This research note is restricted to the personal use of A01318614@itesm.mx.

G00155097

Five Principles of SOA in Business and IT

Published: 8 February 2008

Analyst(s): W. Roy Schulte

This research explains the underpinnings of service-oriented architecture

(SOA) in nontechnical terms. Business managers should understand the
basic principles of services and how they influence the design of business
processes and SOAbased IT systems.

Key Findings
A business function is a business "service" if it is designed and implemented using the five
definitional principles of service orientation it must be: modular, distributable, clearly defined,
swappable and shareable. A software function is an SOA service if it is implemented using
these same five principles.
None of these principles is particularly surprising or new, but they collectively represent an
important theme in the evolution of distributed computing.
The service concept is used in the design of SOA application software for most of the same
reasons that it is beneficial in organizing business processes outside the IT organization.

Recommendations
Use SOA when designing most large, new business applications and processes.
Use SOA when integrating a combination of purchased packages, legacy applications and
services from other business units.
Do not discard non-SOA applications in favor of SOA applications, unless there are compelling
business reasons why the non-SOA application has become unsatisfactory. Continue to use
non-SOA styles for some new, tactical applications of limited size and complexity and for minor
changes to installed, non-SOA applications.

Analysis
This document is an updated version of the document published on 18 December 2006.

This research note is restricted to the personal use of A01318614@itesm.mx.

 This research note is restricted to the personal use of A01318614@itesm.mx.

What You Need to Know

The general notion of "services" is well-established and widely used in business organizations.
When applied in the realm of software development, SOA is defined as the simultaneous use of five
well-known design principles that parallel those commonly implemented at a business level. SOA
helps those designing software for essentially the same reasons that the service concept helps in
organizing business services. SOA is not a new idea in software development, but its use was
limited to leading-edge organizations until recently. "The Business Impact of Service-Oriented
Architecture" explores the practical implications of SOA in more detail.

Context
Companies structure many parts of their business operations as services. For example, they use
cleaning services, copy services, package and mail courier services, legal services, security
services, personnel recruiters, auditors, advertising agencies and travel agencies. The service
concept is a way of organizing work that improves an organization's flexibility and efficiency. One
party, the service provider, performs a function to assist another party, the service consumer. At a
business level, a service provider is a department, workgroup or some other business unit. For
example, the HR department provides recruiting and other personnel-related services to other
business units. Similarly, the IT department is a service provider to other business units. Some
service providers are part of the company (they are an internal department, for example) and others
are part of another company (that is, the work is contracted outside the company, or "outsourced").

In this context, service consumer refers to a business unit that uses the service; it does not mean a
private individual person acting as a customer (another common use of the term consumer). The
service is the consumer's view of the provider's capabilities. A business unit can be a service
consumer in some relationships and a service provider in others. For example, the travel
department is a consumer of the cleaning service every day, and it is a service provider to the
accounting department when, for example, an accountant needs to travel.

Business Levels of IT
A well-designed service, whether at a business level or an IT level, has five key characteristics.

Modular
There is a separation of concerns so that the work of one service provider is distinct from the work
done by other providers (or by the consumer). Each service provider is largely autonomous,
addressing one function or a set of related functions. Providers are more effective because each
specializes in one kind of work. Complicated jobs are accomplished by combining multiple simpler
services. This makes the company's organization and its business processes easier to understand,
manage and change by mixing and matching different combinations of services. The lack of
entanglements also contributes toward making components swappable because a service provider
can be replaced without causing unintended side effects. For example, a company can replace its
advertising agency without bringing in a new cleaning service because they are unrelated.

Page 2 of 6 Gartner, Inc. | G00155097

This research note is restricted to the personal use of A01318614@itesm.mx.

 This research note is restricted to the personal use of A01318614@itesm.mx.

At an IT level, SOA applications consist of multiple components, each of which is an application

program or package of application programs, along with the data relevant to the component's
function. Each component is a service consumer, service provider or both. As with business
services, the capabilities to specialize, mix and match, and swap components are key benefits.

Distributable
Business services, whether outsourced or insourced, are spread out over multiple physical
locations. The service provider often does not reside on the consumer department's floor, although
some sections of its work may be performed locally. This is important because a single service may
be used by multiple consumer departments and cannot or should not be physically contained in any
one of them.

Similarly, the software components in an SOA application are almost always hosted on disparate
computers in different locations, often miles or even continents apart. SOA applications are
inherently distributed applications (or at least they are designed to be distributable, even if they
may, in rare cases, run on one computer).

Clearly Defined
A service contract defines the function that will be performed, and describes the terms and
conditions to which the consumer and provider have agreed. The contract may specify things such
as timeliness, quantities, quality, price, hours of availability and reliability. If another company
provides the service, then the contract is usually carefully written. If a department within the same
company provides the service (insourcing), then the contract is often less formal but services should
generally still be documented. For example, a catering service posts the cafeteria's hours of
operation, menu and prices. This contract helps both parties (the caterer and the employees who
eat at the cafeteria) understand what they are supposed to do, and it provides a basis for measuring
and reporting performance.

At an IT level, an SOA service contract is always explicit and formally documented in software. SOA
consumer and provider components are usually developed by different people, often working in
different locations and sometimes for different companies. Software developers write or generate
technical interface descriptions (interface metadata) so that another developer can find and use the
service. Interface metadata describes the format of the input and output messages, the sequence
and nature of the message exchanges, the communication protocols and service-level agreements,
such as promised response times. The single most common mechanism for defining SOA interfaces
uses the Web Services Description Language, although other alternatives can be used. Software
interface definitions are usually maintained in a registry or repository that is available to many
application developers.

Swappable
The service contract is separate from the design of the service provider's internal workings. The
contract says what will be done, not how it will be done. The service implementation is opaque to
the consumer, as if it is performed inside a "black box." The consumer is thereby relieved of the

Gartner, Inc. | G00155097 Page 3 of 6

This research note is restricted to the personal use of A01318614@itesm.mx.

 This research note is restricted to the personal use of A01318614@itesm.mx.

burden of understanding the details of the provider's operation. The provider benefits because it
has the freedom to change its internal processes without telling the consumer, as long as the terms
of the contract are not affected. For example, a mail and package courier can reroute its airplanes,
build a new hub or change the way it automates its sorting operations without needing permission
from its customers.

At an IT level, this principle is fulfilled by separating the implementation (the service provider
module's code and data) from the interface metadata. A copy of the interface metadata is
accessible to other developers separately from the code that implements the provider component.
This makes it possible for the consumer developer to use the service without having a copy of the
provider software module. It also enables multiple development teams to create interchangeable
provider modules. Provider developers can change or move their software and data to another
computer without disrupting the consumers, as long as the interface remains unchanged (this
capability implies a loose coupling between the consumer and the provider). The consumer and the
provider can use disparate programming languages, application servers and operating systems,
demonstrating more flexibility than was found in some traditional, distributed computing
infrastructures.

Shareable
Multiple people, departments or even separate companies can use the same service. All parties
benefit from economies of scale because a provider can add an incremental consumer for less than
it costs to implement a new, dedicated service from scratch. A consumer can put a new business
process, branch office or even a whole new company into operation without reinventing ways to
perform common functions.

This principle is implemented at an IT level by ensuring that each provider module in an SOA
application can be invoked successively by disparate consumers. Developers can write many
different consumer application modules that use the same service as long as they conform to the
conditions specified in the interface contract. In practice, many SOA services are not actually
shared because only one type of consumer needs them, but the capability is always there in any
software component that has been built according to the principles of SOA.

Key Facts
Services are nothing new at the business level. Companies have implemented the service concept
for hundreds of years, although it is arguably more widespread today. More aspects of company
operations are being re-factored into services because of improvements in communication and
transportation technology. As the cost of moving data and goods decreases, and the cost of labor
increases, it becomes more economical to shift certain additional functions to dedicated specialist
service providers rather than performing that work in consumer departments. Moreover, increasing
competition, globalization and technology advances are driving companies to change their
products, business processes and prices more frequently. The flexible, reconfigurable nature of
services makes it possible for companies to adapt more quickly to address changing conditions.

The service concept represents a bigger change at the IT level because few business applications
used SOA until recently. Early application systems were monolithic, consisting of a few large

Page 4 of 6 Gartner, Inc. | G00155097

This research note is restricted to the personal use of A01318614@itesm.mx.

 This research note is restricted to the personal use of A01318614@itesm.mx.

programs that were not distributed. Business applications began to evolve toward modularity and
distribution during the past 20 years as networks became faster and less-expensive and as
standard low-level communication protocols (such as TCP/IP) emerged. However, most distributed
applications, including most client/server applications in the 1990s, fell short of implementing SOA.
The missing element, in terms of SOA's five definitional principles, was systematic interface
documentation. Progress in related communication standards and software management
disciplines has also made SOA applications more practical.

SOA is not "finished" because the IT industry has more to learn about how best to implement it.
However, SOA has come far enough so that the majority of companies recognize the benefits. A
body of knowledge has developed regarding SOA best practices, design patterns and tools. Those
subjects go beyond the scope of this report but are addressed in other Gartner research.

Recommended Reading
"The Business Impact of Service-Oriented Architecture"

"Service-Oriented Architecture Overview and Guide to SOA Research"

"Applied SOA: Transforming Fundamental Principles Into Best Practices"

Gartner, Inc. | G00155097 Page 5 of 6

This research note is restricted to the personal use of A01318614@itesm.mx.

 This research note is restricted to the personal use of A01318614@itesm.mx.

GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

2008 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartners prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartners research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartners Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see Guiding Principles on Independence and Objectivity.

Page 6 of 6 Gartner, Inc. | G00155097

This research note is restricted to the personal use of A01318614@itesm.mx.