 | Level: Introductory Bertrand Portier (bportier@ca.ibm.com), IT Architect, IBM
15 Nov 2006
Updated 24 May 2007 Learn some basic SOA terminology in this first part of a series.
Bertrand Portier defines terms including service, architecture, Service-oriented
architecture, governance, and business process -- and explains why they are
fundamental to the success of SOA. He also introduces key graphics from the IBM SOA
foundation.
Introduction
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.
Service
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 Resources
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.
Architecture
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:
-
"A formal description of a system, or a detailed plan of the system at
component level to guide its implementation.
-
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
Resources 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 Resources section for links to more
information on the SOA foundation.
Figure 1. The 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 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
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 Resources section for
links to more information on Rational Method Composer.
Governance
"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
Business
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 Resources 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 Resources 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 Resources
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.
BPEL
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 Resources section for a
link.
Industries
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
Resources 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.
Conclusion
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!
Acknowledgements
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.
Resources Learn
Get products and technologies
About the author | 
| | Bertrand Portier is an IT Architect with SOA Advanced Technologies, IBM Software Group. He works in the field on strategic SOA transformation projects and, based on these experiences, works with IBM software group development teams. His background is in J2EE and Web services and he is now heavily involved with asset-based and model-driven development. |
Rate this page
| |
