The goal of so-called service-oriented architecture is to fix this growing problem. Applications built using SOA will support the same business processes that applications have always supported, but with some important distinctions. SOA's goal is to design and develop all the business functions that go into an application as independent "services," which can then be strung together in several different ways to complete whatever business processes the business requires.
And since different applications often share a single service, that service can be used and reused as often as needed.
The result: greater consistency across business processes and more agility in dealing with business changewith the added benefit of more efficient use of IT assets.
Redesigning an order process, for example, might require a change to a particular service, rather than an entire rewrite of one or more applications that contain the business function that service now performs. And improvements to one service, in security, reliability or performance, for instance, will accrue to every application that uses it.
SOA is no panacea. Overhauling the application systems of a large organization in order to employ SOA is a complex, multiyear journey. Companies that began that journey several years ago are now testing the limits of SOA. The software a company needs to manage a growing portfolio of services, for instance, is relatively immature. And while the technology is in place to share services over the Internet with external business partners, few organizations feel security is reliable enough to do so with anyone other than those they most trust. But the tenets of SOA contain an inherent simplicity and rational design that many, if not most, application portfolios sorely lack.
This article was originally published on 10-05-2005