One of the latest trends in software is the concept of service oriented architecture (SOA). A central idea of SOA is the movement away from technology-oriented solutions and toward business services. By focusing on services, applications are aggregated to provide richer, more meaningful business processes. As a result, SOAs usually reflect a truer alignment with business models. In this article, we'll examine what makes up an SOA and how it's aligned with the business.
The technology- and application-centric view
For some time, business software solutions have been centered on specific technologies and applications. Figure A shows a typical architecture that's focused on technology components. Good examples of this model include database technology, integration technology, CRM applications, and ERP applications.
|A technology-centric view|
Part of the reason for this view is that businesses have been buying software largely from vendors—which, obviously, sell technology and applications. The idea was that a specific technology or application could provide the necessary functionality to complement your business model. There are downsides to this approach. Often, specific applications require the business model to bend enough to fit the software. This approach also moves the focus of IT away from the business model and puts it squarely on the technology. As a result, sometimes you get good technology, and sometimes it's implemented well, but many times, it's not what the business needs.
Business processes and services require multiple applications
A single application does not meet the needs of many businesses, either. Even if the application is a large ERP solution, there will still be gaps where the system doesn't provide particular functionality that's essential to the business. So most businesses require multiple applications to implement their business processes and realize their business model. Services are the view of technology from the perspective of the business processes—as seen from the top down. This is counter to the common view of business driven by the available technology.
Services more closely align with business than applications
The advantage of services is clear: They align with business processes and therefore more accurately represent the business model. Implementing an SOA allows technology to better support the business by aligning with it rather than defining it. The application-centric model forces businesses to limit their capabilities to what the applications can do. With services, the applications support the business and the gaps are filled by other applications.
Services descend from business processes
Defining an SOA is not a trivial task. It is a discipline that requires heavy doses of analysis, strategy, and understanding of the business. Most SOAs are built from the blueprints of an enterprise framework that defines the processes and components that make up the business model.
Enterprise business framework
The enterprise framework is a tool for understanding the business model at a very high level. As Figure B shows, it defines the taxonomy for business processes and how they are organized. In more mature environments, it can also define the priority of the framework components.
|The enterprise framework|
The framework is a view of the components that make up the business model and may include entities outside of the corporation. A true business model does not operate in a vacuum; therefore, the enterprise framework should include touch-points for partners, customers, vendors, and others who interact to create the business model. In the above model, customers interact with the front office components, while vendors and partners are hooked into the extended office components.
An enterprise process is the air that breathes through the enterprise framework, giving life to the components in the business model and more clearly defining their relationships. A process defines a particular way of interacting with the business model. For example, accounting might be a component of the framework—but posting an invoice to a client is a business process.
Services are defined to support the business processes. Throughout the processes, various services will be required to facilitate processing and logic. Understanding the business processes is key to defining services.
Many processes are internal to the organization. Within the framework, these processes stick within the bounds of the corporation. Internal processes use only internal services.
Some processes require interaction with other organizations. These external processes force the issue of business-to-business (B2B) integration. External processes use a combination of internal and external services.
Aligning services with business processes
The challenge of designing an SOA is creating a useful set of services that can support the business model. The services defined in the architecture don't define what processes you can implement; rather, the business processes define what services you need. In addition, a service alone is not good enough. The interaction between services is what creates the implementation of the business processes.
Define services to support business processes
The enterprise framework defines the components of the business model and the enterprise processes define the relationships and interactions between the components of the model. Services provide the next layer down, required to realize the business processes, while applications and technology are farther down the stack.
Create choreography between services to implement processes
Not only do services have to be defined as discrete components but they also have to be defined in terms of the relationships. A process will rarely, if ever, use a single service. Instead, it will use multiple services in a variety of ways. The interaction between services is called the choreography. A series of choreographed interactions among services is the realization of the business process implementation.
Mapping services to applications
Services, in a very basic way, are an abstraction above applications and technology. They provide a logical separation between ever-changing technology and agile business models. The next trick in defining SOAs is understanding the relationship between services and applications.
Catalog application-specific functions
Applications are cornerstones for services. They provide specific functionality that is sometimes configurable. Before you can map services over applications, you need to understand what functionality your application portfolio provides. Many corporations have a complex set of applications for everything from e-mail to accounting to mobility. Cataloging the available features of these applications is the first step toward understanding what you can and can't deliver via services today.
Fill gaps for missing functions
If you're lucky, your application portfolio will provide all of the functionality required to realize your business model. Unfortunately, that's usually not the case. Many companies can recognize at least 80 percent of their services through existing applications, but an elusive set of functions is still required to complete their model. For these functions, you define special applications that fill the gaps in your architecture.
Components of an SOA
A service architecture consists of three primary components. The first is the service provider—the actual service. Next is the service requestor—the component that accesses the service. Finally, the service agency provides registration and discovery services. Figure C illustrates these components.
A service provider is the source of the service functionality. A provider publishes an interface contract that requestors use to access the service. The contract defines what the service does and how you access it.
A requestor is a client to a service. The requestor uses the agency to discovery what services are available. Once a service is located, the requestor retrieves the interface contract from the agency. The client uses the interface contract to understand how to access the service.
A service agency is a registry of available services. Each provider publishes its interface contract to the agency along with information used to locate the service. The requestor searches the agency for appropriate services and retrieves the interface contract.
Building the framework
So far, I've examined the recipe for defining and architecting an SOA. The next step is understanding how to realize the architecture with Web services. In the next installment in this two-part series, I'll discuss how Web services provide the framework for creating service requestors, service providers, and service agencies.
You can get additional information on Service Oriented Architectures by following these links: