Ask the Expert: Service-Oriented Architecture (SOA)

Service-oriented architectures have received much attention for their potential to improve business performance as well as reduce IT costs. Avanade's Tyson Hartman shares his experience working on service-oriented architecture development projects, and his insight into how to best approach the move to SOA.

What does the term "Service-Oriented Architecture" mean?

Can you explain what you mean by open standards? And, how they enable improved communications?

What kind of business value can be realized through SOA?

Have you come across any situations where implementing SOA is not the best option?

What are the first three steps my organization should take when considering a move of an application(s) towards a service-oriented architecture?

Q: What does the term "Service-Oriented Architecture" mean?

A service-oriented architecture (SOA) is an architectural strategy that you can use for greater interoperability and easier integration between your systems and with your business partners. It is an architectural strategy rather than an installable product, and it allows you to take advantage of open standards to communicate between systems and business partners. Even more, it can provide a platform for long-term change that you can leverage today to drive out cost and improve agility over time.

back to top

Q: Can you explain what you mean by open standards? And, how they enable improved communications?

Standards that are "open" are maintained by public organizations such as the W3C and OASIS and have been agreed to by major industry vendors. For example, the web service interoperability standards or WS-* were defined and agreed to by firms such as IBM, Microsoft, Sun, and others. The standards define how to request that specific activities, such as reliably sending a message, will be represented. That means different vendors will use these open standards to ensure their platforms all represent requests for reliable messages in the same way. Many of these standards build on each other. For example, to securely and reliably send a message between disparate systems, standards for addressing (WS-Addressing), reliable messaging (WS-ReliableMessaging), and security (WS-Security) also need to be in place.

Previously, software design standards such as these were proprietary to each vendor, making interaction between systems a more difficult and slower task. But today open standards have enabled new ways for interoperability between systems that reside on a variety of platforms.

And this is where SOA comes in, because it provides a new, open, standards-based way to solving common interoperability problems that businesses have struggled with over the years. This is not to say that cross-platform systems were unable to talk to each other prior to SOA, rather that SOA makes those communications much easier and faster to approach. In fact, I would call SOA "evolutionary" rather than "revolutionary" in that many of its core tenets have existed for years but are only a reality today because the open standards necessary to implement them are now available.

back to top

Q: What kind of business value can be realized through SOA?

With SOA organizations have the opportunity to consolidate a significant amount of redundant business function and reduce the complexity of their systems. And this can translate into lower total cost of ownership for streamlined or consolidated systems as well as lower costs for bringing and integrating new applications within the existing business environment. Due to merger and acquisition activity or realities of large enterprises, many companies have redundant business processes in their systems, and SOA represents the first cost-effective way to have these systems co-exist. Abstracting these business processes from the applications allows you to measure KPIs around business performance and improve the efficiency of the business over time.

However, it is worth mentioning the benefits SOA brings do not make it a silver bullet. One consideration is that implementation will not be a one time event, it's a journey. Because SOA is not an installable product, but instead offers an approach towards application design, organizations will need to continue to service orient new systems they bring into their environment. The good news is that following the initial implementation, each subsequent integration of systems into a service-oriented environment will become easier and faster. So while an organization can gain significant benefits, SOA adoption is an investment, and it takes time to recognize and realize the value of service orienting your business. Many major ISVs, including ERP/CRM vendors, are building web service support into their products, providing the building blocks for SOA so enterprises won't have to develop them.

To maximize benefits, we often advise organizations to approach their move towards a service-oriented environment strategically. One option is to begin incorporating service-oriented design within new applications first instead of tackling the existing environment. Another option is to begin moving existing systems—but only as required by the business needs of the organization. A cost reduction initiative such as server consolidation or application rationalization can be a good starting point for using SOA design in existing systems. Similarly any new integration projects or new business partner integration that include SOA will benefit in the long term.

back to top

Q: Have you come across any situations where implementing SOA is not the best option?

In my experience, the most critical success factor to SOA adoption is having a clear business case driving the need to service orient an enterprise. As with any large IT initiative, any change introduced to the organization should be directly linked to a business issue which it can affect.

If an organization has no clear vision of how SOA can improve its business performance, then it may not be the answer. To illustrate this point with a simple example, let's say I have two systems that can talk to each other. Service orienting their architectures will not necessarily bring me any additional value unless I have a vision of how the exposed services could be reused in other applications in the future as well. Quite possibly, the effort taken to move the two applications to SOA would slow down the business, if there were no clear long-term benefits in sight.

back to top

Q: What are the first three steps my organization should take when considering a move of an application(s) towards a service-oriented architecture?

First, I would recommend an organization define a governance model. Lack of clear governance is one of the biggest obstacles that we have seen to successfully driving a service-oriented enterprise. The governance model should define what the goals of the initiative are, who has control, who will have what responsibilities, the execution model, and both a business and a technical review board or committee. In practice, most IT governance models are too loose, so without good governance, you could potentially end up with more services than you need, services built for inappropriate uses or redundant services all together.

Once you have the governance model outlined and stakeholders identified, the second step is to develop your plan. Again, it is very important that your plan to be built around solving a business problem, to give it backing under a broader strategy. Without this piece, it will be harder for the business to appreciate or fully understand the long-term benefits of your development efforts.

Finally, set and test standards for the project by using proof-of-concepts to ensure your project aligns to the business' needs. It's worth keeping in mind that moving towards SOA will impact the entire IT lifecycle, changing how IT designs, develops, tests and monitors applications. Testing your design can be an important element to reducing implementation challenges later on.

back to top