Business Implications

SOA has several important implications for business. First, to the extent that loose coupling is in effect, changes made to the service logic won't force significant changes to requesters of that software. When each component is a relatively stand-alone unit, your company can respond to business or technological changes more quickly and with less expense and confusion. At best, a service can even be re-deployed to another machine without changing logic or recompiling the code. A further implication is that your company can develop services for different platforms and with different implementation languages, letting the organization use the best available technologies.

In general, a company's ability to respond quickly and well to change is known as agility. The main promise of service-oriented architecture is that a well-crafted SOA will increase agility over time.

SOA also has an important effect on how people work together. Aside from the most technical services, a well-written service is coarse-grained, meaning that the area of concern is broad enough so business people can understand the purpose of the service even if they know little about software. To the extent that a collection of coarse-grained services handles your company's business procedures, the firm's business analysts and software professionals can share information knowledgeably, can include end users in early deliberations about the purpose and scope of each service, and can understand all the implications of changing a business procedure. Ease of human communication is an important benefit of SOA and suggests that the architecture will become the primary organizing principle for business processing.

Last, well-designed services are more likely to be reusable. Your company benefits from reuse in at least two ways: first, by avoiding the expense of developing new software, and second, by increasing the reliability of the software inventory over time. The firm can do less extensive testing if an existing service is placed in a new application, in comparison to the testing required to deploy software that was written from scratch.

Criteria for SOA Implementation

A company is most likely to develop an SOA if the firm anticipates substantial change, has problems with existing applications or application access, and is willing to make the initial investment in analysis and planning.

A company is most likely to embrace an SOA based on Web services if it wants its software to be accessed by partners and customers - specifically, partners and customers that lack the binary-exchange solutions the company might otherwise favor. A Web service implementation is also the approach of choice for companies that want to depend less on particular software vendors.

Migration of Existing Applications

A company can develop an SOA to increase the rationality of its existing applications. A migration can be costly, though, in part because the design team must complete an analysis that reflects a concern for the business as a whole. A business-wide focus means that the team is better able to isolate services for use in multiple applications, including applications that are likely to arise in response to future requirements. The need is for knowledge and vision, so that interaction with business people can reduce the amount of duplicate logic in a company's software and can increase the ease of future updates.

Although planning for service development is essential, the actual development can occur in stages, with the cost of work spread over time and over several projects. As a start, a company might convert code that has strategic value, is accessed by different systems, or is likely to change in any case.

An incremental migration lets the company learn from experience. Decision-makers may begin a migration to an SOA that's based on Web services, for example, and then turn to a binary-exchange solution. The company is likely to benefit from whatever design was accomplished in the initial phase. It can even benefit from completed Web services because in most cases, code that depends on binary-exchange technology can access Web services.

Reasons to Reject Web Services

A company may require that its software respond more quickly than is possible with Web services. In this case, the company can use a binary-exchange technology and still gain the benefits of SOA. For example, if COBOL programs access one another, a firm may want to avoid the runtime overhead that comes from converting data into XML and back to native COBOL.

Similarly, if a subsystem requires hardware or software from specific vendors, a company may consider using binary-exchange services that continue the firm's reliance on these vendors. A cost of this strategy is that the company is vulnerable to the vendors' pricing and customer response.

Last, a company may avoid developing Web or binary-exchange services to replace software that isn't expected to require a lot of change. This consideration applies when applications have fulfilled their mission for years and an appropriate statement is, "If it ain't broke, don't fix it."