SOA terminology overview, Part 1

Service, architecture, governance, and business terms


Content series:

This content is part # of # in the series: SOA terminology overview, Part 1

Stay tuned for additional content in this series.

This content is part of the series:SOA terminology overview, Part 1

Stay tuned for additional content in this series.

Semantics are essential in any domain and especially in Service-oriented architecture (SOA). Since SOA spans teams and organizations, agreement upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts behind them. You will learn the vocabulary necessary to communicate in the SOA field. For each term, you will understand why it is important for SOA, what it means in this context, what the relevant standards are, and how the term differs from others.

A note about organization

The terms listed below are not organized alphabetically, nor are they shown in order of importance. Rather, they are organized in a building-block fashion. We begin with "service", as it is probably the most fundamental concept for an understanding of the SOA framework. We build upon service with definitions of "architecture", "governance", and "business" concepts. In many cases we've broken down the larger terms into their components.


Services are obviously at the heart of Service-oriented architecture, and the term service is widely used. However, it means different things to different people and the question "What is a service?" often leads to long arguments. I have heard people talk about business tasks, business services, application functions, technology services, or infrastructure services. Let me give you a definition, based on the IBM Rational® Method Composer Plug-in for SOA Governance and the IBM Rational® Unified Process for Service-Oriented Architecture. Please see the Related topics section for more information).

"A service is a discoverable resource that executes a repeatable task, and is described by an externalized service specification."

It is a difficult task to start this article by defining "service" because of the variety of definitions it elicits. For example, you may find the above definition too technical. Please bear in mind that it is important not to rely too much on a formal definition of a service, but rather focus on the key concepts behind services, including:

  • Business alignment: Services are not based on IT capabilities, but on what the business needs. Services business alignment is supported by service analysis and design techniques.
  • Specifications: Services are self-contained and described in terms of interfaces, operations, semantics, dynamic behaviors, policies, and qualities of service.
  • Reusability: Services reusability is supported by services granularity design decisions.
  • Agreements: Services agreements are between entities, namely services providers and consumers. These agreements are based on services specification and not implementation.
  • Hosting and discoverability: As they go through their life cycle, services are hosted and discoverable, as supported by services metadata, registries and repositories.
  • Aggregation: Loosely-coupled services are aggregated into intra- or inter-enterprise business processes or composite applications.

These combined characteristics show that SOA is not just about "technology", but also about business requirements and needs.

It is also important to note that not everything is a service. For example, there are IT functions that should not be exposed as services. Analysis techniques such as IBM's Service-Oriented Modeling and Architecture (SOMA) exist to identify the list of appropriate services based on the concepts listed above. We will cover these aspects (including all of the bold terms in this section) in detail in the course of this article.


Like services, it is difficult to find an agreed-upon definition of architecture. However, unlike services, architecture is sometimes forgotten when people talk about SOA, and it clearly should not be! In fact, enterprise architecture and Service-Oriented Architecture share common goals around supporting the business with an integrated IT strategy. Enterprise architects, for example, are key to the success of SOA, as they look at the strategic evolution of an enterprise’s IT systems based on evolving business needs and demands.

The Open Group Architecture Forum (TOGAF) provides two definitions for architecture, based on context:

  1. "A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
  2. The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time."

These two definitions are relevant to understanding the "A" of SOA. Breaking it down even further, we find that architecture is necessary to do the following:

  • Design and model at different levels of abstractions
  • Separate specification from implementation
  • Build flexible systems
  • Make sure business requirements are addressed
  • Analyze the impact of a change in requirements
  • Ensure principles are followed

Enterprise architecture

Here is the definition from Wikipedia:

"Enterprise architecture is the practice of applying a comprehensive and rigorous method for describing a current and/or future structure and behavior for an organization's processes, information systems, personnel and organizational sub-units, so that they align with the organization's core goals and strategic direction.

The primary purpose of creating an enterprise architecture is to ensure that business strategy and IT investments are aligned. As such, enterprise architecture allows traceability from the business strategy down to the underlying technology."

You may think of "architecture" at the project-level, and "enterprise architecture" at the organization level. Note the reference to processes, information systems, personnel, goals, strategy, and business IT alignment.

Service-Oriented Architecture

Service Orientation

As described in the IBM SOA foundation white paper, "... service orientation is a way of integrating a business as a set of linked services." Please see Related topics to learn more about IBM’s SOA foundation.

A key word here is "business". For example, service orientation provides the flexibility of implementing business processes with services from one line of business (LOB), across LOBs, and with business partners.

SOA foundation reference model

The IBM SOA foundation includes an SOA reference model, as in in Figure 1, which shows the key capabilities equired to support Service-Oriented Architecture.

Because this model is itself based on service orientation, it allows for the incremental adoption of SOA as new business requirements arise, starting from small projects, and gradually broadening integration across the enterprise. Please refer to the Related topics section for links to more information on the SOA foundation.

Figure 1. The SOA foundation reference model
The IBM SOA foundation reference model
The IBM SOA foundation reference model

Service-Oriented Architecture

SOA is defined by IBM's SOA foundation as follows:

"Service-Oriented Architecture (SOA) is an architectural style for creating an enterprise IT architecture that exploits the principles of service-orientation to achieve a tighter relationship between the business and the information systems that support the business."

SOA has the following characteristics:

  • It enhances the relationship between enterprise architecture and the business.
  • It allows the building of composite applications as a set of integrated services.
  • It provides flexible business processes.

Service-Oriented Architecture implies new roles in the enterprise, new ways of collaborating, new supporting frameworks and new types of software artifacts in an evolutionary (as opposed to a "revolutionary") way.

SOA solution stack

The SOA solution stack, shown in Figure 2, is an SOA reference model depicting the conceptual (high level of abstraction) view of an SOA solution.

Sometimes referred to as "the SOA layered architecture", this model introduces layers and concepts such as business process, service, or service component, as well as the relationships between them.

It is independent of the technology used for implementation. This separation is important, as you will see in the Model-Driven Architecture (MDA) section in Part 2 of this series.

Figure 2. The SOA solution stack
The SOA solution stack
The SOA solution stack

The five functional layers are as follows (bottom to top):

  • Operational systems: Represents existing IT assets, and shows that IT investments are valuable and should be leveraged in an SOA.
  • Service components: Realize services, possibly by using one or more applications in the operational systems layer. As you can see on the model, consumers and business processes do not have direct access to components, but just services. Existing components can be internally reused, or leveraged in an SOA if appropriate.
  • Services: Represents the services that have been deployed to the environment. These services are governed discoverable entities.
  • Business Process: Represents the operational artifacts that implement business processes as choreographies of services.
  • Consumers: Represents the channels that are used to access business processes, services, and applications.

The four nonfunctional layers are (left to right):

  • Integration: Provides the capability to mediate, route, and transport service requests to the correct service provider.
  • Quality of service: Provides the capability to address the nonfunctional requirements of an SOA (for example, reliability and availability).
  • Information architecture: Provides the capability to support data, metadata, and business intelligence.
  • Governance: Provides the capability to support business operational life cycle management in SOA.

Refer to the "Design an SOA solution using a reference architecture" article for a more detailed explanation of the SOA solution stack.


Governance is necessary for the successful adoption of SOA partly because of the cross-organizational nature of SOA where service funders, designers, implementers, maintainers, or consumers are not located in the same organization, business, IT department, LOB, division, or enterprise.

This section contains definitions from the IBM Rational Method Composer Plug-in for SOA Governance. It defines governance, IT governance, SOA governance, and the difference to management or compliance. It also describes the challenges addressed by SOA governance. Please see the Related topics section for links to more information on Rational Method Composer.


"Governance is about:

  • Establishing chains of responsibility, authority, and communication to empower people (decision rights)
  • Establishing measurement, policy, and control mechanisms to enable people to carry out their roles and responsibilities

Governance looks at assigning the rights to make decisions, and deciding what measures to use and what policies to follow to make those decisions. The decision rights are assigned to roles, not to individuals. Management, on the other hand, includes assigning staff to the roles and monitoring the execution of policies.

Part of any governance solution is meeting the organization's compliance requirements. Compliance is documenting and proving that governance is in place and is being executed: decisions are documented and decision policies are followed."

IT governance

"IT governance refers to the aspects of governance that pertains to an organization's information technology processes and the way those processes support the goals of the business."

IT governance may be characterized by assigning decision rights and measures to IT processes.

SOA governance

"SOA governance is an extension of IT governance specifically focused on services and other SOA artifacts' lifecycle."

Specifically, SOA governance focuses on the methods and processes around service identification, funding, ownership, design, implementation, deployment, reuse, discovery, access, monitoring, management, and retirement.

"SOA governance addresses challenges such as:

  • What new organizational roles and structures facilitate service identification, design, and sharing?
  • What metrics support investment, maintenance, vitality, and sharing of services?
  • How do businesses decide to invest in service creation and maintenance?
  • What is an enterprise’s service-orientation maturity?
  • What education, training, or mentoring is required?"

Life cycle

Service life cycle

Service life cycle comprises the states services may be in and the events that trigger transitions between these states.

Through their lives, services go through many stages or phases (like us ;-) ). Think of a service's life cycle as a business state machine with states (positions) in which services can exist, and transitions that make them evolve from one state to another.

SOA governance is about planning, defining, enabling, and measuring around the service life cycle. SOA governance defines what the service states are, what actions need to happen to move from state to state (transitions), how (processes and methods), and by whom (roles, guards).

For example, SOA governance can define that services states are identified, funded, specified, implemented, approved, operational, published, deprecated, and retired.

The underlying SOA framework then needs to support services through their life cycles and make sure the processes in place are followed. For example, service registries and repositories need to allow users to take action so that services evolve through their life cycle. Collaboration and portfolio management tools need to allow users (and just those who have the rights) to make decisions that will move services from one state to another, and notify users that need to take action.

SOA life cycle

The IBM SOA foundation uses four phases in its definition of the SOA life cycle:

  • Model includes business analysis and design (requirements, processes, goals, key performance indicators) and IT analysis and design (service identification and specification).
  • Assemble includes service implementation and the building of composite applications.
  • Deploy includes application deployment and runtimes such as Enterprise Service Buses (ESB).
  • Manage includes the maintenance of the operating environment, service performance monitoring, and service policy enforcement.

SOA governance and processes , as defined above, underpins these four phases. This is displayed in Figure 3.

Figure 3. The SOA life cycle
The SOA life cycle
The SOA life cycle


Businesses nowadays need to be able to recognize change and react to it quickly while maintaining their ecosystem of employees, partners, customers. Technology needs to be fully leveraged in order to achieve this, as described by IBM On Demand Business . Please see the Related topics section for information about IBM On Demand Business.

Because of external demands such as customers and regulatory compliance, and changes such as competition and markets, businesses have to be flexible and agile. Service-Oriented Architecture helps achieve this and allows businesses to quickly adapt to change.

Business alignment

Key to the success of SOA is the reuse of existing IT assets such as legacy applications. SOA, however, allows businesses to focus their technology efforts on services that will support their business capabilities or processes -- for example, service operations can correspond to business tasks -- as opposed to services based on siloed information systems. This business alignment provides better convergence and easier communication between business and IT. In a later part of this series we’ll cover top-down, bottom-up, and meet-in-the-middle approaches to SOA analysis and design to understand how business models can be refined into IT models, and how key existing functionality can be leveraged.

Being business aligned, however, doesn’t mean having business capabilities and IT implementations tightly coupled. One of the key SOA concepts is loose coupling and the separation between specification (business model, interface) and implementation (technology), which allows for the impact of a change, such as replacing a service provider, for example, to be minimized.

Business componentization

IBM Component Business Model® is a strategic method that allows businesses to focus on core competencies -- the parts of the business that differentiate them from their competitors, see how resources are consumed, and better align business and IT. Please see the Related topics section for more information on the Component Business Model. The integration of these business components’ interaction as well as flexibility, such as outsourcing a component, is needed and achieved with service orientation: business components have a unique business purpose and collaborate through a set of business services they provide to or consume from other components. This can be seen as being part of the "business architecture".

Business modeling

Business Modeling is defined by IBM Rational Unified Process® as follows:

"The Rational Unified Process Business Modeling discipline provides specific guidance on how to describe the "as-is" or the "to-be" business using a number of approaches and techniques at different levels of formality."

Business modeling introduces concepts, deliverables, and roles; it describes and organizes tasks around business strategy, business vision, business objectives, business goals, business vocabulary, business architecture, business analysis and design, business rules, business value, business use cases, business entities, and business processes. The next section offers more details.

SOA is a long-term strategy about reorganizing business and IT systems in order to be able to quickly react to changes. The Related topics section has a link to the IBM Systems journal, volume 44, number 4, on SOA, which offers a more detailed view on the business aspects of service-oriented thinking.

Business process

A business process consists of a sequence of activities that produces a valuable result.

A business process has related business items (data) that flow through it, including those used as the process’ input and output.

Business activities and tasks

Business activities and tasks are the elements that, when connected, make up a business processes.

You can associate duration, cost, revenue, resources, input and output to business activities. They are the elements used to decompose business processes. Service identification techniques include the decomposition of business processes into activities and tasks from which existing or to-be-developed services (and their operations) are identified. These services are sometimes referred to as "business" services.

Modeling business processes

An organization's business processes (current, "as-is") can be complex because they are often the result of a significant number of changes to the process that was originally defined. Understanding, formally defining, and documenting business processes is critical. Also, modeling and simulating "as-is" and "to-be" (future) business processes will allow for the identification of costs, delays, or areas for automation.

Modeling business processes not only provides a visual representation, but when done within a framework that provides underlying metadata, which we’ll cover in Part 2 of this series, it allows for elements of the business process model to later be refined into or linked to IT design elements.

Human tasks

Quite often, human interactions are needed in the course of a process (e.g., travel approval or loan approval). During business process modeling, a task is identified as manual, and different roles are assigned to each of these human tasks. When deployed, the SOA environment will then need to support human tasks as part of the execution of a process. For example, products like IBM WebSphere Process Server will provide users with a list of human tasks awaiting their action. Combined with this, collaboration products like IBM WebSphere Portal and Lotus Sametime will also allow users to collaborate with colleagues if needed, and notify the system of their decision so that execution of the process can carry on. This human aspect is critical to the success of SOA.


IBM, Microsoft and others have contributed to the Business Process Execution Language (BPEL) for Web services specification as a means to formally specify business processes and interaction protocols.

Version 1.1 was published in May 2003, and an OASIS committed draft has been published for version 2.0, now called Web Services Business Process Execution Language WSBPEL. Please see the Related topics section for a link.


Business processes can be specific to a domain or industry, such as an insurance claim process. Industry consortiums define industry business processes. For example, the TeleManagement Forum defines the enhanced Telecom Operations Map (eTOM) for the telecom industry. In addition to these, enterprises can differentiate themselves from their competitors by internally adopting proven business processes like the ones from the IBM Industry Models. Please see the Related topics section for a link to the IBM Insurance Application Architecture (IAA), which is one of the IBM Industry Models.

Business Process Management

Business Process Management (BPM) looks at the full life cycle of business processes to improve their efficiency, flexibility and control.

BPM is about modeling, simulating, optimizing, deploying, running, managing and monitoring business processes before feeding the results back to improve the models and to follow a continuous improvement cycle. IBM WebSphere provides a variety of products needed around BPM.


In this article, Part 1 of the SOA terminology series, we defined the core SOA terms, namely Service, SOA, and how SOA relates to Architecture. We defined two terms, Service Life cycle, and SOA Governance, which are core elements of SOA. Finally,we talked about the relationship between SOA and the Business, and described Business Processes. This is just the beginning. Following parts of the series will define SOA terms related to IT design, development, runtime, and management. So stay tuned to developerWorks!


I would like to thank my IBM colleagues who have contributed a lot to Service-Oriented Architecture and the concepts described in this article. Specifically, I would like to thank Richard D. Johnson and Steve Kinder for their review of this article.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=SOA and web services
ArticleTitle=SOA terminology overview, Part 1: Service, architecture, governance, and business terms