 | Level: Intermediate Dr. Mamdouh Ibrahim (mibrahim@us.ibm.com), Senior Certified Executive IT Architect and STSM, IBM
Gil Long (gillong@us.ibm.com), Distinguished Engineer, IBM
26 Apr 2007 The first of a three-part series, this article provides a framework to help
you understand how Service-Oriented Architecture (SOA) and Enterprise Architecture
(EA) work together. First, get a brief introduction to and definitions of SOA and
EA. Then learn about the scope and focus of SOA and EA so you can effectively
compare and contrast the two.
Introduction
Close examination of SOA and EA and their corresponding governance reveal a great
deal of overlap in their concepts, activities, processes, and outcomes. For
example, both require input based on business objectives and produce outcomes that
are tied to and measured against these objectives. Furthermore, both aim to
address issues on the enterprise level (strategy and planning, reference
architecture, and so on), and at the same time their governance models are
similar. An enterprise that's adopting SOA while developing EA and its governances
may encounter problems if the similarities and overlaps between EA and SOA are not
recognized and accounted for.
The content of this series of articles is based on the practical experiences we
gained while involved in a large engagement with a Fortune 500 company in the
utilities industry. IBM® provided a broad range of business transformation
and IT outsourcing services, and managed all of the client’s IT operations —
mainframe, midrange, desktop, help desk, voice and data network, application
development, and maintenance. The engagement required both SOA and EA to be
developed concurrently. This three-part series articulates the potential problems
such overlap creates and provides suggestions and guidelines about how you can
address such problems. Specifically:
-
Part 1 provides definitions and scope of both SOA and EA to establish a
framework in which proper comparisons and contrasts between the two can be
meaningful.
-
Part 2
compares and contrasts SOA and EA. It also highlights the
potential problems that may arise when an enterprise has developed (or is
developing) an EA and then embarks on establishing an SOA.
-
Part 3
provides guidance as to how these problems can be addressed
based on the experience gained while facing similar challenges on a US$1.6
billion engagement where both SOA and EA were under development
concurrently.
With many enterprises moving fast toward the adoption of SOA, it's becoming
increasingly important to understand how this architecture and its governance fit
within EA and governance, which most corporations have either developed or are in
the process of developing. In particular, some of the issues that need to be
addressed are:
- The scope of EA vs. the scope of SOA (for example, how can you leverage their
similar aspects?).
- The relationship between the SOA Center of Excellence (CoE) and the EA
governance boards (for example, how can overlaps be avoided?).
- The responsibility and ownership of SOA infrastructure (for example, where
does the Enterprise Service Bus (ESB) fit within the enterprise infrastructure,
and should it be used exclusively for SOA?).
Enterprise Architecture
EA definitions
An IBM Academy of Technology Study defines EA as follows:
"The EA discipline defines and maintains the architecture models,
governance and transition initiatives needed to effectively co-ordinate
semi-autonomous groups towards common business and/or IT goals."
The definition was crafted carefully to highlight that EA is more of a discipline
than just an architecture. It also intended to capture the need for an EA to link
an enterprise's business strategy to its change programs through the definition
of:
- Architecture models to capture the business' intended structure (through a
business architecture) and to provide a clear specification of how multiple
projects and programs must exploit information technology (through common, and
explicit, IS and IT architectures).
- Mechanisms, such as architecture governance and transition planning, to help
plan, coordinate, and control all parts of the business, ensuring they all pull
in the same direction.
There's no shortage of EA frameworks in the literature. Zachman was the first to
formalize the concept and publish a framework for EA, which was named after him.
Since then, many other EA frameworks have been published and are used by many
organizations, particularly in the domain of the federal government. Examples of
such frameworks are depicted in Figure 1.
Figure 1. The different EA models
in the literature
This information may help you identify the acronyms in Figure 1:
- FEAF — Federal Enterprise Architecture Framework
- TEAF — Treasury Enterprise Architecture Framework
- DoDAF — Department of Defense Architecture Framework
- NASCIO — National Association of State Chief Information Officers
Figure 2 depicts a framework developed as part of the IBM Academy of Technology
Study on EA that addresses all the concepts mentioned in the proposed definition
and shows how EA is positioned as the link between the enterprise strategy (both
business and IT) and the business operating environment and IT infrastructure. The
following sections provide further insight into the different aspects of EA.
Figure 2. IBM EA framework
EA is more than architecture
It's understood that the architecture is only part of what's included when EA is
considered. In particular, EA includes architecture, governance, and a roadmap.
Figure 3 depicts these building blocks of EA and how they influence and interact
with projects under development to achieve business objectives.
Figure 3. EA includes
architecture, governance, and a roadmap
EA framework
The framework established by IBM to facilitate the development and implementation
of the EA consists of several architecture domains and governance, as depicted in
Figure 4.
Figure 4. Positioning EA domains
and governance in the planning process
The architecture domains that need to be modeled as part of the EA are:
- Business architecture
- Application architecture
- Information architecture
- Technology architecture
The architecture governance framework includes the organizational structure and
the processes that need to be established to ensure the proper approval,
exception, communication, and vitality of the architecture.
SOA
SOA definitions
There's no single definition of SOA that has been unanimously agreed upon by
everyone. Instead, several definitions were published by different groups,
vendors, and business analysts. These definitions range from a high-level view of
what SOA does for a business to definitions that focus on the technical aspects of
SOA-based solutions. The following are a few of the SOA definitions often found in
the literature about software development:
W3C's definition:
"A set of components which can be invoked, and whose interface
descriptions can be published and discovered."
CBDI's definition:
"The policies, practices, frameworks that enable application
functionality to be provided and consumed as sets of services published at a
granularity relevant to the service consumer that can be invoked, published and
discovered, which are abstracted away from the implementation using a single,
standards based form of interface."
Gartner's definition:
"Service-oriented architecture is a client/server software
design approach in which an application consists of software services and software
service consumers (also known as clients or service requesters). SOA differs from
the more general client/server model in its definitive emphasis on loose coupling
between software components, and in its use of separately standing
interfaces."
IBM definition:
Because IBM felt strongly about the relationship between SOA and the business
objectives and goals of the enterprise, the IBM SOA Center of Excellence developed
a definition of SOA that was coined to take that into consideration.
"A Service-Oriented Architecture is an enterprise-scale IT
architecture for linking resources on demand. These resources are represented as
business-aligned services which can participate and be composed in a value-net,
enterprise, or line of business to fulfill business needs. The primary structuring
element for SOA applications is a service as opposed to subsystems, systems, or
components."
Recognizing that SOA means many things based on your perspective, three
definitions were introduced to address the business, architecture, and
implementation perspective. These definitions are as follows:
Business perspective definition:
Set of services that a business wants to expose to its customers and
partners or other portions of the organization.
Architecture perspective definition:
An architectural style which requires a service provider, requester,
and a service description.
Set of architectural principles, patterns, and criteria, which address
characteristics such as modularity, encapsulation, loose coupling, separation of
concerns, reuse, composability, and single implementation.
Implementation perspective definition:
A programming model complete with standards, tools, and technologies,
such as Web services.
SOA is more than architecture
Similar to EA, SOA is more than architecture. In addition to its architecture
aspects, SOA needs governance as well as a transition roadmap that allows
enterprises to fully adopt it. As a matter of fact, the same figure used to
illustrate what EA includes can be used to describe SOA with minor modifications,
as illustrated by Figure 5.
Figure 5. SOA is more than
architecture
SOA solution stack
SOA is composed of processes, services, and components. At the heart of the SOA
is the service model that defines services and components that realize them.
Figure 6 presents the SOA solution stack and shows the relationship
between the different elements that comprise SOA.
Figure 6. SOA solution stack
This partially layered architecture shows how composite services are aligned with
business processes, while enterprise-scale (large-grained) components realize the
services. The business processes can be supported by choreography of exposed
services into composite applications. This architecture is supported by several
vertical layers, including:
- An infrastructure layer that's commonly referred to as the Enterprise Service
Bus (ESB).
- A monitoring and management layer to ensure the quality of service and to
achieve nonfunctional requirements.
- A data architecture layer.
- A governance layer.
Summary
In this article, Part 1 of 3, you saw definitions and scope of both SOA and EA to
help you properly compare and contrast the two. Parts 2 and 3 will identify
similarities and differences between SOA and EA, and provide guidance as to how
these problems can be addressed based on experience gained from an
engagement.
Acknowledgments
Special thanks to Ian Charters who was the lead on the Academy of Technology Study EA from which many of the diagrams that appear in this article were developed. Also, we would like to acknowledge the following people for their work in this area and for their valuable comments on early drafts of this presentation: Paul Bate, Luba Cherbakov, Claudio Cozzi, Peter De Meo, Ray Harishankar, Kerrie Holley, Don Hutcheson, David Janson, Steven Barnes, Satish Kalyani, and Sharon Fortune.
Resources Learn
Get products and technologies
Discuss
About the authors | 
| | Dr. Mamdouh Ibrahim is a Senior Certified Executive IT Architect and Senior
Technical Staff Member (STSM) with the Enterprise Architecture and
Technology Center of Excellence. He is also a member of the SOA Web Services
Center of Excellence extended team. Dr. Ibrahim has over 30 years of experience in
both industry and academia in the areas of enterprise architecture, SOA,
distributed computing, and wireless technologies. He is a member of the IBM IT
Architect Certification Board and an author and instructor of the IBM
Architectural Thinking course. Dr. Ibrahim holds a Ph.D. in computer science;
master's degrees in computer science, solid state science, and mathematics; and
bachelor's degrees in electrical engineering and mathematics. He is an adjunct
faculty at Central Michigan University. He served as the OOPSLA 2002 general chair
and is currently serving as the OOPSLA Steering Committee chair until 2008. He is
a member of ACM, IEEE Computer Society, and AAAI. |
| 
| | Gil Long is a Distinguished Engineer with IBM. He serves as the Worldwide
Enterprise Architecture Education Leader and SOA Governance integration leader,
specializing in enterprise-wide architecture design and transition planning and
SOA infrastructure planning. Mr. Long has extensive senior management experience
in all areas of IT, including IT strategic planning, architectural design,
business systems design and implementation, systems and network design and
deployment, and data center operations. He has had direct management
responsibility for large IT organizations, staffing, and budget accountability. He
also has multi-industry experience in healthcare, financial services, education,
retail, insurance, utilities, manufacturing, and government. |
Rate this page
| |
