Service-Oriented Architecture and Enterprise Architecture, Part 1: A framework for understanding how SOA and Enterprise Architecture work together
Summary: 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.
Date: 26 Apr 2007
Level: Intermediate
Also available in: Chinese Korean Russian
Activity: 45140 views
Comments: 0 (View | Add comment - Sign in)
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?).
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
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
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.
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.
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 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.
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.
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.
Learn
- Check out the Web Services Glossary by the W3C Working Group Note 11 February 2004.
- Check out 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]
- Treasurey 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.
- 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.
- Browse for books on these and other technical topics at the Safari bookstore.
- 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.
Không có nhận xét nào:
Đăng nhận xét