 | 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
30 Aug 2007 If you're adopting a Service-Oriented Architecture (SOA) and
developing an Enterprise Architecture (EA) simultaneously—or planning
to—you'll benefit from
this article. The first two parts in this
series
compared and contrasted SOA and EA and covered problems that can result from not
coordinating EA and SOA activities within an enterprise. The authors came face to
face with these issues while working on a US$1.6 billion client engagement where
both SOA and EA were under development. In this final installment of the series,
learn from their experience as they provide guidance to help you address these
challenges—and hopefully avoid costly setbacks.
Introduction and recap
There's a great deal of overlap in the concepts, activities, processes, and
outcomes of SOA, EA, and their corresponding governance. For example, both SOA and
EA require input based on business objectives and produce outcomes tied to and
measured against these objectives. They both aim to address issues on the
enterprise level (strategy and planning, reference architecture, and so on). And
their governance models are similar. If your enterprise is adopting SOA while
developing an EA (and its associated governance), you may encounter problems if
the similarities and overlaps between EA and SOA are not recognized and accounted
for.
| |
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
focused 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, this final article in the series, presents a case study based on
our experience with a large account for which we developed EA and SOA
concurrently. We provide guidance as to how we addressed the potential problems
and summarize the lesson learned.
The engagement
The client, a Fortune 500 company, is engaged with IBM® for a 10-year
contract for business and IT outsourcing services. As part of this engagement, IBM
is providing a broad range of business transformation and IT outsourcing services,
and managing all of the client's IT operations—mainframe, midrange,
desktop, help desk, voice and data network, application development, and
maintenance.
Key IT transformational activities include the following:
- The establishment of a framework and center of excellence (CoE) for SOA
- Level 3 Software Engineering Institute (SEI) process maturity attainment for application development and
maintenance
- Application portfolio management
- Development of several new transformation projects as well as data center and
server consolidation projects
Relevant facts and
challenges
First, let's break down some of the specific SOA-EA challenges we encountered to
help provide some perspective on the environment in which this took place:
Enterprise Architecture
- The need for EA was recognized late in the due diligence phase of the sales
cycle. As such, no budget or staff, other than the enterprise architect, was
allocated to develop the EA.
- We decided to develop the EA incrementally by abstracting principles,
decisions, and models from the projects already under development, including the
consolidated financial and accounting system and the customer services common
desktop system.
- Shortly after the start of the engagement, we established a straw man EA
governance structure while the effort for formulating and documenting SOA and
its governance was still in development.
SOA
- Some of the reasons for winning the contract and a differentiator between IBM
and its competition were proposing SOA and demonstrating leadership in its
development.
- The contract included funding and plans for SOA startup activities, which led
to a good kick off.
- Only one transformation project was clearly linked to SOA, while other
transformation projects were structured and funded without explicit inclusion of
SOA. This made the introduction of SOA into those projects after the contract
signing problematic.
Proposed governance
organizational models
While the contract specifically called for the development and implementation of
an architecture governance model, the development of an SOA governance model was
implicitly assumed as part of the SOA starting activities. The following sections
describe the proposed architecture governance and the SOA governance models.
The architecture governance
organizational model
To establish an architecture governance, we proposed a model that consists of a
two-tiered organizational structure (see Figure 1), which is an adaptation of the
governance model described in the IBM Enterprise Architecture Consulting Method.
In this model, the two governance bodies are called the Architecture Management
Council (AMC) and the Delivery Architecture Review Board (DARB).
Figure 1. Proposed EA governance
organizational model
The charter of the AMC:
- Decides the overall architecture strategy for the client, taking into
consideration the client's business strategy, technology scans (sponsored
studies covering available technologies), and industry knowledge.
- Deals with and resolves escalated issues.
- Sponsors and drives the EA.
The DARB charter can be classified into two categories:
-
EA incremental development and maintenance:
- Collects existing architecture policies and examines them to decide which
are applicable for adopting as the client's EA
- Elevates and incorporates individual project architectural decisions that
are appropriate for the enterprise to become an integral part of EA
-
Architecture governance
- Guides the development of project architecture
- Monitors compliance of the project architecture with the client's EA
- Approves the project architecture as a prerequisite for moving forward with
hardware and software procurement and initiation of detail design and
development
- Grants exceptions as appropriate
The SOA governance organizational
model
While the EA governance model was being developed and established, the SOA team
was proposing the following SOA governance organizational model, as depicted in
Figure 2.
Figure 2. The proposed SOA
governance organizational model
In this model, the SOA is governed through the establishment of three boards: the
executive steering committee (top of the diagram), the SOA business council
(right), and the SOA review board (left). The SOA CoE and a proposed centralized
SOA delivery team represent the core SOA team. Figure 2 also shows the members of
each of these governing bodies.
Dealing with challenges
This section outlines how we addressed the potential problems that resulted from
developing SOA and EA concurrently. The problems are divided into two
categories—architecture and governance—and map to the issues
described in
Part
2
of this series.
Architecture-related problems
| Potential problem | Our solution |
|---|
| With all the focus on SOA, other EA aspects are
ignored |
- We kept the SOA CoE and the DARB separate.
- The DARB focused on EA, while the CoE focused on SOA.
- The SOA lead and the enterprise architect reciprocally participated in
both the DARB and the SOA CoE.
|
|---|
| Inefficiencies as a result of duplicated efforts
and missed opportunities to leverage existing architecture artifacts |
- We leveraged the DARB to review SOA design and infrastructure.
- We used the enterprise service bus (ESB) as the enterprise integration
infrastructure.
- We leveraged (with extensions) existing system management and monitoring
tools for SOA infrastructure.
|
|---|
| Failure to identify and incorporate SOA-specific
needs as part of EA |
- The DARB reviewed SOA-related projects as other non-SOA projects.
- We positioned SOA as the basis for the EA functional architecture
domain.
|
|---|
Governance-related problems
| Potential problem | Our solution |
|---|
| Overlap between the responsibilities of the SOA
CoE lead and the enterprise architect |
- The EA was a member of the SOA CoE, and the SOA lead was a core member
of the DARB, resulting in joint decisions being made.
|
|---|
| Competition between SOA and EA for the same
business resources |
- Sharing the same governance boards for both SOA and EA allowed business
resources to address both SOA and EA needs in the same forum.
|
|---|
| Potential for making contradicting architectural
decisions that affect the whole enterprise |
- Except for specific SOA-related issues, all other architectural
decisions were approved by the DARB.
|
|---|
Figure 3 shows how we leveraged the EA governance organizational model to
implement the SOA governance structure. (See a larger version of Figure 3.)
Figure 3. Mapping the architecture
and SOA governance organizational models
Lesson learned
Dealing with issues encountered during this client engagement taught us some
valuable lessons about adopting SOA and developing an EA at the same time. The
following list highlights what we've learned and will hopefully help you dodge
problems similar to those we encountered.
Lesson 1: SOA addresses only a subset of EA domains
- The SOA scope focuses mainly on services and their implementations.
- Most SOA activities and decisions fall within the domain of EA functional
architecture.
- SOA can leverage other EA domains, such as information architecture, system
management, and any operational architecture established for the
enterprise.
Lesson 2: SOA governance should leverage EA and IT governance structure
- The service model should be developed and maintained by the SOA CoE.
- Established architecture review boards and steering committees should be
considered to cover SOA governance needs.
- If needed, SOA may require special councils, such as a business council.
Lesson 3: SOA funding model is outside the scope of EA
- Traditional EA models don't address funding.
- SOA funding should be on the enterprise level not on a project level
- SOA funding should leverage the IT funding model and governance rather than
establishing its own.
- The service model should be developed and maintained by the SOA CoE; however
it should be referenced from the EA functional domain rather than duplicating
it.
Lesson 4: SOA infrastructure (ESB) should be an enterprise asset
- ESB should be considered to handle all the enterprise integration needs, not
just systems that are using services.
- Management of the ESB should be considered as part of the enterprise system
management architecture.
- ESB- and SOA-related security should comply with the enterprise security
policies.
Summary
Implementing an SOA in an enterprise where EA has been established or is concurrently
being developed is tricky. Potential architecture- and governance-related problems
lurk as a result of the overlap in their scope of influence, governance
organizations, processes, and architectures. To reduce headaches in the process,
make sure you have well-planned architecture governance and SOA governance models
as well as a better understanding of how they should work together. And take advantage of the lessons learned by those who have gone before you—like the ones we've outlined in this article—to save time and money during your own engagement.
Acknowledgments
We would 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, Ian Charters, Peter De Meo, Luba Cherbakov, Claudio Cozzi, Ray Harishankar, Kerrie Holley, Don Hutcheson, David Janson, Steven Barnes, Satish Kalyani, and Sharon Fortune.
Resources Learn
Get products and technologies
Discuss
- Participate in the discussion forum.
- Get involved in the developerWorks community
by participating in developerWorks blogs, including the following SOA
and Web services-related blogs:
-
Service Oriented Architecture -- Off the Record with Sandy Carter
-
Best Practices in
Service-Oriented Architecture with Ali Arsanjani
-
WebSphere SOA and J2EE in Practice with Bobby
Woolf
-
Building SOA applications with patterns with Dr. Eoin Lane
-
Client Insights, Concerns and Perspectives on SOA with Kerrie Holley
-
Collaboration apps, SOA, open source, Apache Tuscany, and world
travel with Luciano Resende
-
Isn't it SOAnderful?: SOA, architecture, and developer issues
with Pat Flanders
-
Service-Oriented Architecture and Business-Level
Tooling with Simon Johnston
-
SOA Innovations with Dr. Liang-Jie Zhang
-
SOA, ESB and
Beyond with Sanjay Bose
-
SOA, Innovations, Technologies, Trends...and a little
fun with Mark Colan
-
Web Services Interoperability with Tom Glover
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
| |
