There seem to be many reasons for moving onto a Service-Oriented Architecture (SOA) footing. Users hope to achieve lower costs, faster timeto-market, enhanced business agility and visibility, and reduced risk. But as the rosy glow starts to fade, companies are starting to find themselves struggling.
In some cases, although the technical and architectural groundwork has been laid, IT organizations have come up against roadblocks in internal procurement and investment cycles. In others, despite expanded SOA use, expected benefits aren’t flowing. So is SOA all just a lie? Does it not deliver all the benefits it claims? There are plenty of examples where SOA is delivering the goods. The fact is, turning IT assets into reusable services that align with business operations and are accessible in a common way, independent of service location, truly can deliver higher levels of reuse, reduced redundancy, more flexible and adaptive systems, and clearer IT alignment with the business.
This article offers lessons to be learned from the mistakes and successes and points out the corresponding pitfalls to help you avoid them.
Reuse Isn’t Happening
Reuse is a key factor in many SOA benefits. The idea is that creating reusable services will remove redundancy and dramatically cut application maintenance costs. Reusing services in building new projects saves development and testing effort while improving project quality and reducing risks. Saving this effort lowers development costs and speeds time-to-market, improving responsiveness and agility.
So, what are the main reasons that companies are experiencing problems with reuse levels? Here are the three most common ones:
• Nobody knows what services have already been built
• Services don’t do what everyone wants
• Programmers can be hostile to reuse.
Finding Existing Services to Be Reused
The first issue comes down to how easily programmers can find existing services. A programmer must be able to find existing services and also understand what they do, their characteristics, and how to use them. Some companies embraced Web services as a means of achieving SOA benefits. Developers started to publish Web services for all sorts of different program components. But how should another programmer find out about them? Is this supposed to be a process of osmosis? Companies successful with SOA have discovered the importance of recording SOA services in an enterprisewide registry where others can search for them. These records must be in a common format, and include both technical information about the location and execution of the service, and customizable information where userspecific information can be recorded.
Using Web services as the basis for these SOA services offers a standard way to express the technical information, though it isn’t the only approach. The user-specific information can cover areas of policy such as security requirements, name of the service author, and documentation related to the service, its purpose and usage characteristics. The acid test is: Does the record provide enough information for another programmer to identify which services might be useful and clear directions on how to use them?