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.

Back to top

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

Back to top

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.

Back to top

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).

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:

1. 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
2. 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.

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.

Back to top

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

Governance-related problems

Figure 3 shows how we leveraged the EA governance organizational model to implement the SOA governance structure. (See a larger version of Figure 3.)

Back to top

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.

Back to top

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

• Be sure to read the other articles in this series.
  
  
• Check out the Web Services Glossary by the W3C Working Group Note 11 February 2004.
  
  
• Read "Understanding SOA" for SOA definition by David Sprott and Lawrence Wilkes.
  
  
• Find more SOA definitions on Gartner's Web site.
  
  
• Find out more about the following models and frameworks:
  • Zachman Framework
  • Federal Enterprise Architecture (FEA) Reference Models
  • NIST EA Model [PDF]
  • Department of Defence Architecture Framework (DoDAF) [PDF]
  • Treasury Enterprise Architecture Framework (TEAF)
  
  
• Learn more about the National Association of State CIO (NASCIO) Enterprise Architecture [PDF].
  
  
• Find information about the Federal Enterprise Architecture Framework (FEAF) by reading A Practical Guide to Federal Enterprise Architecture [PDF].
  
  
• The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  
• The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
  
  
• Stay current with developerWorks technical events and webcasts. Check out the following SOA and Web services tech briefings in particular:
  • Get started on SOA with WebSphere's proven, flexible entry points
  • Building SOA solutions and managing the service lifecycle
  • SCA/SDO: To drive the next generation of SOA
  • SOA reuse and connectivity
  
  
• Check out the SOA development and best practices community topic.
  
  
• Browse for books on these and other technical topics at the Safari bookstore.
  
  
• View a quick Web services on demand demo.
  
  
• Get an RSS feed for this series. (Find out more about RSS.)
  
  

Get products and technologies

• Download the Zachman Framework.
  
  
• Innovate your next development project with IBM trial software, available for download or on DVD.
  
  

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.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction and recap
• The engagement
• Relevant facts and challenges
• Proposed governance organizational models
• Dealing with challenges
• Lesson learned
• Summary
• Acknowledgments
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers