Common tangible benefits of SOA

So far we've discussed what constitutes an SOA. Much of this book expands on this topic by providing details about the inner workings of service-oriented solutions. Provided in this section is a list of the reasons why the IT community is going through the trouble of changing so much of its philosophy and technology in an effort to adopt SOA.

The benefits described in this section focus on tangible returns on investment, related primarily to:

• how SOA leads to improvements in automated solution construction
• how the proliferation of service-orientation ends up benefiting the enterprise as a whole

Note

SOA will benefit organizations in different ways, depending on their respective goals and the manner in which SOA and its supporting cast of products and technologies is applied. This list of common benefits is generalized and certainly not complete. It is merely an indication of the potential this architectural platform has to offer.

3.4.1. Improved integration (and intrinsic interoperability)

SOA can result in the creation of solutions that consist of inherently interoperable services. Utilizing solutions based on interoperable services is part of service-oriented integration (SOI) and results in a service-oriented integration architecture.

Because of the vendor-neutral communications framework established by Web services-driven SOAs, the potential is there for enterprises to implement highly standardized service descriptions and message structures. The net result is intrinsic interoperability, which turns a cross-application integration project into less of a custom development effort, and more of a modeling exercise.

The bottom line: The cost and effort of cross-application integration is significantly lowered when applications being integrated are SOA-compliant.

3.4.2. Inherent reuse

Service-orientation promotes the design of services that are inherently reusable. Designing services to support reuse from the get-go opens the door to increased opportunities for leveraging existing automation logic.

Building service-oriented solutions in such a manner that services fulfill immediate application-level requirements while still supporting a degree of reuse by future potential requestors establishes an environment wherein investments into existing systems can potentially be leveraged and re-leveraged as new solutions are built.

The bottom line: Building services to be inherently reusable results in a moderately increased development effort and requires the use of design standards. Subsequently leveraging reuse within services lowers the cost and effort of building service-oriented solutions.

3.4.3. Streamlined architectures and solutions

The concept of composition is another fundamental part of SOA. It is not, however, limited to the assembly of service collections into aggregate services. The WS-* platform is based in its entirety on the principle of composability.

As described in the Common characteristics of contemporary SOA section, this aspect of service-oriented architecture can lead to highly optimized automation environments, where only the technologies required actually become part of the architecture.

The bottom line: Realizing this benefit requires adherence to design standards that govern allowable extensions within each application environment. Benefits of streamlined solutions and architectures include the potential for reduced processing overhead and reduced skill-set requirements (because technical resources require only the knowledge of a given application, service, or service extension).

Note

The reduced performance requirements mentioned previously only refer to the fact that SOA extensions are composable and therefore allow each application-level architecture to contain extensions only relevant to its solution requirements. Message-based communication in SOAs can, in fact, increase performance requirements when compared to RPC-style communication within traditional distributed architectures. See the Not understanding SOA performance requirements section later in this chapter for more information.

3.4.4. Leveraging the legacy investment

The industry-wide acceptance of the Web services technology set has spawned a large adapter market, enabling many legacy environments to participate in service-oriented integration architectures. This allows IT departments to work toward a state of federation, where previously isolated environments now can interoperate without requiring the development of expensive and sometimes fragile point-to-point integration channels.

Though still riddled with risks relating mostly to how legacy back-ends must cope with increased usage volumes, the ability to use what you already have with service-oriented solutions that you are building now and in the future is extremely attractive.

The bottom line: The cost and effort of integrating legacy and contemporary solutions is lowered. The need for legacy systems to be replaced is potentially lessened.

3.4.5. Establishing standardized XML data representation

On its most fundamental level, SOA is built upon and driven by XML. As a result, an adoption of SOA leads to the opportunity to fully leverage the XML data representation platform. A standardized data representation format (once fully established) can reduce the underlying complexity of all affected application environments.

Examples include:

• XML documents and accompanying XML Schemas (packaged within SOAP messages) passed between applications or application components fully standardize format and typing of all data communicated. The result is a predictable and therefore easily extensible and adaptable communications network.
• XML's self-descriptive nature enhances the ability for data to be readily interpreted by architects, analysts, and developers. The result is the potential for data within messages to be more easily maintained, traced, and understood.
• The standardization level of data representation lays the groundwork for intrinsic interoperability. Specifically, by promoting the use of standardized vocabularies, the need to translate discrepancies between how respective applications have interpreted corporate data models is reduced.

Past efforts to standardize XML technologies have resulted in limited success, as XML was either incorporated in an ad-hoc manner or on an "as required" basis. These approaches severely inhibited the potential benefits XML could introduce to an organization. With contemporary SOA, establishing an XML data representation architecture becomes a necessity, providing organizations the opportunity to achieve a broad level of standardization.

The bottom line: The cost and effort of application development is reduced after a proliferation of standardized XML data representation is achieved.

Note

The last two benefits (legacy integration and XML data representation within SOA) are covered in Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, the companion guide to this book.

3.4.6. Focused investment on communications infrastructure

Because Web services establish a common communications framework, SOA can centralize inter-application and intra-application communication as part of standard IT infrastructure. This allows organizations to evolve enterprise-wide infrastructure by investing in a single technology set responsible for communication.

The bottom line: The cost of scaling communications infrastructure is reduced, as only one communications technology is required to support the federated part of the enterprise.

3.4.7. "Best-of-breed" alternatives

Some of the harshest criticisms laid against IT departments are related to the restrictions imposed by a given technology platform on its ability to fulfill the automation requirements of an organization's business areas. This can be due to the expense and effort required to realize the requested automation, or it may be the result of limitations inherent within the technology itself. Either way, IT departments are frequently required to push back and limit or even reject requests to alter or expand upon existing automation solutions.

SOA won't solve these problems entirely, but it is expected to increase empowerment of both business and IT communities. A key feature of service-oriented enterprise environments is the support of "best-of-breed" technology. Because SOA establishes a vendor-neutral communications framework, it frees IT departments from being chained to a single proprietary development and/or middleware platform. For any given piece of automation that can expose an adequate service interface, you now have a choice as to how you want to build the service that implements it.

The bottom line: The potential scope of business requirement fulfillment increases, as does the quality of business automation.

3.4.8. Organizational agility

Agility is a quality inherent in just about any aspect of the enterprise. A simple algorithm, a software component, a solution, a platform, a processall of these parts contain a measure of agility related to how they are constructed, positioned, and leveraged. How building blocks such as these can be realized and maintained within existing financial and cultural constraints ultimately determines the agility of the organization as a whole.

Much of service-orientation is based on the assumption that what you build today will evolve over time. One of the primary benefits of a well-designed SOA is to protect organizations from the impact of this evolution. When accommodating change becomes the norm in distributed solution design, qualities such as reuse and interoperability become commonplace. The predictability of these qualities within the enterprise leads to a reliable level of organizational agility. However, all of this is only attainable through proper design and standardization.

Change can be disruptive, expensive, and potentially damaging to inflexible IT environments. Building automation solutions and supporting infrastructure with the anticipation of change seems to make a great deal of sense. A standardized technical environment comprised of loosely coupled, composable, and interoperable and potentially reusable services establishes a more adaptive automation environment that empowers IT departments to more easily adjust to change.

Further, by abstracting business logic and technology into specialized service layers, SOA can establish a loosely coupled relationship between these two enterprise domains. This allows each domain to evolve independently and adapt to changes imposed by the other, as required. Regardless of what parts of service-oriented environments are leveraged, the increased agility with which IT can respond to business process or technology-related changes is significant.

The bottom line: The cost and effort to respond and adapt to business or technology-related change is reduced.