Previous column

Next column


The Year of the Globally Integrated Enterprise

Mahesh H. Dodani, IBM Software, U.S.A.

space REFEREED
COLUMN


PDF Icon
PDF Version

1  ENTERPRISE ARCHITECTURE IS THE KEY

"The globally integrated enterprise will require fundamentally different approaches to production, distribution, and work-force deployment. This is already happening. Because new technology and business models are allowing companies to treat their different functions and operations as component pieces, firms can pull those pieces apart and put them back together again in new combinations, based on strategic judgments about which operations the company wants to excel at and which it thinks are best suited to its partners." – Sam Palmisano, CEO, IBM

Thomas Friedman postulates the creation of a flat earth – "a global, web-enabled platform for multiple forms of sharing knowledge and work, irrespective of time, distance, geography and increasingly, language." However, several pundits have pointed out that the concept of the "flat earth" and globalization have been overly exaggerated – "despite talk of a new, wired world where information, ideas, money, and people can move around the planet faster than ever before, just a fraction of what we consider globalization actually exists" (Phankaj Ghemawat.) In IBM, we think that the impact of the "flat earth" is to drive enterprises to become globally integrated (from their current global manifestations as multi-national corporations), where a company designs its strategy, management, and operations by integrating its production and value delivery worldwide. To provide the capabilities to support such a global integration, an enterprise must think of its architecture holistically, and ensure that the component pieces can be combined and used in the ways to facilitate the flexibility and agility that it needs. In this article, we make the case for Service Oriented Architecture (SOA) as the enterprise architecture of the globally integrated enterprise. The following discussion shows how SOA in the context of an enterprise architecture provides the foundation for "componentizing" both the business and IT of an enterprise.

Figure 1 shows the main components of an enterprise architecture, which describes 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 Enterprise Architecture provides the blueprint that can be used by the projects that are undertaken by the enterprise to implement its strategy and achieve its business outcomes. The projects are defined as part of the transition plan which establishes the roadmap (based on appropriate assessments of the enterprise) to move the enterprise from its current state (e.g. multi-national corporation) to its strategic state (e.g. globally integrated enterprise.) This transition is tracked and managed in the context of the enterprises' governance framework that provides the capabilities to ensure that appropriate decisions are being made and that the projects conform to the blueprint.

Figure 1: Enterprise Architecture

Designing and establishing enterprise architectures require:

  • A framework that defines the process and method to design and build an enterprise archtiecture.
  • A set of reference architectures on which the enterprise architecture can be built on.
  • A set of best practices that can be leveraged for establishing and executing the enterprise architecture.

The Open Group Architecture Framework (TOGAF) is probably the most widely accepted, vendor-neutral framework. TOGAF facilitates organizations to build their enterprise architectures to address business needs through:

  • A well defined Architecture Development Method (ADM) that defines the specific activities and tasks to build and evaluate the enterprise architecture, focusing on the business and IT (application, information, and technology) architectures.
  • A set of reference architecture models that can be used as the basis for defining the enterprise architecture.
  • A set of resources that establish the relationship of architectures (e.g. SOA) and standards (e.g. COBIT, ITIL) with TOGAF.

The next key component is a set of reference architectures that can be leveraged to build the enterprise architecture. In previous articles, I have covered the (IBM versions of) SOA Reference Architectures which show how the key principles of SOA are realized to achieve the necessary alignment of IT with business and providing the flexibility within IT to respond with agility to business changes. I will summarize these reference architectures shown in Figure 2.

Figure 2: SOA Reference Architectures

There are two reference architectures shown in Figure 2: the first focuses on showing how an SOA solution is decomposed into appropriate layers, and the second focuses on showing the capabilities that must be provide to support SOA solutions. In the SOA solution layers, the Services layer is the specification of the services that are used by the service consumers and implemented by the service providers. This services layer directly supports the principle of “programming to an implementation not to an interface.” As shown in Figure 2, atomic services can be exposed directly to consumers, or exposed via a business process; and implemented via service components or directly (via a service façade) through the operational systems. The consumer of the service does NOT know how the services are implemented, which facilitates great flexibility in changing implementations without impacting the consumers. The services layer also shows the ability to compose services to achieve increasing levels of behavior. The business process separates collaboration/control behavior and logic from the underlying business behavior and logic that is provided by the services themselves. This approach to separating behavior logic from business logic (especially when defined “declaratively”) supports changing of behavior without the need to re-code the underlying logic. The reference architecture directly handles separation of concerns by providing separate “back planes” that support integration (the ESB), qualities of services, data architecture and governance.

The SOA capabilities reference model in Figure 2 shows the key functionalities that are required to implement comprehensive, enterprise wide SOA solutions and to support the SOA lifecycle (model, assemble, deploy and manage.) The Development Services are used to implement custom artifacts that leverage the infrastructure capabilities, and Business Innovation & Optimization Services are used to monitor and manage the runtime implementations at both the IT and business process levels. At the core of the SOA Reference Architecture is the Enterprise Service Bus which delivers all of the inter-connectivity capabilities required to leverage the services implemented across the entire architecture. Transport services, event services, and mediation services are all provided through the ESB. The SOA also contains a set of services that faciliate the integration of people, processes, and information. Interaction Services provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences. Process Services provide the control services required to manage the flow and interactions of multiple services in ways that implement business processes. Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways. Many of the services in an SOA are provided through existing applications via the Access Services, newly implemented components via Business Application Services, and external connections to third party systems via the Partner Services. Underlying all these capabilities of the SOA is a set of Infrastructure Services which are used to optimize throughput, availability and performance. IT Service Management Services include capabilities that facilitate the management and security of the deployed services, composite applications, and hardware/storage/network resources. These services also provide the capabilities to monitor the deployed environment to collect both technical and business metrics and present these via appropriate “dashboards” for inspection by appropriate personnel and to help them take the necessary actions to optimize the managed environment or the business service/process. Note that all of these capabilities are provided by several well established products and tools. To get a deeper understanding of these capabilities and their support in the products and tools, you can “play” in IBM's SOA Sandbox .

2  BEST PRACTICES FOR THE ENTERPRISE ARCHITECTURE JOURNEY

The final component of supporting the enterprise architecture journey are a set of best practices that can be leveraged to ensure that the enterprise architecture matches the strategy and business needs, and is used as the blueprint to drive projects in the enterprise. The best practices are required to help address the following issues:

  • Transition Planning and Project Prioritization: A key component of the enterprise architecture journey is to establish the business goals, and then establish a roadmap for the journey. It is important to think of this enterprise architecture adoption at two levels. At the strategic level it is important to have a vision or a master plan that can be used by the enterprise as a guideline in to be applied as various interests work together to meet specific business goals. At the tactical level are the individual project plans that are the piece parts of the roadmap. The enterprise architecture will never be established in one big-bang project. Instead it will be implemented incrementally and the business will demand return at each incremental project step. Consequently, the roadmap must have individual project plans to meet the most immediate goals of the business and yet created in a way that is consistent with and helps the enterprise move toward the goals articulated in the strategic vision.
  • Solution Modeling Methods: Just as the object-oriented approach required analysis and design methods, we need similar methods to support solution modeling that is consistent with the enterprise architecture. For SOA, we need methods that facilitates building of solutions that conform to the SOA reference architectures (and therefore embody the SOA principles), and are able to address all aspects of the solution – covering both business and IT.
  • Governance: Any organization transitioning to an enterprise architecture and wanting to be successful will have to deal with big challenges including changes in behavior, ensuring rules and policies are followed; making the right decisions; and facilitating communication and collaboration. In a SOA world, we include challenges in finding, using and sharing services; defining high-value business services; and ensuring service characteristics are appropriately defined and managed. Governance establishes decision-making rights along with the associated policies and mechanism to control and measure how these decisions are carried out. For example, it ensures that the projects have appropriate architectures as blueprints, as well as ensures that the projects conform to the established architectures and principles.
Figure 3 summarizes the best practices to support this enterprise architecture journey, and that directly relate to the three issues shown above. In particular the Service Integration Maturity Model (SIMM) supports the effort of defining the series of projects that need to be undertaken through the journey, the Service Oriented Modeling and Architecture (SOMA) establishes the method that will be used by all projects in designing and implementing solutions that conform to the enterprise architecture, and the Service Governance and Management Method (SGMM) provides the approach of establishing the governance framework to ensure that everything is in synch and kept current.

Figure 3: Best Practices for Enterprise Architecture

SIMM is a maturity model that describes capabilities that an enterprise would need to achieve a required maturity level (defined in terms of how well the services are integrated through the enterprise and its business ecosystem) across several domains (business, organization, methods, architecture, application, information, and infrastructure.) Underlying each cell in the maturity model are well defined characteristics and capabilities needed to support these characteristics. SIMM can be used to understand the current or as-is state of the enterprise as well as the needed or to-be state. A catalogue of projects and capabilities are defined to move from one cell to the next in a given domain. A roadmap prioritizes these projects and creates a step-by-step process and timeline for getting an enterprise from their as-is to their to-be states. Such a roadmap provides the overall blueprint for how an organization will move towards SOA. SIMM has been adopted by The Open Group as OSIMM – a vendor-neutral SOA maturity model. If you want to try doing an initial assessment of your organization, you can use the self guided SOA readiness assessment which is based on SIMM.

SOMA is the methodology that supports the design of SOA solutions. SOMA facilitates the identification, specification and realization of services, components and flows (through choreography of services.) The service identification process consists of a combination of top-down, bottom-up, and middle-out techniques of domain decomposition, existing asset analysis, and goal-service modeling. In the top-down view, a blueprint of business use cases provides the specification for business services. This top-down process is often referred to as domain decomposition, which consists of the decomposition of the business domain into its functional areas and subsystems, including its flow or process decomposition 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. 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 this process, you analyze and leverage API's, transactions, and modules from legacy and packaged applications. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality. The service classification activity is started when services have been identified. It is important to classify services into a hierarchy to reflect that services can and should be composed of finer-grained components and services. Classification helps determine composition and layering, as well as coordinates building of interdependent services based on the hierarchy. It also helps alleviate the service proliferation syndrome in which an increasing number of small-grained services get defined, designed, and deployed with very little governance, resulting in major performance, scalability, and management issues. The service realization step recognizes that the software that realizes a given service must be selected or custom built. Other options that are available include integration, transformation, subscription and outsourcing of parts of the functionality. In this step the decision is made as to which legacy system module will be used to realize a given service and which services will be built from the “ground-up”. Other realization decisions include security, management and monitoring of services. SOMA is available as a Rational Unified Process plug-in , which allows enterprises to use the method as a guide in designing their SOA solutions.

IBM has defined the SOA Governance Lifecycle that facilitates an incremental and iterative approach of determining the focus and scope of SOA governance, defining the governance model to address the scope, implementing the governance model, and measuring & monitoring its effectiveness. SGMM is a method that helps enterprises create their unique SOA governance framework based on merging appropriate best practices with existing IT processes. It includes detailed, step-by-step tasks and recommendations for each phase of the IBM SOA Governance Lifecycle. SGMM allows an enterprise to define the rules, processes, metrics, and organizational constructs needed for effective planning, decision-making, steering, and control of establishing an SOA. The governance model defines what to do, how to do it, who should do it, and how it should be measured. SGMM is available as a plug-in to Rational Method Composer, and allows organizations to customize the method to their own requirements.

In summary, to survive in the emerging "flat earth", organizations must become globally integrated enterprises. To do this effectively requires a focus on enterprise architecture, and in particular an architecture that is based on SOA – to facilitate componentization of the underlying business, and the flexibility in putting these components together in new and interesting ways to meet ever changing business challenges. Establising an enterprise architecture is a difficult journey, and this article has laid out a roadmap of how to get through this journey using established methods and leveraging best practices. Through 2008, I will guide you through this journey to highlight potential pitfalls, and to ensure that you can complete it successfully. Get your minds ready, and hop on to the "enterprise architecture" bus for the ride of your life!

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.


Cite this column as follows: Mahesh Dodani: "The Year of the Globally Integrated Enterprise", in Journal of Object Technology, vol. 7, no. 1, January-February 2008, pages 35-42, http://www.jot.fm/issues/issue_2008_01/column4/


Previous column

Next column