 | 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
21 May 2007 In this article, Part 2 of this
series,
you examine the architecture and the governance models of both Service-Oriented
Architecture (SOA) and Enterprise Architecture (EA), and explore their similarities
and differences. Then you learn about potential problems that organizations can face
if they don't coordinate EA and SOA activities within the enterprise.
Introduction
This three-part series of articles covers the similarities and differences
between SOA and EA, and shows you how to address the potential problems that
result from their overlap based on a real customer engagement. In this engagement,
IBM® provides a broad range of business transformation and IT outsourcing
services and manages 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.
Part 1
of this series provided definitions and scope of both SOA and EA to establish
a framework in which proper comparisons and contrasts between the two can be
meaningful. It also explained that SOA and EA are more than just architecture
— specifically, both are comprised of architecture, governance, and a
roadmap. You saw a breakdown of the different domains of each and the governance
framework for both.
Part 2
, this installment, focuses on identifying the similarities and
differences between SOA and EA, considering the architecture in both and
identifying the overlap between their corresponding domains. It highlights the
potential problems that may arise when an enterprise has developed (or is
developing) an EA and is now embarking on establishing an SOA. Then you focus on
the governance aspects of EA and SOA and perform analysis similar to what we did
with the architecture while working on a large engagement with a Fortune 500
company in the utilities industry.
Part 3
, coming soon, provides guidance about addressing these problems
based on the experience the authors gained while facing similar challenges while
working with their client.
The A in SOA and EA
To determine the overlap between the different domains of architecture of SOA and
EA, take a look at Figures 1 and 2. They depict the corresponding domains of EA
and SOA, respectively. You'll use these diagrams as the basis for your mapping.
Figure 1. EA architecture domains
Figure 2. SOA solution stack
The following table provides a mapping between the architecture domains of SOA
and EA. The mapping shows clearly that there's a great deal of overlap between SOA
domains and EA domains.
Table 1. Mapping SOA and EA Architecture
Domains
| Architecture domains | SOA solution stack | EA framework |
|---|
| Business | Business process | Business architecture |
|---|
| Applications | Services and components | Application architecture |
|---|
| Integration& Middleware | Integration architecture / ESB | Technology architecture |
|---|
| Data | Data architecture | Information architecture |
|---|
| Operations | QoS, security, monitoring, and infrastructure | Technology architecture |
|---|
However, it's also obvious that the SOA domains are a subset of the EA domains.
For example, SOA is not concerned with the development of business architecture.
Instead, it uses the outcome of business processes and other business architecture
artifacts, such as Component Business Modeling (CBM), as input to identify
business services. In contrast, EA is concerned with the development of business
architecture, including business processes and CBM among others. Similarly, from
an Application Architecture point of view, SOA is concerned with the modeling and
development of services and the components that realize them, while the EA
architecture deals not only with SOA-specific artifacts, but with other
components, packages, and systems for the whole enterprise.
When analyzing the Technology Architecture, the SOA ESB is just one of many
integration mechanisms an EA may need to address. Note also that SOA doesn't
address Content Management Architecture, while EA does.
Another area of overlap is security and service management. In fact, SOA security
is a special case of the total security that EA must specify, and SOA Service
Management and Monitoring is a subset of Systems Management that EA must deal
with.
Architecture domains: similarities and
differences
The following summarizes the similarities and differences when considering the
concepts of architecture in both SOA and EA:
Similarities
SOA and EA domains share many similarities. For example:
- Both address similar architectural domains.
- Both are intended to closely align IT with business.
- Both use input based on business objectives.
- Both require similar strategies and planning activities.
Differences
While the focus of the EA architecture domains is on the macro level, the SOA
architecture domains work on a micro level. More specifically:
- EA focuses on defining business components, while SOA focuses on business
services.
- EA deals with application frameworks and enterprise applications, while SOA's
scope is on service modeling only.
- EA deals with enterprise-level infrastructure including servers, databases,
and so on, while SOA focuses on the infrastructure that supports services,
namely the Enterprise Service Bus.
- EA addresses enterprise integration patterns and when they should be used,
including point-to-point integration, file transfer, and other traditional
application integration approaches. SOA provides an integration approach based
on using services. Though the SOA approach to integration may prove to be the
most flexible and recommended approach, you should consider it as one of the
approaches EA needs to define and support.
Potential Problems
Because of the overlap in the architecture domains of both EA and SOA, the
following potential problems may arise when the two are developed in isolation:
- If the enterprise focuses only on SOA, it's possible that other EA aspects are
ignored. For example, legitimate needs for integration approaches and standards
other than those supported by SOA (for example, point-to-point interface) may be
ignored and not addressed on the enterprise level. Also, without EA
organizations may fall into applying the Golden Hammer antipattern (if a hammer
is your only tool, then every problem looks like a nail) and attempt to use SOA
for every solution, even the ones that don't benefit from such architecture.
- With parallel efforts to develop an SOA and EA concurrently, you might
encounter inefficiencies as a result of duplicate efforts and missed
opportunities to leverage existing architecture artifacts. It's conceivable that
two teams working on developing SOA and EA can spend unnecessary time and
resources producing duplicate, and sometimes contradicting. information models,
infrastructure, system-management policies, strategies, and tools.
- Without careful consideration of what's covered by EA and what's SOA specific,
enterprises may fail to identify and incorporate SOA-specific needs as part of
EA (for example, SOA-specific standards like XML and BPEL).
 |
Governance
Governance definitions are different based on the domain to be governed, for
example, IT governance, architecture governance, and now SOA governance. However,
there's a relationship between these different governances, which you'll explore
in this section.
The definition of governance depends on the domain to be governed. The following
are selected definitions of governance for different domains:
IT Governance
"A structure of relationships and processes to direct and control the
enterprise in order to achieve the enterprise’s goals by adding value while
balancing risk versus return over IT and its processes." —
The IT Governance Institute
Architecture governance
"The practice and orientation by which enterprise architectures and
other architectures are managed and controlled at an enterprise-wide level.
Typically does not operate in isolation, but within a hierarchy of governance
structures, which, particularly in the larger enterprise, can include Corporate
Governance, Technology Governance, Information Technology (IT) Governance, and
Architecture Governance." —
The Open Group
SOA Governance
"SOA governance extends IT governance as enterprises increase their
level of service-orientation. SOA is also a cross functional initiative involving
business and IT in the collective pursuit to deliver on the enterprise's strategy
and goals. Hence, SOA Governance must bridge any gaps between enterprise and IT
governance." —
Kerrie Holley, IBM Fellow
The comparison that follows focuses on the organization models for governance
rather than the governance processes or the processes to be governed.
Governance organization models
To support governance processes, a governance organization must be established to
define, enforce, and maintain these processes. This section compares governance
organizations for SOA and EA.
Architecture governance model
Figure 3 depicts a typical organization model for architecture governance as
described by IBM.
Figure 3. Typical architecture
governance organization
In this architecture governance organization, the governing bodies in the bottom
tier deal with the individual projects, while those in the middle tier establish
governance on the program level (which normally oversees several projects). The
teams in the upper tier operate on a level above the program level and provide the
necessary links to external entities and stakeholders (if necessary). Of
importance in the context of this article are the Architecture Review Board (ARB)
and the Architecture Steering Group (ASG) in the middle tier.
The ARB owns and maintains the EA. In many cases, and where there is no design
authority in place, the ARB provides guidance to project teams while developing
project architecture. The ARB is also responsible for enforcing compliance with EA
by the individual projects as well as granting exception when appropriate.
The ASG, on the other hand, is responsible for establishing architecture policies
and resolving issues escalated by the ARB when they arise. It's important to note
that both the ARB and the ASG have distinct responsibilities and strict
interactions with the governing bodies in the other two tiers.
SOA governance model
Figure 4 presents a simplified governance organizational model for SOA. The major
teams depicted in this governance model are the:
- SOA Executive Steering Committee, which is responsible for setting the
direction of SOA in the enterprise.
- SOA Review Board, which is responsible for ensuring that the SOA standards and
policies are implemented in all SOA related projects.
- SOA Business Council, which is the link to the line of business (LOB)
organizations to identify and prioritize the services to be developed and that
are important to the business.
- SOA Center of Excellence (CoE), which is responsible for the ongoing mentoring
and providing guidance to the SOA development on all projects.
Figure 4. Simplified SOA
governance organization
EA and SOA governances: similarities and
differences
Here you observe that review boards and steering committees are present in both
SOA and EA governance organization models. However, the SOA governance
organization model potentially extends traditional EA governance organization
through the introduction of the SOA CoE and the SOA Business Council, which don't
appear to have an equivalent in EA.
Based on their respective responsibilities, the following lists the potential
mapping between SOA and EA governance organizations:
- SOA Executive Strategy Committee maps to Architecture Steering Group
- SOA Review Board maps to Architecture Review Board
- SOA CoE could map to Design Authority (a concept popular in the UK, Europe,
the Middle East, and Africa but not commonly used in the U.S.); however, even
with the existence of design authority, an enterprise may still elect to
establish an SOA CoE to ensure the realization of all the benefits promised by
adopting SOA.
- SOA Business Council would not typically exist in an EA environment.
In summary, SOA and EA governance have many similarities and differences:
Similarities
- Both require executive committee oversight.
- Both require a review board.
- Both address issues on the enterprise level.
- Both strive to ensure that business and IT stakeholders are fully
represented.
Differences
- SOA needs more tactical visibility to the business in the form of an SOA
Business Council that closely interacts with business units.
- SOA may require specific measures to secure funding for implementation, which
isn't a concern of traditional EA governance models.
- SOA CoE is a separate entity that may have no direct equivalent in an EA
organization.
- While EA governance views governance in a generics leadership and sponsorship
level (strategic), SOA governance views it as tactical, using tools to do the
governance (which in truth is more management than governance).
Potential problems
The most obvious potential problems that an enterprise may encounter if they
develop SOA and EA governance in isolation include:
-
Potential overlap between the responsibilities of the SOA CoE lead and the
enterprise architect. This overlap in responsibilities may cause confusion
and friction between the two leads that ultimately might impede the success of
both SOA and EA.
-
Competition between SOA and EA for the same business resources. In most
enterprises, the time and availability of business subject matter experts are
scarce resources. As such, asking them to participate in duplicate and similar
activities and governance organizations for both SOA and EA can cause lack of
participation and perception of inefficiencies. This can lead to less
contribution by these experts to the activities of one or both.
-
Potential for making contradicting architectural decisions that affect the
whole enterprise. With both efforts for SOA and EA progressing in
isolation, it's likely that some of the decisions made by one or the other could
cause further confusion among those who are relying on the outcome to guide
their decisions
|
Summary
In this article, you learned about the similarities and differences
between SOA and EA from the perspectives of both architecture and governance. You
also explored potential problems that enterprises may encounter if they don't
coordinate the EA and SOA activities in the enterprise. The next installment in
this series, Part 3, provides guidance as to how these problems can be addressed
based on experience gained from a real-world engagement.
Acknowledgments
Special thanks to Ian Charters who was the lead on the Academy of Technology
Study EA from which many of the diagrams in this article were developed. Also,
we'd like to acknowledge the following people for their work in this area and for
their valuable comments on early drafts of this article: 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
| |
