An Enterprise Architecture Strategy for SOA

Hatay Tuna
Microsoft Corp.

September 2009

Summary: This article discusses key concepts and methods that CIOs, CTOs, architects, and IT leaders can put into action pragmatically to help their organizations evolve their IT architecture and solutions, so as to meet ever-changing business needs and demands through service-oriented architecture (SOA). It presents a robust architecture foundation—built on proven and already successful methods and practices—to implement tangible service orientation in a consistent and repeatable fashion, with a focus on business priorities and alignment, to deliver predictable and measurable business value while maximizing value of IT investments.

Introduction

• Where to start and how to begin SOA
• How to align services to business needs and priorities
• How to identify and scope services
• How to enable agility and innovate through services
• How to implement SOA

These are the fundamental challenges that organizations who demand a realization of business value through SOA—whether it is in the form of innovation, growth, revenue, or operational costs—are facing today.

An inconsistent understanding of promises, disconnected approaches to implementation (even among departments within the same organization), and unrealistic expectations of products and technologies become impediments on the road from aspiration to success.

This article introduces and discusses key concepts, principals, and methods that architects can practically put to work immediately to help their companies overcome these challenges and lead their organizations in their journey through SOA implementation for a better outcome.

The concepts and the methods that this article presents are technology-agnostic and compatible with widely available methodologies; they are designed to complement existing capabilities for implementing service orientation on-premise, in the Cloud, or both. Samples are selected from a recent case study for a leading global-recruitment consultancy firm in which these concepts and methods were implemented successfully.

Concepts

SOA is not an end; it is not a production environment that organizations can buy or deploy, after which some singing-and- dancing technologies magically adapt to change and deliver out-of- this-world value.

In fact, SOA is an incremental and iterative journey that organizations need to experience through ways and means so as to achieve predictable ends.

Industry has done a fairly good job in terms of defining the means: standards-based Web services, advancements in middleware products, and integration patterns.

On the other hand, because of the bottom-up and technology- centric perspective that is predominantly driven by software vendors, organizations who want to adapt SOA are left in the dark with poorly defined or no ways—methods and practices that will help them navigate though their SOA implementations.

The following are key, foundational concepts that organizations can embrace as part of their ways to tackle the key challenges that they face and build a robust enterprise architecture (EA) strategy for successful SOA:

1. Abstracting the stable from the volatile
2. Encapsulating the volatile within services
3. Managing change through services—the journey

Abstracting the Stable from the Volatile

Starting SOA is difficult, not to mention figuring out how and where to start implementation in an environment that is, in fact, a web of closely coupled people, IT systems, and business processes. This tight coupling makes change very difficult for organizations that are desperate to move forward and evolve.

Therefore, architects must acquire a new way of thinking and a view of the problem domain, so that they can slice and dice problems into stable and consumable parts that can be addressed through service orientation.

Let us look at the following scenario from the recruitment industry, in point:

A recruitment consultant sends a notification e-mail message to a successful candidate.

The fundamental problem with such requirements is that they do not differentiate between what must be done and how it should be done. In other words, the problem and the solution are closely coupled.

How many times have architects been given problems in such a form and expected to develop solutions to change quickly and cost- effectively?

Capability-oriented thinking can help.

Capabilities Are Abstract

Capability is an abstract view of what an individual business function does; it defines the “what” of the function and is not concerned with the “how.” Capability hides the bewildering details of the:

• People who perform the capability.
• Information technology that supports the capability.
• Processes that describe how the capability is performed.

Abstraction enables organizations and helps architects concentrate on the problem and, then, focus on solutions in terms of people, IT systems, and business processes.

Figure 1 illustrates the capability-oriented thinking about the problem.

Figure 1. Capability perspective

Capabilities Are Stable

Compared to business processes, organizational structures, and IT systems, capabilities are very stable in terms of change. People, IT, and processes are often very volatile and change over time. Capabilities, however—because they represent the abstract view—have a life span of centuries.

Let us go back to our scenario:

A recruitment consultant sends a notification e-mail message to a successful candidate.

In fact, sending an email message is just one way of doing it. “How” it is done varies from organization to organization. However, “what” a recruitment company does has not changed much over centuries; they have always notified candidates of their successful job applications, and they will always notify candidates of their job-application status—even 100 years from now. How they do it, however, may change; in fact, it probably will change.

For example, as Figure 2 shows, a consultant might choose to leave an automated recorded voice message on a candidate’s telephone or send an SMS message.

Figure 2. Change happens; evolution is inevitable (Click on the picture for a larger image)

The nature of such evolution makes capability-oriented thinking an ideal foundation for service orientation to embrace change.

This is the promise of SOA.

Capabilities Have Clear Boundaries

As a consequence of their abstract and stable nature, capabilities form clear boundaries that help architects define the implementation scope of their solutions. Such boundaries enhance the understanding of the relationships between capabilities and dependencies and between their implementations.

A capability architecture—also known as a business-capability architecture or a business architecture—is the decomposition and exposure of the business model that is represented as a capability map that is composed of capabilities. Capability maps represent different granularities of detail, which are also known as levels.

Let us look at the following capability-map sample that a recruitment firm might have:

• Develop products and services
• Generate demand
  • Sales
    • Generate new jobs
    • ...
  • Marketing
  • ...
• Deliver products and services
  • Recruitment
    • Generate new candidates
    • Manage applications
      • Submit application
      • Process application
        • Parse CV [curriculum vitae, or résumé]
      • Notify candidate
        • Notify candidate of application acceptance
        • Notify candidate of application rejection
        • Assess candidates
    • Manage shortlists
    • ...
• Plan and manage enterprise
  • Financial management
    • Billing
    • ...
• Manage collaboration

Capability architectures have three inherent qualities in which architects will be very interested. A capability architecture:

• Abstracts the problem from the solution, where the solution is expected to change.
• Decomposes the problem into different levels of granularity of detail, with clear boundaries.
• Establishes a common language and a vocabulary that are shared between the business and the IT teams.

Building a Capability Map

It is the foremost duty of an architect to embrace this view, and to lead and drive conversations with business representatives—in terms of workshops, interviews, and so on—to develop a map that represents the “what” and not the “how” of the business.

It is important that each level in a capability map represent the same intensity of granularity, so that organizations can drill-down and gather details of a particular capability. For example, organizations might be looking for opportunities for automation. They might be investigating why a particular capability is not performing well. In other words, is it the people, the IT, or the process that is letting down the organization?

Prioritizing and Contextualizing

Capability maps help organizations proactively carry out purposeful analysis and assessment of capabilities to identify and prioritize capabilities that do or do not need attention, based on what is important to business.

Let us look at a sample. Which low-performing capability should the organization address first?

• Match candidate and job
  Business value: High
  Competitive differentiator: Yes
  Performance: Low
  
  Or
  
• Pay employees
  Business value: Low
  Competitive differentiator: No
  Performance: Low

The answer most likely is “Match candidate and job.” In fact, it delivers high value to business and is a competitive differentiator in the marketplace, when compared to “Pay employees.”

This is how an organization might know where to start and align its SOA initiatives with business needs and priorities.

An analytic assessment of capabilities through their attributes provides benefits immediately:

• It enables better, rational, and defensible decision-making to help prioritize the problem.
• It provides contextual information to architects for a better understanding of the problem at hand (what is important to business, what is not performing well, why not, and so on).

Let us remember the basic principles: The “what” is very stable and the “how” is volatile. So, what is next? Why not hide the “how” behind services?

Encapsulating the Volatile Within Services

Service-oriented modeling is a method that connects capabilities to their implementation via services. Capabilities represent an abstract view of what a business or business function does or intends to do. People, IT, and processes collectively make up the implementation of a capability. Such implementations are grouped logically as services.

Service-oriented modeling helps architects productively:

1. Qualify (or map) capabilities to services.
2. Model services, including the components in which they are composed.

Figure 3 illustrates the key concepts of service-oriented modeling.

Figure 3. Connecting business to IT (Click on the picture for a larger image)

Services are composed of service components that implement the capabilities. In other words, a service is a logical group of components that make up the implementation of a capability. A service represents a logical association between capabilities and service components; by doing so, it loosely couples what a capability is and how it must be implemented.

Consider the “Manage applications” capability from the previous recruitment capability-map sample. This capability is concerned with allowing candidates to send job applications with their CVs. Processing includes parsing candidate CVs, extracting candidate information, and matching this information to a job description. If there is a match, candidates are notified of their successful application submission. This saves valuable time for a consultant, who can actually focus on candidates whose profiles fit the job at hand. Otherwise, a rejection notification is sent to candidates whose profiles do not match the job.

After a candidate and job are matched, the recruitment cycle continues (interviews, offers, and so on):

• Manage applications
• Submit application
• Process application
• Parse CV
• Notify candidate
• Notify candidate of application acceptance
• Notify candidate of application rejection

Figure 4 illustrates not only the granularity of these capabilities, but also the interactions among them.

Figure 4. “Manage applications” capability

With this example in mind, let us look at how these capabilities might be mapped to services.

Qualifying Capabilities for Services

Qualification is the process of mapping capabilities to services that are composed of service components that will provide the implementation of the capability.

There are no predefined qualification criteria or contexts that fit all organizations that operate in all industries, or a magic formula that satisfies each and every business scenario. However, the characteristics of capabilities—such as their clear boundaries, purposes, and other attributes—come in really handy when capabilities are being qualified for services.

Figure 5 represents a possible mapping between the “Manage application” capabilities (illustrated as lollipops) and the services that encapsulate their implementation.

Figure 5. Capabilities mapped to services

Moreover, because of the associating behavior between capabilities and their implementation, services also form a logical entity to define the expectations—such as performance, reliability, service-level expectations, quality-of-service (QoS) requirements, or key performance indicators (KPI)—of the capability implementation.

Thus, the performance of capabilities can be monitored and assessed against business objectives.

“Parse CV” from our recruitment scenario is a good example, in point:

• Ninety-percent accuracy (in terms of extracting quality information from CV documents)
• One-thousand CVs per hour

Such attributes and requirements provide architects with vital information and context in terms of selecting the right products and technologies, as well as developing successful architectures. In this case, for example, architects should be looking at technologies that can hit 90 percent accuracy, as well as perform (Parse 1,000 CVs per hour) and scale.

Qualification is a rational, logical, and purposeful activity. When it has been completed, architects can start thinking about developing service-oriented models.

Modeling Services

Modeling is the process of capturing and illustrating relationships, as well as the interactions between services. Service-oriented models include structural and behavioral models to capture and detail different aspects of the services.

For example, the “Candidate-notification service” depends on the “E-mail-messaging service” to send notifications via e-mail, as shown in Figure 6.

Figure 6. Structural model

Structural models represent the decomposition of services in relation to other services—thus, allowing architects to capture dependencies between services, and understand and analyze the impact of change before it happens.

Behavioral models, on the other hand, represent interactions between services within context in terms of business processes, scenarios, use-cases, and so on.

Figure 7 illustrates a scenario in which a candidate applies for a job; the CV is parsed and successfully matched to the job; and the candidate is notified via e-mail.

Figure 7. Behavioral model

Models that are developed at the service level, as opposed to detailed technical models, provide an easy-to- understand illustration and help architects capture the business requirements with clear boundaries, while hiding the complexities of the implementation.

Figure 8 illustrates the logical composition of these services in terms of service components that implement the “Manage application” capability.

Figure 8. Services composed of service components

Table 1 presents the connections from capabilities to services to service components.

Table 1. Composition of services and the capabilities that they implement

Service components can be a combination of devices—for example, mobile phones and printers; hardware components, such as networks and servers; and (last, but not least) software components, such as applications, Web services, and databases. All principals seamlessly apply, regardless of whether a service component is a singleton commercial off-the-shelf (COTS) application, a batch file that runs overnight, a set of Web services that run in the Cloud, or a legacy COBOL application.

Often, it is not an option to ignore existing investments and perform a fresh start; architects must also ensure that existing assets are mapped to capabilities through services, so that they can be managed and reused—in this case, the “E-mail-messaging service” for sending e-mail messages.

Let us build on our recruitment scenario and allow the change to happen. Consider that this organization is looking to transform its “Manage applications” capability by implementing the following changes that the business requires:

• Improvement in the accuracy of CV parsing from 90 percent to 95 percent by using a COTS specialist application
• Use of SMS messaging instead of e-mail messaging
• Extension of reach by allowing candidates to apply for jobs through a mobile application for smart phones

Figure 9 illustrates such a change.

Figure 9. Boundaries are stable

Note the boundaries of services; although the implementation has changed to meet the latest business demands, the scope and boundaries that are inherited from the capabilities remained stable—helping the organization minimize the impact of change and enable room for evolution and innovation.

Mind the Gap!

Service-oriented modeling plays a vital role in bridging the gap between the business and IT—between business architecture (represented as business capabilities) and IT architecture (represented as service components)—by connecting an abstract view of what is done or what must be done to how it is done or how it must be done (see Figure 10).

Figure 10. The missing link in EA—SOA alignment

Also, service-oriented modeling enables loose coupling between business models and technology models to embrace change and, ultimately, enable agility.

Service-oriented modeling has three qualities in which architects will be very interested:

• It connects and loosely couples business models to technology models via services.
• It hides complexities and transformation for IT behind services.
• It accelerates the delivery of services with robust service modeling.

By now, the immediate benefits and practicality of capability architectures and service-oriented modeling might have become clear. Now, let us put these into context and discuss SOA implementation from a life- cycle perspective, and see how these methods can be performed in interactively and incrementally.

Managing Change via Services

Every change has a life cycle, from identification of the business need to implementation to verification of the success after the change. Figure 11 illustrates the key phases through which organizations must go during the life cycle of such a change— transformation of capabilities through services.

Figure 11. The journey—from vision to value

Note that it is better to incorporate SOA-implementation phases (the journey) to existing IT functions, such as Microsoft Operations Framework (MOF), the Information Technology Infrastructure Library (ITIL), the Control Objectives for Information and related Technology (COBIT), and the International Organization for Standardization (ISO). It greatly helps organizations manage the life cycle of services in a structured and systematic fashion with which most IT teams are familiar and comfortable. Also, it allows organizations to leverage their existing people and processes and optimize their thinking for service orientation, without creating unnecessary organizational and political barriers.

Let us have a brief look at these phases.

Step #1: Prioritizing Capabilities and Identifying Services

Service planning is the key phase in which architects must perform capability architecture and service-oriented modeling to prioritize capabilities and model services. The purpose of this phase is to:

1. Identify and prioritize capabilities that require attention, based on business context.
2. Qualify priority capabilities for services and, thus, for service orientation.
3. Model identified services and their key components.

This is the phase in which fundamental challenges are addressed: where and how to start SOA, how to identify and scope services, and so on.

The primary deliverables are approved projects to deliver services that represent the desired change.

Step #2: Transforming Capabilities via Services

Service delivery is concerned with transforming capabilities— implementing desired change via services. Attributes and boundaries of capabilities, as well as service-oriented models, provide vital input to architects and into the delivery phase.

Because service-oriented modeling connects implementation all the way up to business, it enables end-to-end visibility and traceability throughout the delivery phase, and provides teams with a context for the work that they are carrying out.

Obviously, the ultimate purpose of service delivery is to deliver to production reliable services that implement the capability and represent the desired change.

Step #3: Monitoring Capabilities via Service Operations

Service operations focus on operating and monitoring services and their components that are deployed in production. They are concerned with the operational health and performance of services (composition of service components) that represent capabilities.

Organizations must ensure that key service characteristics—such as SLAs, QoS requirements, and KPIs—are continually monitored.

The key outcome of service operations is that the health and performance of services—representing the success of the service, whatever its shape or form—are key inputs and requirements for healthy service planning.

Changes in economy and competition, pressures to cut operational costs, the desire to innovate, and an ever-changing business landscape all drive organizations to focus on priorities and realize value from each and every service that is deployed through increments and iterations. Therefore, here is where you go back to Step 1—not only to drive the next set of services, but also to measure the success of the services that you deployed in Step 2 and that you have been monitoring in Step 3.

Conclusion

Solutions to key challenges in SOA are not hidden in products or technologies; in fact, they can be unlocked by applying a framework of methods and practices (collectively illustrated in Figure 12) to help organizations navigate through SOA implementation.

Figure 12. The big picture—an EA strategy for successful SOA

Let us sum up by remembering the key concepts:

1. Abstract the stable from the volatile.
   Capability architectures help organizations build an abstract and stable view of the business and expose areas that require attention. They help architects abstract and decompose the problem into consumable elements that have clear boundaries.
2. Encapsulate the volatile within services.
   Service-oriented modeling helps organizations connect and align IT to business. It helps architects map capabilities to services— and, then, to IT implementation—and model these services, while hiding the complexities of technology.
3. Manage change through services. SOA is the journey, not the end.
   Organizations must go through incremental and iterative cycles to implement SOA with business needs and priorities in mind.

Whether it is a business capability or an IT capability—and whether solutions are implemented on-premise, in the Cloud, or both— capability architecture and service-oriented modeling both greatly help an organization navigate through its SOA journey. They can dramatically increase the chances of an organization to succeed in delivering a required change—from innovation to optimization to outsourcing to automation to the Cloud—via service orientation, so as to realize the desired value and benefits of SOA.

The people, processes, and IT that make up implementation of a capability will change; they always do and always will. Loosely coupling what is done (capability) and how it is done (service components) via logical associations (services) provides a foundation for alignment, innovation, productivity, and agility.

Loosely coupling business from IT first and, then, loosely coupling systems will enable innovation and productivity that business desperately demands and which cannot be achieved by loosely coupling systems only.

Resources

• Microsoft Corporation. “Michael Page International MPI.” Microsoft Case Studies, July 2009.
• Microsoft Corporation. “ Service-Oriented Modeling.” Architect Insight Conference 2009, May 2009.
• Microsoft Services Business Architecture (MSBA) and Microsoft Services Service-Oriented Modeling (MS SOM) are solutions that are offered by Microsoft Services.

Acknowledgements

Special thanks to my brother, Kutay Tuna (Microsoft Services), for tirelessly reviewing everything that I threw at him and helping to bring out the lousy author in me.

About the Author

Hatay Tuna ( hatayt@microsoft.com) is an award-winning Principal Architect in Microsoft in the UK. He specializes in Software + Services, Service Oriented Architectures, Business Architectures, Modeling, Model-Driven Development and Architectures, Software as a Service, Service Bus Architectures, Process Automation and Optimization, Event-Driven Architectures, and Software Factories. Hatay has a strong passion for innovation, cutting-edge technologies, and future industry trends. He has successfully delivered several solutions in the Government/Public Sector, the Financial Services space, and the Health and Retail industries. Also, he regularly presents at internal and external events, such as TechReady, SOA & Business Process, and Architecture Insight Conferences. Besides work, Hatay enjoys spending time with his family, playing on Xbox 360, watching movies, and reading strictly technical books.

Follow up on this topic

• Microsoft Services. Architecture and Planning