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.