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.
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:
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.
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.
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 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:
- 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.
- 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).
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
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.
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.
Learn
- Learn about the
IT Governance Institute.
- Check out the
Web Services Glossary by the W3C
Working Group Note 11 February 2004.
- Check out
Understanding SOA
by David Sprott and Lawrence Wilkes for an SOA definition.
- 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.
- 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
- Get involved in the developerWorks community
by participating in
developerWorks blogs.
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)
Table of contents
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
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
