DM Review Published in DM Review Online in September 2005.
Printed from

Enterprise Architecture: The Holistic View: Reuse Versus Performance in SOA

by JP Morgenthal

One of the more heavily promoted advantages of a service-oriented architecture (SOA) is reuse of software assets. However, those who are deploying large-scale SOA-based applications soon come to realize that SOA purity may create a need to sacrifice performance. Arriving at the proper balance of performance and reuse for an SOA application is a critical part of its design when using this type of technology.

For example, in a loosely coupled design, such as a service-oriented architecture, should the data model also be loosely coupled? That is, should each service have its own data model that it uses for persistence and have no intimate knowledge of other service's data models? If reuse is your highest priority for moving to SOA, then your data model should be loosely coupled along with your service architecture. This will maximize your ability to use that service as part of other composite applications.

If one follows this line of thinking, SOA forces us to rethink our entire approach to data management. Today, we leverage powerful relational database engines that can perform high-speed relational operations. However, if you have multiple services all leveraging the same tightly integrated data model, it becomes extremely difficult to use that service in other applications without first decoupling it from its existing data model (see Figure 1 below).

Figure 1: Attempting to reuse a service in a new composite application that has tight integration with an underlying data model.

This decoupling requires you to break the relations that are established in the database and reestablish those relationships in the form of service calls (see Figures 2 and 3 below).

Figure 2: Two services that use the same underlying data architecture limits reuse, but has good performance.

Figure 3: Decoupling the data model allows for greater reuse and adds greater levels of abstraction, but adds additional overhead.

Decoupling the database tables from the database and using services to each manage their own data sets require a fundamentally new way to access data. Today's distributed query engines, such as those by Composite Software and Metamatrix, already demonstrate a need for a query facility that is not intimately tied to a single persistence mechanism. Additional requirements include new standards, such as WS-AtomicTransactions, which will allow multiple services to operate within the confines of transaction boundary that either succeeds or fails with rollback.

In many regards, this is a complete extension of the concepts represented by the data hiding attribute of object-oriented programming, and thus, using this model provides us significant flexibility to change how and, more importantly, where the data is being stored without impact to our existing applications. Hence, following this model delivers us the real value we seek from SOA, which is the ability to deliver long-term missions without being interrupted by technological changes. However, in the short term, we trade off performance for this agility.

The concept of reuse versus performance also needs to be addressed when SOA is used for integration purposes. Figures 4 and 5 below illustrate two ways to use a service to integrate the receipt of a purchase order across accounting, inventory and procurement. Figure 4 illustrates a robust and reusable approach to design of a CXML handling service, but has performance overhead due to the increased levels of abstraction and messaging, in addition to the possible increased chances for failure. In contrast, Figure 5 illustrates a service that is tightly bound to accounting, inventory and procurement application. It gets the job done, but limits the ability to use the CXML handling service for any other purpose outside of this integration.

Figure 4: The CXML handling service is an example of a well-defined service that is reuseable and does not offer overloaded functionality.

Figure 5: An example of a service that is tightly bound to the data model and has limited reuse.

As you design your services within your SOA, here are some basic guidelines to help you identify limitations to reuse:

  1. Are any other applications' data impacted if you were to incorporate your service in a new composite application? If other applications using your service impacts other running applications, its level of reuse will be very low to none.
  2. If you needed to deploy your service inside the data management zone or in the public domain, how would this impact your other applications?
  3. Is your service tightly integrated with a particular data adapter or database application program interface? If so, these interfaces may limit your ability to reuse or scale that service.
  4. Does your interface contract require data simply to support the underlying implementation? If so, then your service is too tightly bound to the implementation for enterprise-wide adoption.

I firmly believe that SOA should not be adopted for the sake of adopting the latest technology. If you are truly seeking enterprise agility, which means the ability to deliver on long-term missions without interference from emerging technologies, then SOA is right for your organization. In these cases, it makes sense to:

  • Accept the performance limitation today where necessary;
  • Address unacceptable performance on a case-by-case basis by developing services to encapsulate the tightly bound modules;
  • Isolate services that introduce tight coupling with the underlying architecture or data models until they can be replaced by high performing loosely coupled components.
Following these basic guidelines will ensure that you are taking a pragmatic approach toward delivering the balance between reuse and performance.

JP Morgenthal is managing partner for Avorcor, an IT consultancy that focuses on integration and legacy modernization. He is also author of Enterprise Information Integration: A Pragmatic Approach. Questions or comments regarding this article can be directed to JP via e-mail at Do you have and idea for a future Enterprise Architecture column? Send it to JP; and if it is used, you will win a free copy of his book.

Copyright 2006, SourceMedia and DM Review.