Most companies today have a strategic initiative focused on Service-Oriented Architecture (SOA) development. Some of these efforts struggled in the early days, but many now have clear goals and measurable objectives. Many of these same companies also have an Enterprise Business Architecture (EBA) initiative as well, or at least some type of Business Process Modeling or Business Process Management initiative. Here again, initially it was a struggle, too. For the early adopters it is always a struggle, but then again, visionary companies initiate pioneering efforts and average companies wait for easier times.
The integration of EBA and SOA initiatives may offer some benefits and ease this struggle. For years many of us have said, “Technology enables the business!” In a similar fashion, perhaps now it is time for some of us to say, “The EBA enables SOA!”
The EBA is a blueprint of the enterprise built using architectural disciplines to improve performance. It integrates the business processes into an architecture used for business design, analysis and performance improvement. If built properly through the judicious use of aggregation and decomposition techniques, the enterprise’s “functional” structure is disassembled and then, reassembled and redesigned into a “value stream” structure. The value streams contain effective business process components, many of which use supporting IT to achieve high levels of efficiency and automation. A component is a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well defined architecture1.
For example, let us take a look at two components in the Order-to-Cash value stream. Before allowing the purchase of a product, the customer’s credit card or personal check is validated. Both of these payment types require some sort of authentication and authorization with the appropriate financial institution. Later in the process, the receivable transaction is posted to the General Ledger.
Payment validation and General Ledger posting are just two examples of important and necessary components in the Order-to-Cash value stream. Each represents a service that is provided using software residing on a network. A service is (Ideally) a self-contained, stateless business function that accepts one or more requests and returns one or more responses through a well-defined, standard interface2. If we continue evaluation of all components, in all value streams, we may better determine the most important and common services to develop in order to improve the business, basing development priorities on strategic needs. We can evolve these components into services that the business users can understand. Taking this business perspective, we may promote the reuse of existing IT assets rather than duplicating or reinventing them. A result achieved from employing the EBA to understand the enterprise.
This represents an example of the synergy between an integrated EBA and SOA strategic initiative. As we mature the SOA development from the guidance provided from the EBA, we are led by priorities based on strategic business objectives. Perhaps this affords additional opportunities in other process improvement and reengineering efforts. Instead of building new processes or reengineering existing processes from a “blank” white board, we begin by assembling processes from our inventory of well-defined and proven services. From a strategic perspective, this enables us to deliver new and improved capabilities to the marketplace better, quicker and at a predictable cost.
Early SOA initiatives were most likely started as IT projects. Perhaps they were adrift somewhere in the IT organization. Others were part of an IT strategy, but were still behind the scenes with limited visibility to the business community. By forming a nexus between the EBA and SOA, you have an opportunity to harness the power of two strategic initiatives, setting the expectation of gaining a competitive edge, higher profits or improving productivity.
Early business architecture initiatives usually got started when someone realized that the independently built, graphical process models needed to be connected and integrated. The business architecture enables you to control the evolution of the process models, ensuring integration “as you go” rather than attempting to force fit loosely associated components together “at the end.” Reuse of architectural components and services becomes apparent when viewed through the EBA, supporting a cultural behavior that can return value to the enterprise.
When considering EBA and SOA initiatives or reevaluating their progress, take the time to understand the potential benefit to the enterprise through integration of these initiatives rather than treating them as two stand alone strategic initiatives. You just might see how the EBA enables the SOA!
References:
1. Philippe Kruchten, The Rational Unified Process: An Introduction (Addison Wesley Longman, Inc. 1999), 89.
2. Wikipedia, Service-Oriented Architecture – SOA Definitions.
