Evolving from business-process reengineering (BPR), business-process management (BPM) was an established discipline well before service- oriented architecture (SOA). Initially, enterprises viewed the two as distinct—often, establishing separate teams that leveraged disparate technologies. Since then, SOA is less about leveraging Web services for faster integration and more about providing an abstraction of information-technology (IT) resources to support business activities directly. This maturity in SOA thinking brings it closer in alignment with BPM.
Enterprises now see this alignment and frequently combine new SOA and BPM projects; however, challenges still exist. While activities in a business process can be implemented as discrete services, there is usually no direct connection between BPM model artifacts and SOA model artifacts, which makes traceability difficult. Enterprise architects have a strong desire to see which processes would be affected if a given service were modified. At the same time, business owners want to see how their investments in SOA are faring. Ideally, they would like to gain visibility into which processes and services support a given business capability such as “Order fulfillment.”
This article explains how Microsoft Services might provide enterprises with the visibility that they want through the application of service offerings (see Figure 1) that would leverage any existing Microsoft Services Business Architecture deliverables. Specifically, the article focuses on how Architecture and Planning services might feed directly into technology-optimization services. By weaving existing Integration (SOA) offerings—part of the Application Platform Optimization (APO) model under Business Technology Optimization (BTO) services—with emerging concepts that are used to drive future requirements, we hope to paint a picture of how you can enable business capabilities today on our stack and how this will only get easier over time.
Figure 1. Services offered by Microsoft Consulting
The Integration offerings are built around the concept of enterprise layers that describes relationships among processes, services, and data in the enterprise. The specific mesh of enterprise- layer items and their relationships in a given environment is referred to as an enterprise service model (ESM). To deliver this ability, we start by mapping items in our ESM to capabilities in a capability model, as described by Martin Sykes and Brad Clayton in their article titled “Surviving Turbulent Times: Prioritizing IT Initiatives Using BusinessArchitecture”in the July 2009 issue of The Architecture Journal. When the mapping is complete, we have a dependency map that we can use to identify which IT resources support a given capability and to understand which capabilities are affected by IT resources. In this case, an IT resource might be a Web service; but it might also be a message queue (MQ) or a mainframe Customer Information Control System (CICS) transaction.
We will continue to use the fictional retail bank, Contoso Bank, which was previously introduced to provide a context for discussing the concepts of enterprise layers and the ESM. As with all businesses, Contoso Bank must perform employee onboarding. The onboarding of an IT resource begins when a start is established after a candidate has accepted an offer and cleared the background check. Onboarding ends when the employee has a telephone number, e-mail address, laptop computer, and cubicle; has registered for HR benefits; and is set up in payroll. Several multistep processes are executed by different groups in the organization to fulfill employee onboarding. In an effort to reduce costs and increase productivity, Contoso Bank has a strong desire to reduce the time that it takes to onboard employees, so that they can start at their jobs more quickly.
Enterprise Layers
The EA team at Contoso Bank structures its decisions and activities around an enterprise-layer model, as shown in Figure 2.
Figure 2. Enterprise layers
The model that is shown in Figure 3 is an evolution of the distributed- (or n-tier–) application architecture paradigm:
Figure 3. Application layersThe enterprise-layer concept extends these areas of concern across multiple applications. Whereas the presentation layer in a single application represents the actionable interface to invoke business logic, it is often asynchronous events in a process that invoke business logic in an enterprise ecosystem. The business layer encapsulates business logic to a specific application. Frequently, enterprise services must coordinate interaction with multiple business services to fulfill an activity step in a process.
The integration layer is where traditional data jobs and enterprise application-integration (EAI) activities take place. The enterprise- layer concept provides enterprise architects with an opportunity to prescribe policies across a given layer and gives them a framework in which to think about dependencies across the entire IT landscape.
After several years, the application portfolio of Contoso Bank is more consistent in approach and architecture, but it still struggles to align with the business. An additional relationship is missing: capabilities.
Business Capabilities
Capabilities do not represent an IT resource or a group of IT resources. They are purely business abstractions that can be accomplished or that are wanted. A given capability might depend on additional capabilities that are to be delivered. The Contoso Bank capability model includes the Onboarding capability. As shown in Figure 4, this capability depends on the following child capabilities:
Figure 4. Capabilities of Contoso BankThe business might choose to model these capabilities at a lower level of granularity and include further child capabilities. In our example, the HR Registration capability could be composed on a Benefit Registration capability and a Payroll Setup capability. These capabilities are pure business abstractions, so that there are no assumptions of how these capabilities are implemented—or even assumptions of whether they are implemented at all.
Modeling Enterprise Layers and Capabilities Capabilities
Artifacts in each enterprise layer can be modeled independently using existing tools in the disciplines of business-process modeling, capability models, and service modeling. Most enterprises would agree that there is benefit in developing their skills in these disciplines. Mature organizations that have established modeling methodologies face new challenges. Often, the business-process models, capability models, and service models are created by using different notations and tools. More importantly (at this point in the discussion), while the models are intended to represent the business and IT landscape, they drift apart quickly and lose value over time.
The Enterprise Service Model
Originally, the concept of an enterprise service model (ESM) existed to rationalize a portfolio of services. The ESM would include a conceptual model of services in the IT environment and services that were planned to be developed and deployed. Challenges immediately existed with the model becoming outdated, because IT employees manually modeled changes in the environment. Also, as enterprises saw SOA aligning closer with BPM, the model had to account for processes and business capabilities—which it often did not, so that its value diminished. The concept of an ESM had to be expanded to keep the model in sync with reality and include capabilities and processes. Today, our concept of an ESM aims to represent the instances of artifacts that are found in the enterprise layers and their relationships with capabilities that are found in a capability model (see Figure 5). Not only are the relationships for specific systems, resources, operations, and capabilities defined, but the ability to affect the real instances is an important goal.
Figure 5. Mapping capabilities through the ESM to enterprise layers (Click on the picture for a larger image)
Each capability can be enabled by one or more processes or service operations. Each step (activity) in a process can be mapped to a service operation. In cases in which an activity maps to multiple services, a façade should be created to manage the coordination of or aggregation to where the activity logically maps to a single service. In our Contoso Bank example, we are attempting to enable “onboarding.” As described earlier, the Onboarding capability comprises child capabilities. However, not all capabilities need to be mapped. If a process or service can be identified that fulfills the entire Onboarding capability, it would be the only one that is mapped. Our customer does not have a single service to fulfill the Onboarding capability.
In the future, Contoso Bank might invest in creation of an onboarding process that would execute in its data center. At this point, the problem is that it is completely conceptual; it might exist in diagrams or described in documents, but there is no concrete IT-resource representation or execution of capabilities. Capabilities exist for traceability and for demonstrating a return on investment (ROI) to business stakeholders. They also aid in strategic architecture planning, by helping IT identify which processes might be leveraged to enable a capability and identify new processes that should be created.
Microsoft Service-Oriented Infrastructure
The process of mapping capabilities to IT resources is powerful. The mapping might help identify gaps in a service portfolio and provide business traceability to service development. As this model become more concrete, moving from diagrams to metadata, it becomes more powerful. Enterprise assets can now develop stronger links—not just at design time, but at runtime.
This is one of the goals of the “Oslo” modeling technologies. “Oslo” is the code name for Microsoft’s forthcoming modeling platform. “Oslo” extends beyond squares and rectangles that cannot be shared across tools to a set of technologies that are focused on enabling gains in productivity. Gains in productivity will come in the form of sharing metadata that is captured through diagrams and runtime environments that will execute metadata that is stored in the repository.
The Integration offering that we introduced earlier includes the service-oriented-infrastructure (SOI) offering that consists of the Microsoft Services Engine (MSE), which allows customers to start establishing their ESM today. The MSE stores information that is related to IT resources in its metadata repository. This metadata includes the location, types, and policies for Web services. It can also include the metadata that is necessary to invoke a CICS transaction through Microsoft Host Integration Server or the metadata that is required to drop a message in an MQ.
As more metadata is imported into the MSE, a more complete picture of the ESM is created. Certainly, there is value in understanding what is in the environment. However, the value in MSE does not come from storing metadata, but from the ability to take this metadata and affect how the environment is constructed virtually. The MSE accomplishes this through its implementation ofservice virtualization. In this context, service virtualization is the abstraction of the address, binding, and contract between the service consumer and the service provider. Because we can hide where the service operation actually resides, change how we communicate with the service operation, and manipulate what the service operation looks like, we can create virtual services.
Adoption of the MSE by Contoso Bank allows them to take operations from disparate services and combine them to create a new endpoint. While Contoso Bank did not possess a single operation or process entry point to fulfill the Onboarding capability, they did have operations to start the hardware, HR, and payroll processes. By leveraging the MSE, Contoso Bank was able to project a virtual service that contained each operation—providing a simple façade that could be developed against, to fulfill the Onboarding capability.
Coming Enhancements
he MSE solution was developed over a four-year period by a team of architects in Microsoft Services who were working with customers and their scenarios. During this period, the MSE solution underwent several releases that added features; updated the ESM; and supported new operating systems, as well as new versions of Microsoft .NET Framework and Microsoft SQL Server. New features were developed in consultation with customers and as a result of frequent meetings with various Microsoft product groups. These meetings helped align the solution with product releases and validate the solution.The result was the filling of a joint patent application that was related to service virtualization and acceptance of the MSE solution into the codename “Dublin” Microsoft Technology Adoption Program (TAP). “Dublin” is an extension of Windows Server that will provide enhanced hosting and management for Windows Communication Foundation (WCF) and Windows Workflow (WF) applications.
In the coming year, MCS plans to extend the ESM to include capabilities as first-class citizens. The ESM will be extended so that business capabilities can be associated with operations. When this is complete, we will be able to get end-to-end visibility—from the business capability all the way to the IT resources that deliver that capability. In our example, we find that the child capabilities are mapped to operations and that those operations are projected as virtual services. Someone who was examining the model would see the need to develop a workflow service to coordinate interaction between the three operations. After the development of that service, it too could be managed by the MSE and mapped to the Onboarding capability for dependency tracking.
As “Oslo” gets closer to release, the MSE will take it as a dependency and leverage the repository to store the metadata that represents the ESM. By utilizing “Oslo,” we will map the virtualized service and operations to the Contoso Bank Onboarding business capabilities. A business analyst or domain expert can start with business capabilities and associate the services and resources that are utilized to perform the specified business capability. The addition of the “Oslo” modeling technology will be a natural extension of the ESM and MSE.
For additional information, please refer to César de la Torre Llorente’s article titled “Model-Dri ven SOA with ‘Oslo’” in this issue ofThe Microsoft Architecture Journal.
Conclusion
Services and applications that were developed over a period of months or even years at Contoso Bank and a variety of different technologies have been utilized. The developers at Contoso Bank followed common architectural patterns for distributed- andn-tier– application development. However, as their business evolves, they face the continued struggle of aligning applications with their business.
By focusing on a business capability such as “Onboarding,” Contoso Bank is better able to align with the applications and business processes. Instead of having to write new applications or application adapters to map to the business capability, Contoso Bank found that by leveraging an MCS solution (the managed-services engine, or MSE), their developers could create new virtual services that align with the business capability. This is possible by modeling the existing services, endpoints, operations, and data entities with the use of the ESM. This process is quickly performed by importing existing services or applications into the ESM; then, new virtual services that align with the business capabilities are defined. Service virtualization enables the composition of multiple physical resources and operations into a virtual service that aligns with the business capability.
Source: The Architecture Journal
For more about Microsft .net consulting, Microsoft .net Outsourcing you can refer to the software outsourcing company website: www.Symbyo.com
No comments:
Post a Comment