The Architecture of Business Mahesh H. Dodani, IBM, U.S.A.

REFEREED COLUMN PDF Version

1  BUSINESS ARCHITECTURE: THE BUSINESS SIDE OF THE ENTERPRISE

" Business Architecture is a disciplined approach to creating and maintaining a set of activity-based information assets that serve as a blueprint for operational planning and execution. Business Architecture provides a common, enterprise-level framework and language for documenting how the business is structured, including business activities, services and processes and their related requirements, rules, terms, etc.” – Business Architect Community

In my previous article, I laid a foundation for a Service Oriented Architecture (SOA) as the enterprise architecture of the globally integrated enterprise. The main components of an enterprise architecture describe the structure and behavior of the enterprises' assets (its processes, information and people) through well defined business and IT architectures that are aligned with the enterprises' goals and strategies. The approach shown in Figure 1 is inherently iterative – allowing the business strategies and requirements to drive the IT implementations, and in turn the implementations drive changes and improvements in the business. Of course, new market dynamics can change the enterprise architecture or the enterprises' core competencies. These changes will effect the business architecture, which in turn starts another iteration through the approach.

Designing solutions with a business focus links business requirements and the IT r ealizations at the enterprise level. Designing solutions with a business focus links business requirements and the IT development process at the enterprise level. SOA provides the foundation platform to address the entire solution lifecycle -- through development, deployment, management and optimization. SOA facilitates the definition of the business requirements and through appropriate approaches transforms these requirements into optimal IT solutions. More importantly, the appropriate use of compatible methods (such as the Service Oriented Modeling and Architecture method I introduced in my last column and will elaborate on below) can result in reusable services that can in turn help the enterprise decrease time-to-market for new applications. More importantly, the manifestation of SOA as the enterprise architecture ensures the alignment of the solutions to the enterprise strategies as they continue to evolve to address changes in the marketplace.

Figure 1: Aligning IT with Business

The rest of this article focuses on the business architecture, showing how to start the process by componentizing the business to establish the requirements, and then how to take these business components and design a service oriented application that realizes them.

2  ESTABLISHING BUSINESS REQUIREMENTS THROUGH BUSINESS COMPONENTS

Although the business requirements of the enterprise can be defined through several techniques, the best practice approach should be consistent with the main principles of SOA to facilitate easy integration into the enterprise architecture. Traditional approaches to establishing business requirements have focused on automating established end to end processes. This business process perspective does not force the generalization of common tasks nor help rationalize shared activities. IBM's Component Business Model (HYPERLINK CBM "http://www-1.ibm.com/services/us/index.wss/offering_library/igs/a1005119") design the business as a set of cohesive and loosely-coupled components that can be combined as a network to support the underlying business activities and that can be shared across the enterprise. These business components combine similar activities resulting in increased flexibility and efficiencies. Furthermore, the business component allows a natural transition to a services view and can be elaborated by modeling the underlying business processes.

The business requirements of the enterprise is modeled as a grouping of business components organized into a Component Business Map. Figure 2 shows an example of such a map. The map organizes the components by focusing on business competencies (defined as the columns) and the accountability levels (defined as the rows.) The business competencies define business areas with characteristic skills and capabilities. The accountability levels characterise the scope and intent of the decisions that the business makes on the component – directing focuses on strategy and policy, controlling on tactical and management, and executing focuses on doing the work.

Figure 2: Modeling Business Components

These identified "hot areas" might become input for elaboration of the requirement through techniques like process modeling. For instance, if we determine that Account Administration is an area for improvement, we can develop the initial requirements through articulation of business vision, business goals, and use case specifications. Each "hot area” shows a differentiated competency that can be improved (e.g. through cost control, increased revenue or customer satisfaction) to achieve the desired business results.

A business component (e.g. Account Administration) is defined in terms of the people (e.g. Call Centers, Customers), technologies (e.g. CICS Customer Account and Billing Applications, SAP General Ledger applications), and resources (e.g. Account Data, Customer Relationship Management) delivering specific business value. Business components have well-defined interfaces allowing them to interact smoothly with each other and to be used like building blocks. The description of the business component further elaborates its functional requirements. The business component also establishes key performance indicators or service level agreements (e.g. decrease the time to open an account by half, decrease the cost of opening an account by half) to achieve the desired results.

To complete the business architecture, the business components identified and described in the business modeling phase are used as the requirements to design a SOA solution. This design process is described below.

3  DESIGNING A SOA SOLUTION TO MEET BUSINESS REQUIREMENTS

IBM's Service-Oriented Modeling and Architecture (SOMA) method provides a rigorous, documented analysis and design approach for deriving a SOA solution. The three fundamental constructs of the SOA model that support business and IT alignment 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. SOMA essentially consists of three major steps, as shown in Figure 3:

• Service Identification: Derives and defines the candidate services and flows.
• Service Specification: Selects and specifies the services that will be exposed and the service components that will realize them.
• Service Realization: Elaborates and extends the high-level service model in terms of decisions that can help guide their detailed design and implementation.

Figure 3: Designing a SOA Solution

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 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 consists of the decomposition of the business domain into its functional areas and subsystems, including its flow into processes, sub-processes, and high-level business use cases. These use cases often are very good candidates for business services exposed at the edge of the enterprise, or for those used within the boundaries of the enterprise across lines of business.

Domain decomposition is supported by business process modeling which often takes place following the identification of key business activities arising from business component design. Process modeling usually starts with a business analyst modeling 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. Business analysts then define the to-be (future) process, and can simulate the process to determine run time characteristics including costs, resource requirements, and process bottlenecks. Some modeling tools also support the definition and specification of business key performance indicators (KPI), which facilitate the analyst to translate business component KPIs into the defined business process model. An example of a business process KPI for Account Administration might be stating the average time needed to open an account should be less than a defined number of hours. Process modeling links business requirements and business services to the identification of candidate services.

In the bottom-up portion of the process or existing system analysis, existing systems are analyzed and selected as viable candidates for providing lower cost solutions to the implementation of underlying service functionality that supports the business process. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality. The existing asset analysis technique is enabled via tooling, as well as by reviewing 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.

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, we will focus on 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: Focuses 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: Focuses 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: Focuses 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: Focuses 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.

The definition of the service model consists of multiple steps and normally results in the creation of UML workproducts. 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 phase 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.

4  SUMMARY

About the author

Mahesh Dodani is a software architect at IBM. His primary interests are in enabling communities of practitioners to design and build complex business solutions. He can be reached at dodani@us.ibm.com.

Mahesh Dodani: "The Architecture of Business", in Journal of Object Technology, vol. 7, no. 4, May-June 2008, pages 43-50, http://www.jot.fm/issues/issue_2008_05/column4/