Service-Oriented Modeling for Connected Systems: Part 1

by Arvindra Sehmi and Beat Schwegler

Summary: As architects, we can adopt a new kind of thinking to essentially force explicit consideration of service model artifacts into our design processes, which helps us identify the artifacts correctly and at the right level of abstraction to satisfy and align with the business needs of our organizations. Here, we offer a three-part approach for modeling connected, service-oriented systems in a way that promotes close alignment between the IT solution and the needs of the business. We'll start by examining the current perspective of service-orientated thinking and explain how the current thinking and poor conceptualization of service orientation has resulted in many failures and generally poor levels of return on investment. Then, we'll examine the benefits of inserting a service model in between the conventional business and technology models that are familiar to most architects, and we'll discuss the Microsoft Motion methodology and capability mapping to identify business capabilities that can be mapped to services. Part 2 of this discussion will appear in Journal 8, and it will show you how to implement these mapped services.

Contents

Five Pillars of Connected Systems
The Old Perspective of Service Orientation Classic System Modeling A New Perspective of Service Orientation Service-Orientation Tenets Models Definition Creating Business Models How Does Motion Work? Motion Methodology Creating Service Models A New Direction Acknowledgements About the Authors Resources

Service orientation is high on the agenda for many organizations. The goal is generally to embrace service orientation to enable better alignment between the requirements of the business and the IT services within the organization and ultimately to enable and support more agile businesses. Today, however, many organizations are failing to align IT services closely enough with the business requirements, and as a result they are failing to see the return on investment that service orientation was expected to deliver.

In addressing service orientation, organizations are attempting to answer these questions: How do we avoid making the same mistakes with service-oriented architectures (SOAs) that previous, hopeful initiatives have resulted in? How do we ensure that the chosen implementation architecture relates to the actual or desired state of the business? How do we ensure a sustainable solution that can react to the dynamically changing nature of the business? In other words, how can we enable and sustain an agile business? How can we migrate to this new model elegantly and at a pace that we can control? How can we make this change with good insight into where we can add the greatest value to the business from the outset?

A key premise we promote here is that to build successful service-oriented systems you need to modify the way you think about service orientation and ultimately about SOA and the way you build your systems. Failing to approach the problem in the right way and getting the thinking wrong up front is arguably the cause of many problems. Without the right thinking, service orientation as an approach is unlikely to deliver the expected benefits.

An essential part of the thinking is about being able to conceptualize your business in the right way, and by doing so you can arrive at solid, well-aligned services that map well onto the capabilities required by your business processes. Having identified the right services, you can go on to implement those services by using your choice of technologies such as those provided by the Microsoft application platform. We'll now look at a model that can be applied to connected, service-oriented systems to promote close alignment between IT solutions and the needs of the business.

Five Pillars of Connected Systems

Messaging is important for service orientation, but it is not the only aspect required to model services, and a number of other pillars exist too. While messaging enables you to connect disparate systems and supplies the underlying connection fabric, there are a number of other important issues that need to be addressed, and additional pillars are required to complement messaging. Let's take a closer look at the five core pillars of connected systems (see Figure 1):

• Identity and access. This pillar is concerned with the notion of federated identity (Web single sign on) and policy-based authorization. It addresses trust relationship management and how access to the systems now connected should be controlled. Governance and compliance regulations are other important factors that need to be given proper consideration under this pillar.
• Data. This pillar addresses entity aggregation and is concerned with providing a single, coherent view of a particular business entity such as a customer, even though the customer data might be duplicated many times across multiple systems.
• Interaction. This pillar is dedicated to the human consumption of services—for example, through the provision of rich, composite user interfaces with online and offline capabilities. Interaction on the edge of networks through the Web, peer-to-peer mechanisms, and mobile devices is also included here.
• Messaging. This pillar provides the underlying fabric of connected systems and needs to support secure, reliable, transacted messaging.
• Workflow. This pillar addresses business process workflow or automation, external to the services themselves. Workflow is concerned with the orchestration of business processes but also with other aspects such as managing user interaction, ad hoc processes, and exception management.

Figure 1. The five pillars of connected systems (Click on the picture for a larger image)

While the three-part model discussed here is largely concerned with the messaging pillar, consideration is also given to certain aspects of the other pillars. Before examining a new approach to connected-systems modeling, it is important to recognize that many of today's problems stem from conventional thinking that needs to change to realize the true benefits of service orientation.

The Old Perspective of Service Orientation

The traditional approach for architecting and building solutions is to take a set of business requirements and from them derive a technology model that typically involves object orientation, component technology, and perhaps mainframe systems. By failing to work closely enough with the business, there is often a large disconnect between the business and the IT solutions provided. Instead of being inward looking, development needs to become an outward-looking engineering discipline.

The other big issue is that while business people might be very good at what they do, it is not their job to describe what they do to people who are not in their business, which is really what is happening when they talk with their IT people about requirements. Historically, business people have not had great tools to help them to create clear, objective requirements. For example, process maps are subjective views that fail to expose a lot of objective content and metrics—and IT needs objective views.

Another problem often occurs because of the way IT departments are organized. Sometimes they are organized according to specific technologies—for example, mainframe, Internet applications, intranet applications, and so on—and other times they are organized around hard human organizational boundaries and departmental boundaries. With both approaches this organization quickly leads to silos, and the way in which information is transferred is largely through prescribed document exchange.

This suboptimal organizational structure also makes it very difficult to create systems that span multiple technologies, and it is very difficult to determine how expensive a solution really is because of the involvement of many people from many different departments.

Figure 2. A classic system model (Click on the picture for a larger image)

To help solve this issue, IT departments need to become more outward looking and more closely connected to the business, and a new way of thinking about service orientation and of modeling connected systems is required. Ideally, the IT department should only provide the infrastructural aspects of the solution, and the solution development should be much more strongly aligned with the relevant business groups. Service orientation and the associated software development process will not on their own enable service-driven organizations. They need to be part of an overall strategy that maps the transition toward service-driven IT.

Classic System Modeling

Today's modeling approaches usually focus on business models and technology models (see Figure 2). Ideally, there is a close correspondence and alignment between the business model and technology model, but in practice this relationship is often not the case. Inward-facing IT departments that do not work closely enough and effectively enough with the business are a key reason. While entity domain models are often used in a layer above the technology model to help address this issue, this approach tends not to work well mainly because they serve two conflicting purposes: internal implementation and business functional exposure. It is arguable that true alignment between the technology and business models is rarely achieved because the gap between the two perspectives is simply too large. So what can we do to close the alignment? Consider these four essential ingredients:

Outward-facing IT professionals. IT professionals must become more outward facing and connect more deeply with the business side of their organization. While they do not need to become experts in the business, they need an objective language that allows them to talk with the business about the business. Architects in particular provide the communications channel between the business and the IT departments, and they need to ensure that business requirements and solutions are as tightly interdependent as possible. This interdependence can be achieved by working very closely with the business to ensure that the contracts that the IT department offers the business are much more aligned with the business requirements. In our opinion, taking this perspective is perhaps the best (if not the only) way to arrive at the right granularity for the services that you ultimately build with a service-oriented approach.

In our common vernacular today we talk about "exposing the business architecture." Since the capabilities of a business in a given industry are very similar, or even identical, both IT and business people can use a standard set of questions to elicit relevant information about the business architecture for requirements gathering. By using a standard set of questions, even nonexperts in a business domain can facilitate a very useful discussion about business requirements and expose important information on metrics, performance, maturity, interconnectedness, and governance and compliance. Because the businessperson is answering questions from the architect, the architect in fact helps to expose a view that the business may not yet have.

Understanding business change. While we don't suggest that all of IT becomes "business-driven" it can be of great value for IT to understand how the business evolved in the past. This knowledge will influence implementation decisions on the provision of extensibility points, versioning, needed resources, and project management issues like number and length of iterations and release management including the major, minor, and delta releases to expect in a given time frame.

A common operational infrastructure. Common infrastructure is required to support business applications that provide holistic, cross-organizational business practices. Building health models for how to operate and manage the infrastructure and deploy applications onto it is vital to success. Healthy applications allow business decision makers to gain key insight into the information that is being moved around among them, which finally enables individuals to collaborate and make decisions to drive the business more effectively.

Web services technology standards. Web services standards enable applications to be connected. Ultimately, the value of connecting the systems leads to more efficient and effective business practices.

A New Perspective of Service Orientation

As architects, can we ensure that the contracts the IT department offers the business are more closely aligned with the requirements of the business? The introduction of a service model in between the business model and technology model is a key factor that can help achieve this goal. The three-part model of service orientation shown in Figure 3 demonstrates an improvement to the classic system model.

Figure 3. The three-part model of service orientation (Click on the picture for a larger image)

The three-part model of service orientation interposes a service model between the business and technology models of the classic system model. The introduction of the service model presents several advantages. The service model is where you can capture the semantics required to express the services that make your solution more loosely coupled and more outward or business facing. The service model provides a logical place to define the contracts that ensure that the business side of your organization is aligned with the IT side from a requirements perspective. By inserting the service model, architects are forced to explicitly consider service-model artifacts in the design process.

The service model helps architects to discover artifacts at the right level of abstraction to satisfy and align with business needs. It also enables the business analyst to have part ownership of the design process and achieve better business-requirements traceability. Lastly, business people already know the word service. For example, in the outsourcing context, a service-level agreement (SLA) is well understood. Internal (not outsourced) functions are similarly understood, though they're (usually) associated with a less-formal, less-contractual service level expectation (SLE). Rather than talking about services and service orientation, it is much better to talk about SLEs because business people will understand their value.

Table 1. The four tenets' requirements and model artifacts

An interesting aspect of the three-part model is that many aspects of the four tenets of service orientation, originally developed at the technology model level, also apply to the service and business levels.

Figure 4. 1) Business function representation, 2) modeling service levels, and 3) implementing the models at different levels of abstraction (Click on the picture for a larger image)

Service-oriented development is based on four fundamental tenets that were originally derived by the Windows Communication Foundation (WFC and previously code named "Indigo") team at Microsoft. The team originally developed the tenets to describe how to use the WCF programming model to build predominantly fine-grained Web services that are more relevant to the technology model than to the other two models. However, we realized they could lend an important perspective to the three-part model when viewed as business service tenets that are applicable at the service- and business-model levels.

Service-Orientation Tenets

The four tenets are: boundaries are explicit; services are autonomous; services share schema and contract, not class; and service compatibility is determined based on policy. Let's take a more detailed look at each.

Boundaries are explicit. Service orientation is based on a model of explicit-message passing, and crossing a boundary is considered an explicit act. To use the analogy of crossing into a foreign country, the act of passing from one country to another is an explicit act. From a business perspective, it is equally important that you understand and define organizational boundaries and function boundaries within your own organization to identify clearly demarcated capabilities. From a service-model perspective, this tenet demands externally consumable service interfaces.

Services are autonomous. Changes made to one service should in no way impact another service. A service should be able to be rewritten without negatively impacting the consumers of the service. To continue the foreign-country analogy, one country is able to introduce a new taxation system independently from another country because they are autonomous. Similarly, at the business level changes to what happens internally within a particular business process should not impact outside parties who are reliant on that particular process or service. Autonomy at the business level also means that individual services can be hosted within an organization or outsourced with no overall impact on the business process. Autonomy at the service-model level requires interchangeable and loosely coupled services. Autonomy at the technology model level requires implementation independence.

Services share schema and contract, not class. This tenet is largely concerned with services not exposing their internals. For example, countries publish the rules required to complete their visa forms but do not provide the internal resources to complete them. As another example consider J2EE and .NET interoperability. This interoperability is not possible if you try to interchange platform-specific types, but rather an intermediate metamodel or schema is required.

Service compatibility is determined based on policy. At the business model level, this tenet is essentially concerned with governance and SLAs and their definitions. Policy defined at the meta level describes the semantic capability of a service based on a set of explicit statements of its capabilities.

Each of the tenets plays an important role across the three-part model and in different ways influences the business, service, and technology models. Table 1 summarizes the needs and artifacts within each model in relation to the four tenets. Let's see what each model defines and how you should approach their creation.

Models Definition

The three-part model of service orientation must be able to represent what a particular business is capable of—its key functional capabilities—rather than how the capability is performed. We'll discuss what a business capability is shortly. The way in which the business function within an organization is represented at different levels of abstraction by the three models is shown in Figure 4.

Business function. From the perspective of the business model, what a business is capable of is expressed by identifying business capabilities. Identifying the capabilities of an organization is a critical task while developing the business model. Capabilities and approaches for determining capabilities within an organization will be discussed later.

Figure 5. The base framework for constructing a capability model (Click on the picture for a larger image)

The functional capabilities have a close relationship with the service contract description defined within the service model. Further down the abstraction level this relationship translates to a description of the service interfaces and ultimately the service implementations within the technology model. (Note that while there is a strong correlation between a capability and a service, it is not necessarily one to one.)

Service levels. To ensure compatibility and consistency across the models, the notion of service levels is introduced. At the business-model level, SLEs define the expected levels of service. These are business expectations. When you subsequently build a software system to provide the service, the SLE is translated into an SLA. At the technology-model level the SLAs impact how you host the service and how you manage the service.

For example, if your business expectations or SLAs are very demanding, then it would be inappropriate to host your service on a single processor server offering no redundancy. The expectations and agreements drive the availability, reliability, security, and manageability requirements of your solution. Similarly, if the business views the system as mission critical, this status places additional onus on the management capabilities that you put in place for your solution. The way in which service levels are represented within each of the three models is shown in Figure 4.

At the business model perspective the expectation can be provided with both qualitative and quantitative information. The fidelity from qualitative to quantitative information becomes more specific as you move toward the technology model. You effectively lose information as part of your descriptions. However, the benefit of having a set of connected models, particularly if they can be described at the meta level, means that you still have the capability to understand where requirements originate and what is related to what.

Implementation. You need to be able to describe how you are going to implement the models and express them in detail. Within the business model you need to express the externalized business processes that you have identified, and then you need an orchestration mechanism to describe the business processes in the service model. When you then implement the orchestrations you need some form of technology workflow implementation or orchestration engine. For example, on the Microsoft platform, you could use the orchestration services provided by Microsoft BizTalk Server (see Figure 4). Though we may imply automated workflows by talking about orchestration, we do not exclude manual or human workflows as a form of implementation in the technology model, which becomes obvious during the business model process definition.

Creating Business Models

To create an effective business model, you need to be able to conceptualize the business and identify its core business functions. Doing so enables you to arrive at well-aligned services that map closely to your business requirements.

Capability mapping. This technique was developed and refined by Microsoft to help conceptualize the way a business works and to help create business models. A business capability models what an individual business function does. It is not concerned with how the business function is achieved, but rather with its externally visible behavior and its expected level of performance (that is, its outcomes). A key benefit in focusing on business capability is that while organizational structures and process flows come and go the essential capabilities of businesses tend to remain constant over time. A business capability abstracts and encapsulates the people, process, procedures, and technology associated with a given business function into a simple building block. The decomposition of the business into capabilities provides the top-level decoupling for the underlying service contracts.

Pay supplier, dispatch product, and generate invoice are examples of business capabilities. At a high level of abstraction a business capability is essentially a black box with certain parallels to services. For example, both have connections that are important and related to, but separate from, their inner workings.

Developing capability models. A capability model is a nested hierarchy of business capabilities that enables you to model the business as a structured network of capabilities, as opposed to a physically integrated network. A business capability model is a diagram that describes the network of capabilities used by the business. The framework used to construct a capability model at varying levels of abstraction is shown in Figure 5.

The level of abstraction with which you can view a business capability varies. Level 1 capabilities are the foundation capabilities common to most organizations, regardless of industry sector. Levels 2 and 3 (and beyond) provide additional levels of detail on business capabilities. Before examining each level in more detail, note that it is not necessary to decompose all capabilities to the same level of refinement; rather, it's necessary to focus on those most relevant to the problem or area of business that's under consideration.

Level 1 foundation capabilities. Having studied business across many industries, Microsoft has found that at a high level of abstraction businesses within most industries exhibit five core capabilities together with a set of operational and environmental capabilities, collectively referred to as foundation capabilities (see Figure 6).

The five foundation capabilities common to most businesses are develop products and services, generate demand, deliver products and services, plan and manage the business, and collaboration. The fifth capability, collaboration is the process that orchestrates and coordinates all of the other business capabilities. It is called collaboration because the process can be automated or manual. The process is essentially an orchestration over capabilities.

The foundation capabilities also include operational capabilities, which are the things inside of the physical business boundary of the organization, and environmental capabilities, which are all of the other people and companies who interact with the business that are outside of the physical boundary of the business. These entities might include customers, partners, service providers, and regulatory authorities. They are significant because they all have capabilities that influence the way in which you conduct your business.

Figure 6. Foundation capabilities common to most businesses (Click on the picture for a larger image)

Note that the business boundary is not the same as the physical boundary of the corporate entity. For example, if something is outsourced it is still part of your business architecture; although, the work is performed by someone outside of your company. There are some interesting examples of work being moved to the other side of the business boundary such as airport check-in, a function that is now performed frequently by the customer; it is the same capability and has the same SLE. However, there is now different technology and that has allowed different people to perform the work, in this case the customer. This holistic view of the entire ecosystem of capabilities empowers organizations to see a much wider range of options that can inform specific changes they make to their business.

Level 2 capability groups. Capability groups provide the next level of detail in the capability model. Level 2 is where initial analysis begins because it is the level that introduces SLE and impediments and constraints between one capability and another; organizational ownership; and accountability. You also identify the inputs, outputs, supporting functions, and controlling functions.

This example starts with the core capability 3, deliver products and services, and shows a nested hierarchy of capabilities at level 3…n:

3. Deliver products and services
     3.1 Provide service
     3.2 Advanced planning
     3.3 Procurement
           3.3.1 Sourcing and supplier contract management
           3.3.2 Purchasing
                3.3.2.1 Request resources
                3.3.2.2 Acquire/purchase resources
                3.3.2.3 Manage suppliers
           3.3.3 Receiving of indirect/capital goods
     3.4 Produce product
     3.5 Logistics

Notice how capabilities are always labeled within their appropriate parent grouping. A capability group is often an important initial level for doing analysis because it is at the capability group level where SLEs, impediments and constraints, organizational ownership, and accountability can first be abstracted and made actionable.

Level 3 business capabilities. Capability groups are subsequently decomposed into business capabilities. By mapping individual business capabilities onto a capability model (see Figure 6), you end up developing a nested hierarchy of business capabilities. Capabilities that reside at level 3 and below are the building blocks of the model.

Business capabilities can be decomposed into more granular business capabilities—for example, when more detailed attributes need to be defined. Within the analysis you may decompose some business capabilities to very detailed levels (level 4 and beyond) and aggregate other capabilities at level 3. It is not necessary to decompose all capabilities to the same level. Equally, you do not need to model your entire business. You can pick and choose areas of your business to model based on current business objectives and project requirements.

For each capability that is ultimately identified, you define a set of attributes to describe and document the capability. Some of the key attributes you need to capture for each capability include: Who owns it? Who is its customer? What are the inputs and outputs? What are the required exception-handling and exception-notification mechanisms? What are the performance requirements (past, present, and future)? Are there governance and or compliance implications? Does the performance of the capability impact directly the performance of its parent capability? Its department? The entire organization? What causes the capability to perform the way it does? People? Process? IT? A combination of these causes? And, is the capability part of why customers, partners, or suppliers do business with the organization?

Figure 7. Contract artifacts defined by the service model (Click on the picture for a larger image)

Capturing attributes such as these help you to define SLE at the business level and then SLAs at the service level. This rich description of the capabilities can be passed to development teams who can use the information to help select the appropriate implementation technologies, hosts, and deployment topologies, based on business-driven SLE.

Capabilities to services. One of the key benefits of the capability modeling approach is that it enables you to identify the stable elements of your business to model your architecture around, and it provides a critical layer that closely aligns the definition of services in your connected systems architecture. You can draw boundaries around capabilities—for example, at the group level—and express each capability with contracts. You can then expose these as services and create an orchestration across those capabilities by using the service contracts.

While capability mapping is an effective way for you to analyze the current state of your organization, you can also build a capability map for a desired future state of your organization, and work out how to transform your business to improve its agility. As an example, consider outsourcing. By dividing the capabilities into those that are core for your organization and those that are not, through a process of re-engineering you can decide to outsource non-core capabilities to other organizations. The important thing from an organization's perspective is that the architecture supports business process change and not capability change. The overall business capability remains intact.

How Does Motion Work?

Microsoft Motion methodology does not encourage you to focus on factoring organizational structure, tools, or processes directly into the capability model. Rather, it provides an effective way to help you arrive at appropriate implementation solutions. The methodology defines these four steps at the top level:

• Establish the project context. You start by documenting project objectives, then generate a foundational capability map, and correlate your project objectives with the foundational map capability.
• Understand the business. There are two parallel efforts: capture current business views, which normally involves interaction between the business people and IT people; capture business architecture detail, which at this stage you start to build your top-level capability map.
• Complete the "as-is" business architecture. At this stage, you add more detail to create a business architecture.
• Identify the recommended next steps. You might be complete at this point, or you might have identified the need to apply process improvement techniques, business process outsourcing analysis, and so on.

The methodology is sometimes referred to as a "phase-gate methodology" because there are distinct criteria that you must be able to satisfy before proceeding to the next phase. It is also important to realize that the methodology encourages iteration at each of these stages. Having completed the stages, you then use the information that you have discovered to construct your subsequent model (see Resources for further information).

Motion Methodology

Microsoft has developed a simple, project-oriented method called Motion for exposing your business architecture through building capability maps. Motion is a methodology to organize, measure, and evaluate business capabilities. The four elements of Motion are tools and measures, prescriptive methodology, business capability mapping techniques, and patent-pending model.

The methodology describes what the business does in the form of business capability as opposed to how the business does it in the form of people, process, and technology. Motion helps expose the business architecture of an organization and isolate the elements of the business that define the business model and drive performance and differentiation. Business model and business architecture are separable, and Motion helps organizations expose both, letting them better manage change.

For example, consider two companies in the retail industry. They have the same capabilities, but one might make profits from volume product sales and the other makes all of its money from a membership fee it charges customers. While the industry is the same, both companies have very different business models. Applying retail industry best practices to one will create value in one organization, and destroy it in another. Thus, having a clear and detailed understanding of the business model is very important.

Motion describes how you extract and document structural and process-oriented information alongside individual capabilities. It provides the guidance for performing the modeling activity itself and includes a large number of templates to help you document all of the required information around each capability (see the sidebar, "How Does Motion Work?").

The methodology also provides guidance to show how it complements a number of existing business process improvement frameworks including business process re-engineering, Six Sigma, Lean, and the Zachman framework. Not only does Motion do things these models don't do, it helps with things those other models were never intended to do.

The key to understanding why Motion is different is in understanding capability mapping and how it differs from process mapping. Capability architecture, and not process architecture, is at the core of the Motion methodology. By initially abstracting (even ignoring) processes and analyzing business capability, you can derive an inherently more stable view of your business that is particularly valuable from a versioning standpoint. Capabilities subsequently become the building blocks for processes.

Looking beyond current practices, many of which do not support the rapid rate of change inherent within business today, the Motion methodology was developed as a business architecture methodology that could handle the present and coming challenges of the connected economy.

The Motion methodology defines approximately 80 attributes to help document capabilities. Some of the attributes you should document for each capability were listed previously in the discussion of level 3 business capabilities.

The primary benefit of documenting capabilities in a detailed and consistent way is it gives you a solid understanding of the SLE that the business has for each of the business capabilities. This understanding subsequently allows you to derive SLAs, which in turn helps you to determine the most appropriate implementation technology and deployment topology for the service implementation. Having the full and detailed description of each capability allows your technical teams to implement the solution in the correct way.

Creating Service Models

Given a business model, then, the question now becomes how can you translate that business model into a service model that you can ultimately implement? Before examining an approach that enables you to do this translation, let's consider what you need to define to create a service model (see Table 1). The key contract artifacts that are outputs from service-oriented analysis and design and captured by the service model are shown in Figure 7. Note that only the abstract (technology-independent) artifacts need to be captured for the service model. The underlying transport and endpoint is defined within the technology model.

At an abstract level you need to understand and identify entities, messages, and interfaces. What are the entities contained within the data that is passed as messages during the interaction among business capabilities? What are the messages that need to flow among the different systems? What are the interfaces that business capabilities, and ultimately services, expose?

At the concrete level, the technology model then defines what the underlying transports are and how you should expose the endpoints of a particular capability, which ultimately translates to a service. Within the service model and from a service-definition-language contract perspective, you also need to understand and identify the data types and port types.

To identify and document the preceding items in a service model, you do not need to use radically new analysis techniques. Rather, you can use existing skills such as conventional object-oriented analysis and design (OOAD) skills applied at a different abstraction level to accommodate service orientation rather than object orientation.

With pragmatic, service-oriented analysis and design (SOAD), creating service models does not require completely new methodologies and new approaches. Rather, you can reuse existing skills, and particularly those associated with UML and conventional OOAD. A change of emphasis is required though. You must move away from thinking about RPC-style method call interactions among objects toward message-based interaction among services. By doing so, you can take classic UML-based OOAD and apply it at the business-abstraction level to create your service models. The key difference between SOAD and OOAD is SOAD clearly separates process and entity to decouple services. Decoupled services are more agile and reflect the reality of real business practices.

For example, consider how conventional UML models can be applied to service-oriented analysis and design:

• Use cases including activity diagrams are derived easily from the task and activity descriptions provided by the capability model.
• The collaboration model gives you a good understanding of the process that needs to be enacted between the tasks and activities, which help you to arrive at your orchestration requirements.
• The interaction model or sequence diagram provides information about the underlying message-exchange patterns (synchronous request/response, asynchronous duplex, and so on) that need to occur among the services. It also helps you to start to derive the externalized canonical domain model, which defines the schema for the data on the wire that goes into the messages. With this information, you can start to define service contracts.
• The component model sketched at an early stage helps focus on operational issues and needs, taking into account the organizational structure and the capability (service) responsibilities and owners. It captures important information for availability, reliability, and scalability from a business perspective and helps to review SLE and SLAs.

By using a pragmatic SOAD approach, you can extract all of the necessary pieces required to build your service model. This extraction includes service contracts, SLAs derived from the SLE defined for each business capability, and the service orchestration requirements. With a detailed service model closely aligned with and derived from the business model, you should now be well placed to map the service model to a technology model that identifies how each service will be implemented, hosted, and deployed.

The second part of this discussion will be published in the next issue of The Architecture Journal, and it will demonstrate how by using the preceding approach and by creating the service model, you can hand over to your IT department data schemas, service contracts, and SLA requirements to inform the definition and ultimately implementation of the technology model.

A New Direction

The old way of thinking about service orientation is not working, and a new way of thinking is required. By adopting this new kind of thinking, as architects we can force explicit consideration of service model artifacts in your design process, which helps you to identify the artifacts correctly and at the right level of abstraction to satisfy and align with business needs.

From a modeling perspective, the gap between conventional business and technology models is too large, which is a key contributing factor to the failure of many service-orientation initiatives. We've presented a three-part model with the introduction of a service model in between the business and technology models to promote much closer alignment of your services with the needs of the business. With a detailed service model closely aligned with and derived from the business model, you are well placed to map the service model to a technology model that identifies how each service will be implemented, hosted, and deployed. Capability mapping and the Motion methodology provide an effective way to identify business capabilities and ultimately services. The decomposition of the business into capabilities provides the top-level decoupling for the underlying service contracts, and not the other way around as it usually is today.

Connected systems are instances of the entire three-part model, and they respect the four tenets of service orientation. They can be more completely implemented by using the five pillars of Microsoft's platform technologies. Recall that we asked upfront: How do we avoid making the same mistakes with SOAs that previous, hopeful initiatives have resulted in? How do we ensure that the chosen implementation architecture relates to the actual or desired state of the business? How do we ensure a sustainable solution that can react to the dynamically changing nature of the business? (In other words, how can we enable and sustain an agile business?) How can we migrate to this new model elegantly and at a pace that we can control? And how can we make this change with good insight into where we can add the greatest value to the business from the outset?

Service orientation with Web services is only the implementation of a particular model. It is the quality and foundation of the model that determines the answers to these questions.

Acknowledgements

The authors would like to thank Ric Merrifield (director, Microsoft Business Architecture Consulting Group), David Ing (independent software architect), Christian Weyer (architect, thinktecture), Andreas Erlacher (architect, Microsoft Austria), and Sam Chenaur (architect, Microsoft Corporation) for providing feedback on early drafts of this article. We would also like to show our appreciation to Alex Mackman (principal technologist, CM Group Ltd.), an excellent researcher and writer who helped us enormously.

About the Authors

Arvindra Sehmi is head of enterprise architecture in the Microsoft EMEA Developer and Platform Evangelism Group. He focuses on enterprise software engineering best practice adoption throughout the EMEA developer and architect community and leads architecture evangelism in EMEA for the financial services industry. Arvindra is editor emeritus of The Architecture Journal. He holds a Ph.D. in biomedical engineering and a Masters degree in business.

Beat Schwegler is an architect in the Microsoft EMEA Developer and Platform Evangelism Group. He supports and consults to enterprise companies in software architecture and related topics and is a frequent speaker at international events and conferences. He has more than 13 years experience in professional software development and architecture and has been involved in a wide variety of projects, ranging from real-time building control systems and best-selling shrink-wrapped products to large-scale CRM and ERP systems. For the past 4 years, Beat's main focus has been in the area of service orientation and Web services.

Resources

"Modeling and Messaging for Connected Systems," Arvindra Sehmi and Beat Schwegler
A Web cast of a presentation at Enterprise Architect Summit—Barcelona (FTPOline.com, 2005)

Obtain a case study on Microsoft Motion methodology by sending a request to motion@microsoft.com.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.

© Microsoft Corporation. All rights reserved.