Enabling Business Capabilities with SOA

Chris Madrid
Microsoft Consulting Services

Blair Shaw
Microsoft Consulting Services

 

September 2009

 

Summary: This article describes some methods and technologies for enabling an SOA infrastructure to realize business capabilities and track dependencies between the two, so as to gain increased visibility across the IT landscape.

 

Introduction

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 layers

 

The 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 Bank

 

The 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

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

The 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.

 

References

About the Authors

Chris Madrid ( cmadrid@microsoft.com) is a Solution Architect in the Microsoft Consulting Services Global Practice. Focused on integration, he spends time with customers to grow their SOA maturity through service virtualization and service life-cycle management.

Blair Shaw ( blairsh@microsoft.com) is a Senior Program Manager in the Microsoft Consulting Services Application Platform Optimization Service Line. He has spent the past four years working on SOA solutions with Microsoft customers and partners.


Follow up on this topic

 

Rate this content 

Measuring the ROI of Your SOA

Jeff Niblack

 

The following are two value-based metrics that you should consider the next time that you are asked to report on the IT spend for the SOA initiative of your company.

Consumer-to-Service Ratio

This is a useful metric to track primarily, because each reuse averts the costs of developing, operating, and maintaining a new single-purpose service. As the number of consumers increases for a service, the return on the costs—both initial and ongoing—that is attributed to that service increases.

However, use caution when you report this metric. As the number of consumers increases for a service, the reliance on that service increases, which exposes the enterprise to an increased consequence of failure. Because scalability is the result of design, implementation, and infrastructure choices and investments, as more consumers begin to employ and rely on a service, the workload of that service increases and could potentially move beyond the limits that the service was expecting—thus, increasing the likelihood of failure. Finally, with consumers converging into a single point, the ability of a service to mature over time becomes increasingly more challenging and costly, as any change to the service requires an increased investment in impact analysis, regression testing, and coordination across the enterprise.

Enterprise Adoption Rate

Tracking how services are leveraged across each organizational unit and rolling that information up to the enterprise level provides the enterprise adoption rate. This metric indicates how pervasive the use of services is across an enterprise. However, this metric is not necessarily easy to quantify. For example, given an enterprise that comprises five organizational units, if only two of the units are leveraging services, is the adoption rate of our enterprise at 40 percent? What if 80 percent of the total IT spend is within these two organizational units? Is the adoption rate of our enterprise now at 80 percent?

A more accurate and measurable approach for reporting the enterprise adoption rate begins with a catalog of IT resources that span the enterprise. After determining how many of the applications within the catalog are actually leveraging services, determine the total number of applications that are candidates for an SOA implementation or integration. The product of this review (applications using services/total candidate applications for leveraging services) is a realistic enterprise adoption rate. If the data is available, integration of this metric with actual IT spend provides the weighted enterprise adoption rate, which is an even more compelling value-based metric.


Jeff Niblack ( j.niblack@ratchet.com) is a Team Manager and Architect at Ratchet. He has more than 20 years of experience in dealing with application architecture and design.

SOA Success Factor: Service

VirtualizationSupports SOA Governance

Rama Vangipuram

 

Most every SOA implementation ends up failing to live up to what an enterprise expects of an implementation. The implementation devolves into an unmanageable spaghetti mess of services, with no foresight into governance, visibility, or control. Any benefit that is to be gained and potential return on investment (ROI) can be lost, as IT organizations revert to their old practices. What can an enterprise do to ensure a successful SOA implementation?

There are two keys to make it successful. The first is to have governance over the implementation, and the second is to extend your SOA implementation by leveraging service virtualization. The added benefit of service virtualization is that it helps govern the SOA implementation by providing a dynamic façade by which services are exposed—allowing for reusability of services, and providing policy enforcement through policy assertions. The ability to abstract policy enforcement, such as security or metadata publishing from the service implementation to a policy assertion, is a great advantage.

Abstraction allows developers to focus on the specific business functionality or data to expose as a service, without having to worry about how to enforce certain policies or standards in the service. One example is abstraction of security functionality out of the service to a policy assertion, which enables the development team to have a common security framework to leverage, as all that they would need to do is assign the security policy to their virtual endpoint. Virtualization also frees the developer from having to worry about how a service will be exposed, as logical services can be created that can be exposed through multiple protocols. So, you might ask, “How does this help govern my services?”

There are several key factors that help create a governance model that will stick. Have a board for oversight—developing a framework (standards are the foundation for SOA), creating policies, and enforcing them—and visibility into your services ecosystem. Service- virtualization tools, such as the Microsoft Managed Services Engine (MSE), help in all of those key areas. Virtualization of services helps SOA governance by providing the visibility of the services ecosystem through tools such as MSE—allowing for standardization, such as a security framework through policy assertions—and helps enforce those standards and policies.


Rama Vangipuram is a Senior Manager and SOA Architect at Pariveda Solutions.