1 BUILDING SOLUTIONS TO ALIGN IT WITH BUSINESS"Linking business and IT more tightly offers many benefits, including improved decision-making and corporate agility. The integration of EA [Enterprise Architecture] and MDD [Model Driven Development] enables organizations to develop a seamless workflow that begins with their enterprise architecture, takes into consideration business process analysis, and ends with application modeling and development. This integration encourages the participation of both technical and non-technical personnel in each phase of the EA and application development process, ensuring an optimal solution." – Align Journal – Aligning IT and Business Strategy Over my last two articles, I have laid a foundation for a Service Oriented Architecture (SOA) as the enterprise architecture of the globally integrated enterprise and focused on how to define and establish the business side of the enterprise through a well defined business architecture . Before diving into the IT side of the enterprise, this article discusses how to ensure that the IT aligns with business through architecture. Figure 1 shows the different dimensions of defining a solution – moving from business architecture through a definition of the application architecture, and finally the implementation of the application through a technical or infrastructure architecture. As we have seen in my previous article, the business architecture focuses on defining the strategy and associated processes. The best practice (in the context of SOA) models 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. Typically, the elaboration of the business model also includes a definition of the underlying information (or data) models that are needed to support the business. This information model defines the main business entities and the relationship between these business entities. The business information model provides the foundation for consistency and integration among the various business components and processes..
Figure 1: Aligning IT with Business The application architecture further elaborates services required to implement the defined business model and process. In particular, the services required to implement the business model and process are defined as applications that can be realized using existing legacy, packaged and remote applications and services. The application architecture also elaborates the way that consumers of the business services interact with the process and applications – as defined by the user interface and interaction mechanisms (e.g. via portals, browsers, and mobile devices.) Finally, the application architecture is implemented or realized using the technical or infrastructure architecture. This architecture shows how the processes, services and applications are mapped on the existing middleware and hardware platform. The focus is in realizing the non-functional requirements of the business, including high availability, performance, and scalability. The technical architecture is also concerned with IT optimization, and includes considerations for virtualizing available resources and defining the policies to provision these resources to applications as needed. Increasingly the focus on the technical architecture also includes considerations for environmentally friendly and energy efficient Green Data Centers. The next section discusses the details of how to align IT to business and ensure that solutions are driven by the defined business architecture. 2 AN APPROACH TO ALIGN IT TO BUSINESSOur best practice to aligning IT to business is through the definition of a systematic approach that can translate the business model and processes into a set of service oriented applications. We have described this approach as the Service-Oriented Modeling and Architecture ( SOMA ) technique which provides a rigorous, documented analysis and design methodology for deriving a SOA solution. SOMA is IBM's end-to-end SOA solution development method. 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. How do these constructs constitute a SOA application?
Figure 2 shows the alignment approach. The business model and its associated process, data, and service models, are systematically transformed into a service oriented application that shows how services can be used to expose business services out to consumers of the business services, and in turn how these services are provided through components and existing IT systems. We have discussed how one can use SOMA to identify, specify and realize the SOA application. For example, service identification can be accomplished through domain decomposition, which defines a 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. The identified services are specified and become the layer of services within the application that can be consumed through appropriate business processes or exposed business services, and in turn provided by existing applications, data, and external services. A key component of the alignment is the business process. The business exposes its services either directly or through business processes. Business 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. Using appropriate tools, 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 Administration 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.
Figure 2: Approach to Align IT with Business If the business allows its services to be consumed through exposed business processes, then these processes must become an integral part of the design of the SOA application. In particular, the business process steps are realized by atomic or composite services in the services layer, and external users and systems will participate in these processes through well defined interactions – e.g. through portals. This UI (User Interface) design becomes an integral part of the design of the SOA application – which takes care of both the interaction mechanisms for different types of users as well as the channels that are best suited for their interactions. Note that the business' information model also plays an important role in defining the kind of information needed to support the business services and processes, how this information flows and is transformed through the process, and the definition of appropriate information services that can support the manipulation. The design of the service providers examines existing IT assets that might be considered for implementing functionality specified by the services layer and used to support the exposed business services or processes. Sources of existing assets might include:
Note that assets discovered must be designed as service providers. Most operations are fine-grained even when they are composed services, such as an IDOC or BAPI interactions through SAP. These candidate assets are usually suboptimal in terms of conformance to SOA design principles and will likely be encapsulated by higher level services. The design process includes decisions on how to expose these assets as service providers, and we will cover the patterns and approaches in a later article. The designed SOA solution is then realized by the IT architecture. To the IT solution to the business, we need to ensure that the IT architecture appropriately implements the designed SOA solution. The process of allowing the business to drive this systematic mapping of the SOA solution to the IT architecture is discussed in the following section. 3 BUSINESS DRIVEN DEVELOPMENT OF THE SOA SOLUTIONThe best way to ensure that IT is aligned with business is to have business driven development of the IT solution. This business drive the development approach as it applies to SOA solutions is shown in Figure 3:
Figure 3: Business Driven Development of the SOA Solution A successful SOA implementation within the enterprise requires several things to come together in addition to the alignment of the IT solution to business requirements. It is important for the various practitioners that are involved in the business to have a common understanding of the enterprise architecture as well as the ability of the enterprise to enforce the architectural best practices. As we discussed earlier, it is important across both the business and IT architecture to take advantage of and use existing IT assets, applications and data. Due to the need for many different participants involved through the service lifecycle, it is important to keep solution assets (models, designs, code, tests, etc.) in-sync, aligned, and coordinated. As should be evident from the discussion, the SOA solution is dependent on enterprise assets and best practices – therefore, there needs to be a focus on reusing assets and on harvesting experiences to update the enterprises' best practices. The process requires a early and ongoing focus on quality and testing to ensure consistency and alignment. Finally governance is a key factor in the success to ensure the right decisions are being made as well as the entire process and assets are managed effectively. As shown in the Figure, good solution architecture begins with a solid understanding of the business requirements; which in turn requires a solid understanding of how the business works today, and how it should work in the future. Models (and the associated tools) document the business requirements (and goals and objectives) and create an "as-is" model of the business process. From these models, we can identify deficiencies and pitfalls and create a "to-be" model for how the business can be improved. These models can then be used to simulate the to-be process to validate cost savings, ROI, and other general improvement parameters. Note that governance is integrated into the overall approach to ensure that the business driven approach is successful. Once optimized and validated, the architect exports the business models to the SOA Architect for modeling and design. The architect uses appropriate tools to transform the business requirements into software system requirements and models. This approach will ensure that the system implementation is driven by business requirements and is fully aligned with the business process model. The architect imports the business processes and refines application design based on best practices and existing assets. The architect models and designs the solution following standard methods. Typically, these would include a validation of the business requirements and the systems context in which the solution will reside. The architect next captures the functional and non-functional requirements. The solution architecture is elaborated from logical design through operational models by documenting and making appropriate architectural decisions. It is important that the solution architecture and design are reviewed and validated to ensure alignment with the business requirements and conformance to established best practices. Note that part of the solution architecture design focuses on the information architecture to support the information/data needs of the service oriented applications. The solution design is implemented in two steps. The first focuses on making available the core services needed by the solution – those atomic and composite services defined in the services layer. These service providers will implement the services through existing IT assets, applications and data. Any new services that are needed are made available either through external service providers or by the development of new service providers within the enterprise. Once the service providers are implemented and in place, the business process can be implemented. This requires the appropriate development of the activities, tasks and flows of the process, along with the orchestration of the process and choreography through business rules. Once again, validation of the implementation is a key factor in ensuring alignment with the business requirements along with the enforcement of the enterprises' best practices. We have focused here on the solution design and development process. Of course, the next step in the overall process will focus on deploying the designed solution on to the technical infrastructure. The final step focuses on managing the deployed solution to ensure that the service level agreements as well as the non-functional requirements are being met. In addition, the management of the deployed solution will also monitor the runtime environment against well defined business and technical KPIs (Key Performance Indicators.) This monitoring will lead to automated responses where appropriate to adjust resources as needed to meet business needs and will also provide the approprite feedback to the business to optimize the solution based on actual experiences with the deployed solution. 4 SUMMARYIn summary, aligning IT to business is an integral part of ensuring succesful SOA adoption in the enterprise. This alignment can be tackled at many levels, from associating the business architecture to the IT architecture through the appropriate use of solution modeling and design techniques, to allowing the business requirements and models to drive the development of the SOA solution. In the next article, we continue our journey by looking at the IT architecture. About the author
Mahesh Dodani: "Aligning IT to Business Through Architecture", in Journal of Object Technology, vol. 7, no. 6, July-August 2008, pages 1-8, http://www.jot.fm/issues/issue_2008_07/column4/ |
||||||||
