Companies that decide to invest in SOA sometimes end up going to extremes - too little or too much. Too little happens when some stakeholder latches onto the buzzword and wants to get the benefits promised. However, the environment may be too conservative to invest in the infrastructure and planning required to service-orient existing applications. In this case, an analysis concludes that business as usual is doing just fine, and that there's no need to introduce fancy technologies and platforms. A few minor tweaks to the existing infrastructure are considered sufficient to get on the SOA bandwagon.

In the other case, stakeholders buy into the entire vision of SOA. The IT department is looking desperately for a revamp to continue to survive and prove value, and the company as a whole decides to service-orient lock, stock, and barrel. Major investments are made, five-year plans are drawn up, and the first deliverable is more than a year out. Often, in this situation, business stakeholders end up losing patience, cutting funding, and things roll back to square one.

At one of our current clients, the firm decided to invest in sufficient planning upfront to grow their existing business and achieve business agility via SOA adoption. Often a funding problem is like a tax problem - it's good to have the problem, but it's hard to address it. In our client's case, the business was making money - hence it had extra to hand out to IT to innovate, improve, and grow the business portfolio. The good news was that IT was well funded. The bad news was that it had to figure out what to do with the money. The answer - create an SOA blueprint and plan of execution. And then march to it.

So what do you do if you want to venture out into the world of service orientation, but aren't well versed in the technologies involved? You hire external consultants to set your house in order. Well, that's exactly what happened. Business stakeholders brought in external help to draw up the architecture blueprint. A grandiose vision was delivered and signed off on over a period of over a year. When the time to implement came, the client realized that the change was too big, implementation teams weren't in place, and furthermore, the IT department hasn't really bought into the vision, because it didn't fully understand it. Besides, major pieces of the puzzle were incomplete, because the landscape was too big to be addressed at once. Currently I'm in a situation of rationalizing this vision (created by architects no longer consulting with the company), with a client team that doesn't "believe in SOA."

The main reason companies find themselves in such a situation is because people don't grasp that there are various degrees of SOA adoption and there are often several parts to get there. First you have to decide on which approach applies to you - top-down or bottom-up. Is your infrastructure and team organization mature enough that you can identify and define services in business processes that can then be handed out for independent analysis and development? Or do you need to build basic services that will aggregate to composite infrastructure services, which can then be consumed by calling applications? Do you need to build new applications/interfaces, or do you need to address the fundamental issue of making data available for consumption? Do you need to focus on fundamental services, intermediary services, or process-oriented services? If the existing environment is analyzed properly, the appropriate road to SOA adoption can be defined.

One of the main things to accept is that you will reach a degree of SOA maturity and not everyone reaches the same level in the first iteration. Finally, the vision has to be accepted universally by the business and IT stakeholders.