SAN FRANCISCO – SOA isn’t just trendy, it’s here and it’s working. Most large enterprises have already launched some sort of SOA initiative, the objective being an agile architecture that can respond to business needs in near-real time. Along the way, SOA provides a means for fixing systems that have languished in a dysfunctional state for years. No wonder IDC expects spending on SOA-related software to reach nearly US$15 billion by 2009.
With an SOA in place, organizations can leverage existing systems in a dynamic environment, abstracting the essence of applications into services that can be reassembled quickly into new solutions. But how do you get there from here? An SOA has so many moving parts, it’s often difficult to step back and isolate the guiding principles that can keep an initiative heading toward success.
Fortunately, with so much SOA activity out there, the lessons of experience are plentiful. In fact, you can count the most important of those on one hand: understand the pain, define the value, focus on understanding, remember the people, and concentrate on the long term.
Understand the pain
In many modern global 2000 companies, existing enterprise architectures hinder the business’s ability to change. For instance, a recent survey by the Business Performance Management Institute found that only 11 percent of executives say they’re able to keep up with business demand to change technology-enabled processes — 40 percent of which are currently in need of IT attention.
Worse, according to a poll conducted by CIO magazine, 36 percent of respondents reported that their company’s IT departments are having either “significant difficulties” (27 percent) or “can’t keep up at all” (9 percent).
The reality is that IT has suffered dire levels of latency in supporting business changes. CEOs pull out their hair when IT talks about years rather than months to accommodate new product lines, markets, or mergers. Indeed, in many companies, the IT shop is the single limiting factor in business success, and it can kill the business if left to continue as is.
This is real pain … and a real problem. Solving this problem can be a tremendous boon for many organizations. Never forget that responsiveness is the main driver — and the principal benefit — of SOA.
Define the value
Organizations implement SOA for two major reasons. The first reason is to gain the ability to save development dollars through reuse of services. These services may have been built inside or outside of the company, and the more services that are reusable from system to system, the greater the ROI. The second reason is the ability to change IT infrastructure faster and adapt to shifting needs of the business. This provides a huge strategic advantage and can give the business a better chance of survival in the long-term.
Several factors can help you quantify the value of service reuse, including the number of services that are reusable, the complexity of those services, and the degree of reuse from system to system. The complexity of each service is key to assessing value, which can be defined as the number of functions or object points that make up the service. Just as important is the number of instances where you expect it will be practical to reuse a given service.
Although determining the ROI of agility is difficult to figure in hard dollars, it isn’t impossible. You need to ascertain a few things about the business, including the degree of change over time, the ability to adapt to that change, and the relative value of change.
The degree of change over time is really the number of times over a particular period that the business reinvents itself to adapt to a market. For example, whereas a paper company may experience a change of only 5 percent in a five-year period, a high-tech company may undergo an 80 percent change during the same period.
When estimating the future value of an SOA, it’s essential to describe correctly your business’s current ability to adapt to change, and project to what degree that ability will increase after an SOA is in place. Everyone benefits from realistic expectations. Finally, the relative value of change is the amount of money made as a direct result of changing the business. For instance, if a retail organization wants to become more competitive by establishing a frequent buyer program, the faster time to market afforded by an SOA will result in greater revenue at a lower cost. It may even be that launching such a program would be entirely impractical without an SOA in place.
Focus on understanding
Although many people have some idea of what an SOA is, few have a clear idea of how to get there. Every situation is different, so you won’t find one, canonical set of hard-and-fast rules. Nonetheless, some common patterns are emerging that can help you understand the way forward.
First, you should understand your business objectives and define success. You’re helping to run a business, and the technology you layer into that business should positively affect the bottom line. It’s important to articulate objectives up front, including what defines success.
Second, you should define your problem domain. You can’t boil the ocean, so you need to define the scope of your SOA within an enterprise. Most SOAs are best implemented in small steps, such as moving a single division, or portion of a division, to SOA; grandiose plans for an entire enterprise seldom work. Small successes lead to larger more strategic successes in time.
You should also understand all application semantics in your domain. You can’t deal with information you don’t understand, including information bound to behavior (services). It’s extremely important for you to identify all application semantics — metadata, if you will — that exist in your domain, so you can properly deal with that data. A rational framework for application semantics establishes the way and form in which specific applications relate to properties of business processes.
Understanding all services available in your domain is also important. The best place to begin with services is with the creation of a directory. This is a repository for information about available services, along with the documentation for each service — including what it does, information passed to a service, information coming from a service, and so on. This directory is used (along with application semantics) to define the points of integration within all systems in your domain.
Make sure also to understand all processes in your domain. Define and list all business processes that exist within your domain. After you have established the services and information available, you need to define higher-level mechanisms for interaction, including all high-level, mid-level, and low-level processes. In many instances, these processes have yet to become automated or are only partially automated.
Next, select your technology set. Many people begin with this step — at their peril. You can’t select the right SOA technology for the job without a solid understanding of your requirements. To be successful, the marriage of criteria and products often requires a pilot project to prove the technology will work. In fact, the time it takes to select the right technologies may equal the time it takes to develop the SOA. But it’s worth the investment, because a bad choice practically ensures the failure of your SOA.
And finally, test and evaluate. It’s essential to have a step-by-step procedure detailing how the SOA will be tested when complete. A test plan is important because of the difficulty in testing SOA solutions. Service orientation adds dependencies — and by nature an SOA should be extensible beyond applications you may be able to dream up today. Moreover, in many SOAs, the source and target systems are business-critical and cannot be taken offline. Testing these systems can be a bit tricky, but must be comprehensive nonetheless.
Remember the people
SOAs are built and managed by people, so you need to consider the impact on humans as well as the impact on enterprise architecture. There are two places to focus: the SOA-literacy of the people building the SOA and the skill levels of the people who will be using the services and interfaces of the SOA.
Those tasked with building an SOA need to have a firm grasp of traditional enterprise architecture along with the ideas, approaches, and technology of SOA. For most organizations that’s a tall order. Outside consultants may be needed for mentoring at early stages, and internal training on approaches and tactics should be an ongoing affair.
Without this kind of support, chances are your people — and the SOA itself — will fail. Either hire the consultants necessary to seed the organization with knowledge, or, in some cases, hire new people who are suited for the execution of an SOA project. Not an easy decision, but it could save the project.
Finally, consider those who leverage the services, processes, data abstractions, and the resulting new visual applications. How will this change the way they do their jobs? How will you train them? How will you support them? How will you capture their suggestions for improvements? Better to answer these questions sooner rather than later.
Concentrate on the long term
An SOA is a long-term solution. Expect no measurable ROI in the short term. For most enterprises, the value will be understood in years, not months.
This can be a tough sell when you consider that most American businesses operate quarter to quarter, and budgets and objectives change monthly. Long-term projects such as SOA, which are both complex and systemic, are difficult if not impossible to maintain across time in some organizations. If your organization steadfastly resists a long term outlook, an SOA may not be for you.
The best advice is to get investment and commitment from the top of the organization, so you have the political clout to protect projects, and the bully pulpit to convince people of the long-term value and importance of SOA to the enterprise.
Anything less will result in failure. If SOA is implemented as just another quick fix, it can layer even more complexity onto the enterprise technology infrastructure. Without a long-term commitment to SOA within the organization, even the simplest SOA project will have a slim chance of success.
QuickLink 076638
