Why SOA?
A service-oriented architecture addresses many of the problems currently facing IT. It is a framework that promises to deliver enormous flexibility by leveraging existing systems, implementing reusable services and decoupling rigid system interfaces that are difficult to maintain.
Very few IT shops are monolithic. Companies employ a wide variety of technologies and systems to support complex business functions. Over the years, companies have developed unique and customized systems for each functional area of the company. Because information sharing between various groups in the business is critical in the information age, the development of proprietary interfaces and programs to synchronize data between systems often occurs.
It is not uncommon for a company's system portfolio to look similar to that shown in Figure 1.
Figure 1: Common Company System Portfolio
Each graphic in Figure 1 represents a type of IT system in the enterprise. One of the first things to notice in this figure is the number of ways data must be exchanged (system interface) between these types of systems (each type of exchange is represented by an arrow).
Typical systems architectures such as that shown in Figure 1 have several important disadvantages when trying to implement agile, adaptable systems. In the figure, all of the systems are tightly coupled with one another. Tight coupling basically means that system interfaces are proprietary, unique and single-use; they only serve one application's specific needs. In addition, protocols for the interfaces are explicit and technology-dependent. This means that there is absolutely no transparency between systems.
This leads to constant reinvention of similar programs and functions. For example, every function that retrieves a specific piece of information is duplicated in every one of the application systems. Each platform must implement its own application-specific method of retrieving and using the same enterprise data.
What will be the result of implementing this type of architecture if additional enterprise information becomes necessary to communicate among all of these systems? Every one of the interfaces between these systems must be changed to accommodate the new enterprise information that must be shared. This is terribly inefficient and costs a significant amount of both time and money.
Service-oriented architectures address these issues and more. Decoupling of system interfaces is the backbone of SOA. Consider Figure 2, which replaces the custom interfaces in Figure 1 with a common service layer accessible to the entire enterprise.
Figure 2: Common Service Layer is Accessible Enterprise Wide
Within the service layer, reusable services are published and accessible to the entire enterprise. These services are exposed and discovered by consuming applications. Systems interaction is completely transparent and protocol independent. A consuming application that needs customer information, for example, only needs to instantiate the common "retrieve customer information" service without concern for where the information resides and how to retrieve it.
Not only does this architecture enable unbelievable flexibility, it also allows the company to react quickly to changing business drivers. If the customer database changes, for example, only one change is required in the common enterprise service rather than a change to each application-specific interface.
What's more, SOA does not require a complete rewrite or purchase of new systems. In fact, many of the existing systems can still be used. This translates into less scrap and rework when systems use transparent services rather than tightly coupled interfaces.
SOA Critical Success Factors
Now that we have a better understanding of the services approach to architecture and some of the inherent benefits, it is imperative to recognize critical success factors for implementing SOA. They include:
- Senior Management Support
- Enterprise Collaboration
- Standards and Governance
- Education
- Communication
- Planning
A successful move from traditional architectures to an architectural framework based on consumable services must be directed from the top down. Like water, change flows much more easily downhill than uphill. Attempting to initiate change from the bottom or even from the middle is difficult. When upper management is fully engaged and supportive, success is far more likely.
Because implementing SOA requires enterprise-level collaboration and support, senior management must be fully supportive of the endeavor, even to the extent of exploring organizational changes. In order to gain support, you will most likely have to prove the value of implementing SOA. This can be accomplished by doing a cost analysis of application redundant functionality in the enterprise. Simply calculate the extent of redundancy and the costs for maintaining similar programs, especially related to a change in the underlying database.
How much money was spent developing similar functionality and application logic across different functional areas and applications? What is the cost of maintaining redundancy between these applications, and what does it cost every time there is a simple change that needs to occur in every redundant location? Answering these questions will surely get the attention of upper management and provide impetus for moving to SOA.
Enterprise Collaboration
You need to build cooperation and collaboration not only in IT but also in the business units and across functional areas. If you do not have this cooperation, you will have a difficult time getting the centralized control of the services that are designed, developed and deployed. If you don't have centralized control, your SOA effort will be reduced to building point-to-point, tightly coupled services; the exact opposite of what you want.
