Failing to focus on reuse strategies will inhibit the success of a transition to a service-oriented architecture (SOA). Organizations can waste considerable resources when they don't plan to use reusable components up front. Duplicate development and test effort can go into creating redundant components. Other problems caused by back-end dependencies on shared services can dramatically impact their actual performance.
To address these challenges, experts recommend organizations take a holistic view of their proposed service ecosystem. It's important to take the time to work on the right problems by doing a careful analysis of existing business processes. It's also important to think about several principles of SOA to help organize your exploration and analysis.
An eye towards reusability
To get the most out of SOA, organizations need to start from the beginning, with an eye toward building reusable components. "At a high level, SOA is an architectural pattern that is all about sharing things like data, compute and transaction services across applications," said David Linthicum, chief technology officer and founder of Blue Mountain Labs, a cloud computing consulting and advisory firm based in Washington, D.C. Linthicum has written more than 13 books on computing, including Cloud Computing and SOA Convergence in Your Enterprise, a Step-by-Step Approach.
Linthicum explained, "The idea is I write one great risk-analysis service to determine whether I can trade or not. That has applicability in 10 different applications I may be running in a financial service shop. Therefore, I only have to write it one time, and it propagates value through all of the systems because of the standard Web service."
Always ensure that the components are loosely coupled so that they can be assembled into lots of different types of applications.
The idea is to write services once for storage or compute systems so that you can leverage them many times across applications. "It comes down to the old concept we invented around structured development, but that was at the code level," Linthicum said. "SOA can stand up small applications, called 'services,' that are compatible and can be shared across applications, because all of the services communicate using the same protocols and standards."
The most established best practice is to spend the time doing the design and architecture up front. Instead of thinking tactically about an application, it's important to think holistically around that application and the hundreds of other applications and the number of services that are shareable.
Most organizations have failed in making the leap. The ones that have succeeded have taken many years. It can take three to five years to shift thinking toward a SOA paradigm. "We are not able, at least in the US, to come together in terms of these large strategic shifts," Linthicum said. "Organizations tend to think tactically at the domain level. Organizations that only think in six-month increments don't tend to do too well. Organizations that think in terms of years do much better."
To be successful, Linthicum recommends that organizations bring in a SOA advocate who can also lead and understands the value of the technology and of doing this as a best practice. "If I am going to transform an organization, I need to be able to control budgets and fire people," he said. "You have to make the commitment and investment in someone empowered to make true changes, and that is done by controlling money and careers. If you are just hiring someone to make suggestions and give luncheon talks, you will not have change."
Looking for commonality: Best practices
One important step in transitioning to SOA is to look at commonality among different workflows that can be grouped into candidate services. This provides a preliminary view of reuse potential as currently reflected by the state of the business, said Thomas Erl, CEO of Arcitura Education Inc., and author of SOA Design Patterns and several other books. "By grouping common actions and services into functions with common generic context, we can repurpose those as being useful for future business processes that have yet to be defined."
The reuse potential begins during the analysis stage, when organizations identify common things the business processes are performing. These need to be grouped into generic reusable functional contexts, such as an invoice as an entity. "This maximizes the reuse potential of what we build. It fulfills the current requirements and is there to support future requirements," Erl said.
Always ensure that the components are loosely coupled, so they can be assembled into lots of different types of applications. "It is important to think about how well-suited the individual services are to be effective service composition members," Erl said. "The goal is to be able to pull them into different types of solutions in a way that they never introduce a weak link in the chain. They are designed with the necessary controllers and infrastructure to be part of different types of solutions without requiring redevelopment."
Another best practice is to position these services as high-value IT assets that provide the ability to continuously leverage their availability. Erl explained, "We have the opportunity to leverage and releverage the service. We invest in and build solutions that are closely aligned with how the business changes. By taking advantage of that, we can deliver solutions more responsively and in an agile manner, because we do not have to customize it in order to be part of new solutions."
It is also important to think about the autonomy of different components. The more autonomous an implementation, the more predictable its runtime behavior will be. The more it depends on a shared database, the more shared its underlying environment and the less predictable its behavior. Making it more predictable further increases its reuse potential, Erl said.
A SOA architect needs to look at the key chokepoints in the way services are implemented. Particular attention needs to be paid to shared resources, such as network connectivity, databases or CRM systems. Although these shared back-end resources may perform well when a system goes into production, they can pose a bottleneck when multiple separate services are independently pushed to capacity. To address the need for autonomy, the SOA architect needs to think about identifying and reducing the impact of congestion from resources that need to be used across SOA services.
Improve resuabililty of SOA using microservices