Enterprise architecture and SOA
Thinking back on many SOA client engagements, I find that nearly all of the customers that come to mind followed a bottom-up approach in the design and deployment of their service-oriented architecture (SOA) solutions. Overall, they have done a pretty good job of analyzing existing assets, enabling (or just "wrappering") the relevant ones (or the ones they think are relevant), and developing a service catalogue to address requirements. In short, it is business as usual with SOA as an architectural model for IT-centric integration. On the positive side, this approach provides flexibility and a basic level of reuse, but the big payback for SOA is not there.
Success with SOA at the enterprise level requires an integration of SOA concepts with the business (and technical) strategy aspects of enterprise architecture and governance and support for top-down (as well as bottom-up) SOA solution analysis and design. By focusing on the business aspects as an integral part of the SOA design and development, organizations stand a much better chance of sustaining real value from their SOA solutions.
This discussion is presented with a desire to reinforce the concept of coupling SOA design with a business focus. It is not meant to be a tutorial in enterprise architecture or SOA design methodologies, but the Resources section provides information on IBM®'s SOA method should you desire further information.
From project-level to enterprise
Before we get started, let's be clear: There is nothing inherently wrong with SOA adoption at a project level -- in fact, the inception of most enterprise SOA initiatives typically happen in a well-scoped project. Additionally, organizations with enterprise architectures look toward a pilot implementation to validate the SOA solution. The key is to take the experience learned at a project/pilot level and promote it to the level of the enterprise architecture.
I had an interesting meeting with the lead enterprise architect for a large company a few weeks ago. Although the initial conversation addressed the technical aspects of SOA and SOA design patterns, we spent a considerable amount of time discussing SOA and enterprise architecture. Within this client's IT strategy, SOA is implemented on a project-by-project level. This project-centric development approach is characteristic of most companies that are implementing SOA today -- it is fostered by the traditional enterprise culture as well as project-based funding models. Although project-focused SOA initiatives provide benefits, support for SOA at the enterprise level can provide higher agility and service reuse, plus promote a greater linkage between business and IT. The highest payback for SOA is not fully realized until SOA is part of the enterprise infrastructure and ingrained in the development, design, deployment, and governance methods across an organization.
Successful implementation (and ongoing success) with SOA at an enterprise level brings benefits in terms of adapting quickly to market dynamics, decreasing time to market for new solutions, providing a linkage to business requirements, and reducing IT costs over time. These findings are supported by the recent IBM Institute of Business Value study, performed in 2006.
On the other hand, one challenge with project-driven SOA implementations is elevating the solution to be more than just a collection of service invocations. By integrating SOA at the enterprise architecture level, SOA becomes part of the business/IT ecosystem. With this approach, services become a foundation in the creation of new solutions and can provide cohesion between business requirements and IT solutions.
In Figure 1, business and IT strategies drive the definition and specification of the enterprise architecture. From a downstream perspective, enterprise architecture supports planning at the organizational level with a focus on information, applications, and organizational aspects. This framework implements enterprise-level governance and provides guidance and support for IT solution design and delivery. SOA design at an enterprise level typically requires that SOA becomes a key enabling framework for the strategy, planning, and execution layers of enterprise architecture.
Figure 1. Project focus vs. enterprise focus
Figure 1 courtesy of Gil Long, IBM Distinguished Engineer. Source: IBM Global Services – EA Method Class.
Decomposing the business
Establishing SOA as an integral part of the strategy and planning within enterprise architecture typically requires an understanding of an organization's core competencies to ensure a linkage between business objectives and architectural requirements. The process of analyzing the core functions within an enterprise can be done through a variety of techniques. For example, IBM Global Business Services uses Component Business Modeling (CBM) to assess organizational competencies. Literature on the CBM process is available on ibm.com.
At a high level, CBM is a relatively intuitive concept. The basis for the CBM solution is the definition of core business components within an organization. A business component is a grouping of the people, technology, and resources delivering specific business value and able to operate independently. Examples of business component might be Sales Administration or Product Management/Marketing and the people, processes, and technology dimensions that render either function. Business components support the identification and design of business functions and services in terms of analyzing and documenting the business services consumed, as well as the business services offered by the component. For example, a Sales Management business component may use services from Account Administration and may provide services such as Sales Order Processing to other components, such as Collections.
Once we have derived the business components, CBM enables us to classify the components on their overall relative cost to the business and to assess whether the business considers the capabilities to be differentiating. The grouping of the competencies allows for identification of areas for improvement and optimization. An example CBM work product might resemble Figure 2, with the highlighted components identified as areas for ongoing analysis and design.
Figure 2. Sample component business model
These identified "hot areas" might become input for SOA design activities like process modeling. For instance, if we determine that Account Opening is an area for improvement, we can develop the initial requirements through articulation of business vision, business goals, and use case specifications related to Account Opening.
As an example of this process, we used CBM internally during an engagement with a large retail bank. During the analysis, Account Management was recognized as a core competency for the bank, as well as a differentiator in terms of customer satisfaction and reducing customer churn. CBM activities suggested that the Account Opening process could benefit from transformation to support a more streamlined and standardized set of processes (for example, services) across the bank's multiple lines of business. Delivery of this enhanced capability would reduce costs, as well as increase customer satisfaction. Using the CBM analysis in conjunction with Information Warehouse information and process modeling, this bank is now actively developing an enterprise-level solution to transform Account Opening across their lines of business.
The CBM technique provides a framework for determining the key competencies in an organization and providing guidance, in terms of next steps, for optimizing the organization. Additionally, CBM templates are available via IBM Global Business Services engagements for nearly every major industry vertical. The business component design process provides input into the enterprise architecture by defining strategic areas of improvement at a business level, reconciling these objectives with a business services view, and coupling this services view with IT planning.
Service-oriented modeling and architecture
A service modeling methodology is critical for rendering an optimized service model to implement the solution design. The service-oriented modeling and architecture (SOMA) technique provides a rigorous, documented analysis and design methodology for deriving a SOA solution. SOMA is IBM's end-to-end SOA solution development method. Rather than give a detailed discussion on SOMA here, I will focus on the concept of designing SOA with a business focus. However, an excellent article by Ali Arsanjani covers SOMA in detail. (See Resources.)
The three fundamental constructs of the SOA models are services, service components (implementations that realize those services), and flows (or processes) that orchestrate the services. SOMA was created specifically to address the analysis and design of all three constructs. As documented within the Rational® Unified Process (RUP), SOMA essentially consists of three major steps, as shown in Figure 3:
- Service Identification: Derives and defines the candidate services.
- Service Specification: Establishes and validates service exposure decisions and derivation of the high-level service model.
- Service Realization: Attributes and extends the high-level service model in terms of overall component design.
Figure 3. Three steps of SOMA
Although SOMA links the SOA design with business objectives in multiple ways, Service Identification and the Service Litmus Test (the first critical step in Service Specification) are the major areas where we will focus our attention.
As mentioned earlier, the key output of the Service Identification step is a set of candidate business services. The list of candidate services is generated in Service Identification via the three techniques:
- A top-down approach known as domain decomposition.
- A bottom-up IT-centric approach focusing on discovery and characterization of existing IT assets.
- A meet-in-the-middle approach referred to as goal-service modeling.
Domain decomposition provides the top-down, business-driven technique aimed at capturing information about significant business domains, functions, conceptual subsystems, and business processes for an organization. Domain decomposition results from the specification of business requirements originating from the business component design. Additionally, domain decomposition can be enabled via the creation and validation of process models using tools like the WebSphere® Business Modeler.
Business process modeling often takes place following the identification of key business activities arising from business component design. Process modeling usually starts with a business analyst using tooling to model the As-Is (current) state of the business process. Within the process model, analysts represent work activities or tasks as steps in the process. As the process model evolves and is reviewed by other business stakeholders, the "tasks" become analogous to candidate services. In some modeling tool implementations such as the WebSphere Business Modeler, business analysts can design As-Is and To-Be models, and can simulate the process to determine run time characteristics including costs, resource requirements, and process bottlenecks. Some tools also support the definition and specification of business key performance indicators (KPI). An example of a business KPI for Account Opening might be stating the average time needed to open an account should be less than 18 hours. Through ongoing design and simulation, process modeling links business requirements and business services to the identification of candidate services.
The existing asset analysis technique is enabled via tooling, as well as by the review of existing documentation and knowledge of existing IT assets. This activity examines existing IT assets that might be considered for implementing functionality required by the To-Be process. Sources of existing assets might include:
- Mainframe-based (for example, CICS/IMS/Batch) transactions.
- Commercial application (for example, SAP, Siebel) via API, messaging or service interfaces.
- Custom in-house applications, such as J2EE, .Net, and client/server applications.
- Services and interfaces for external services and components available through partners.
One tool that might be used to support this function is the WebSphere Asset Transformation Workbench. This tool assists IT personnel with the extension, reuse, and transformation of existing applications, and dependencies analysis of applications within mainframe and/or distributed environments.
As with domain decomposition, the result of the asset analysis activity is a list of potential candidate services. It should be explicitly stated that assets discovered (as well as the first iteration of potential candidate services) are not equal to services. In fact, most operations are fine-grained even when they are composed services, such as an IDOC or BAPI interactions through SAP. These candidate services are usually suboptimal in terms of conformance to SOA design principles and will likely be encapsulated by higher level services.
Lastly, goal-service modeling is derived from top-down and bottom-up approaches using the business and IT requirements to drive identification of additional candidate services. This activity helps in the identification of business-aligned services and ensures that services have not been identified during domain decomposition or existing asset analysis. Goal-service modeling starts with an identification of business goals, breaks them into sub-goals, and then determines which services are needed to fulfill these sub-goals.
The second major phase in SOMA is Service Specification. This technique contains a number of distinct steps, but for the purpose of this article, I will distill the discussion down to two major activities:
- Applying the Service Litmus Test to determine which candidate services are appropriate to expose.
- Specification of the service model in terms of dependencies, composition, non-functional requirements, message definition, and state management requirements.
The Service Litmus Test is a defined set of criteria to resolve whether a candidate service should be exposed. The criteria fall into four major areas:
Business alignment: Focusing on business relevance of the service, the presence of a funding model to support development and maintenance, and the ability to share the service across the organization.
Composability: Focusing on consistency with non-functional requirements at the composite level, consideration of state management aspects, identifying service dependencies, and supporting technology/platform neutrality.
Externalized service description: Focusing on the presence of an external service description (such as WSDL), the ability to support service discovery and binding via the service description, and providing meta data as part of the service description.
Redundancy elimination: Focusing on the ability to reuse the candidate service across multiple composite scenarios where the specific function is needed.
Through this set of questions and optional extensions and customizations, as appropriate for the specific organization, the design team can make appropriate architectural decisions regarding which services should be developed, exposed, and managed as service implementations.
As an example of the Service Litmus Test, a workshop with a major transportation and logistics company identified over 400 business-relevant SAP interactions (BAPI and IDOC) initially considered as candidate services. This set of services was in addition to nearly 400 other services exposed in custom applications for a total of over 800 candidate services. Although the analysis is still ongoing, we anticipate that the number of exposed services will be less than 200.
The definition of the service model consists of multiple steps and normally results in the creation of UML workproducts. This step is facilitated through the use of architecture tooling such as the Rational Software Architect and the UML Profile for Software Services. During this step, the service model is designed through documenting service dependencies, defining service composition, documenting the service non-functional aspects, defining the high-level service message model, and specifying state management requirements.
As the last major activity in SOMA, Service Realization defines the allocation of services to a component and the allocation of these components to an implementation solution. For example, a service might be realized through an EJB that we expose as a Web service; another service may be realized through the wrappering of one or more CICS transactions, and another may be realized through an adapter providing a J2C interaction pattern.
Putting it all together
As we have progressed through this discussion, we have discussed three core areas: Enterprise Architecture, Business Component Design, and SOA Analysis and Design via SOMA. These three areas are depicted in the following diagram:
Figure 4. Three core areas of SOMA
The linkage between strategy and assessment within enterprise architecture with the analysis of core organizational competencies results in a set of high-level business and IT requirements. These requirements, in turn, form the basis for the initial steps in SOA Design business requirements.
As you can see in Figure 4, the process is iterative by definition. As new market dynamics shape the enterprise architecture, or as an organization's core competencies change, these changes require an analysis of their effect on the overall service design. Additionally, steps within the SOMA service modeling process are iterative as well. As a result of our developing service models or beginning to consider aspects of service realization, we may end up revisiting decisions we made previously in the service design.
In his blog on developerWorks, Grady Booch says it best:
IMHO, SOA's value proposition begins with the A in its acronym: architecture. There is sound, proven value in governing and growing a system's architecture; there are also hard decisions that must be made, many decisions of which cannot be known a priori (which is why a process shaped around the rhythmic incremental and iterative release of executables is so important).
Project-based SOA solutions typically result from a bottom-up, technical focus, providing an entry point for SOA design and development, but offering minimal benefits from an enterprise architecture standpoint.
Designing SOA solutions with a business focus links business requirements and the IT development process at the enterprise level. Defining SOA as the key enabling architecture provides the foundation platform for enterprise solution development. This realization of SOA as a core enterprise solution approach lets requirements be defined and scoped based on the core business competencies of the organization. With these business and IT requirements as input, SOA solutions can be optimally designed through service development methodologies such as SOMA. This approach to designing SOA solutions can provide for an enterprise-level view of services, and offers the ability to decrease time-to-market for new applications, while reducing IT resource exposure through service reuse. More importantly, the design of SOA solutions with a business focus ensures the relevancy and the value of SOA to the organization.
The author wishes to acknowledge Steve Nowland, Ruqsana Jabbar, and Gareth Patterson for their review of this material. The author also wants to acknowledge Gil Long and Ian Charters (IBM GBS) for their material and insight around the area of Enterprise Architecture; these two individuals and their ongoing efforts around EA competency in IBM have been (and continue to be) outstanding. Additionally, the author wants to acknowledge and recognize Ali Arsanjani for both his review of this article as well as his thought leadership around both SOA and the SOMA methodology.
- UML 2.0 Profile for Software Services
- IBM developerWorks: SOA and Web services zone
- IBM developerWorks: WebSphere and SOA resources
- Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA
- Component business modelling
- Norbert Bierberstein, Sanjay Bose, Marc Fiammante, Keith Jones and Rawn Shah, Service-Oriented Architecture Compass, IBM Press, 2006.
- Thomas Erl, Service-Oriented Architecture (SOA): Concepts, Technology, and Design, Prentice Hall, 2005.
Get products and technologies
- Software architecture, software engineering, and Renaissance Jazz: Grady Booch's blog on developerWorks