An Enterprise Architecture Strategy for SOA
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.
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.
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:
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:
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:
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:
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:
Capability architectures have three inherent qualities in which architects will be very interested. A capability architecture:
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?
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:
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:
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):
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:
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 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:
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:
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:
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.
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:
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.
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 ( email@example.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
Issue 21 Index