While going through in-depth on Service Oriented Architecture (SOA) and Enterprise Architecture (EA) as part of my Oracle SOA and TOGAF certification, I had questions as to how SOA fits in the EA, and how TOGAF for EA support adopting SOA. Here is an attempt to address that...

1. Enterprise Architecture
and
Service Oriented Architecture
Sreeni Setty
PREFACE
While going through in-depth on Service Oriented Architecture (SOA) and Enterprise Architecture (EA) as
part of my Oracle SOA and TOGAF certification, I had questions as to how SOA fits in the EA, and how
TOGAF for EA support adopting SOA.
Here is an attempt to address that.
INTRODUCTION
TOGAF, The Open Group’s Architecture Framework, is a generic Enterprise Architecture framework. It
provides enterprises with a 4 dimensional model- Business, Information, Application and Technology
Architecture that enables to design, evaluate and build the right architecture for any organization
ensuring Business-IT alignment at the enterprise level.
SOA, Service Oriented Architecture, is an industry standard architectural style that re-structures
applications as loosely coupled, modular services to deliver boundary less information flow. It bridges
the gap between Business and IT through well defined, Business-IT-aligned “Services”.

2. COMPARISON
The objectives of TOGAF and SOA are quite similar. However TOGAF is an architecture framework and
SOA is an architectural strategy.
How do the principles of service orientation apply to the enterprise architecture? To answer, let’s take
each phase of TOGAF’ ADM, Architecture Development Method, and see how TOGAF enables to do SOA.
TOGAF ADM phases cycle through A to H for incremental architecture development. Phases A to F for
each cycle is carried out in parallel to phase G the implementation governance phase for the previous
cycle. Phase 0 – the preliminary phase is for each cycle start.
Phase 0: Framework and Principles
This is the preliminary phase where the architecture footprint for the organization is defined. And the
approach to do the architecture is laid out by selecting the framework and the guiding principles.
This is the starting point for adopting the TOGAF ADM framework, and adopting SOA and service
orientation as architecture principles.
An example architecture principle for service orientation is that the architecture is based on a design of
services which mirror real-world business activities comprising the enterprise business processes.
Phase A: Architecture vision
The Architecture Vision phase is concerned with defining scope for the architecture project, creating
vision and obtaining approvals from stakeholders to proceed.
High-level description of the final architecture that is envisioned is produced. The SOA vision in the
architecture is defined highlighting the type of services, its composition and contract, how they support
the business processes and its business benefits.
An example, a particular segment where SOA should be used, and call for use of web services for
interaction between segments.
Phase B: Business Architecture
The Business Architecture phase aligns the enterprise’s business processes, people, operations and
projects with its overall strategy. Provides the foundation to build Information Systems Architecture and
Technology Architecture.
Business functions, requirements and processes are analyzed. The information that is central to the
business operations which is crucial for SOA is described identifying and defining the portfolio services.
Models are developed describing the SOA solution architecture:
Business Process Model – set of diagrams that show the business processes and their
decomposition, their interactions, and the information with which they are concerned.

3. Business Roles Catalog – list of human and organizations users of the system.
Business Vocabulary – list of key terms used in describing the business processes.
Business Rules Catalog – list of business rules and its description.
Business Services Catalog – list of business services showing their providers, their potential
consumers, and the service contracts.
The models provide a view to demonstrate to stakeholders how SOA specific concerns relating to
Business Architecture are addressed.
Phase C: Information Systems Architecture
The Information Systems Architecture phase defines the types and sources of data necessary to support
the business, and define the kinds of application systems necessary to process the data.
The Data Architecture includes the development of:
Business Data Models
Logical Data Models
Data Management Process Models
Data Interoperability Requirements (example, XML schema, security policies, etc)
Data Architecture Building Blocks
The application architecture for SOA means groups of loosely-coupled services, the definition of these
services and the interaction between them based on the previously defined data models.
An example, in services that exchange XML messages, the message schema and tags should be based on
the information and data models.
With SOA, the traditional software applications are replaced with interoperable services. However,
existing applications, and any new traditional type applications that might be added, are also listed in
the application portfolio. Services are identified that cover the application functionality.
The Application Architecture includes:
Service Interaction Model – set of diagrams that show portfolio services, interaction between
them and their use of data.
Business Process/Service Matrix – shows which service caters to which business processes.
Service Consumer Matrix – shows which human and external systems consume which service.
Service Contract and Policy Catalog – catalog of service contracts, and policies for each service
contracts.
Service Access Control Model – set of diagrams that show how access to services is controlled.

4. Service Configuration and Provisioning Model – shows how services are configured and
provisioned with resources.
Service Loading Model – shows expected load on the services, time patterns of service use, and
performance requirements.
The models provide a view to demonstrate to stakeholders how SOA specific concerns relating to
Application Architecture are addressed.
Phase D: Technology Architecture
The Technology Architecture phase maps the application components deified in the Application
Architecture phase into set of software and hardware technology components, defining the software
and hardware infrastructure needs to support the portfolio services.
For SOA the infrastructure building blocks include:
Activity Monitor – is a program that interfaces with messaging programs and monitors the messaging
activity and results. Example: Business Activity Monitor (BAM) in the Oracle Fusion Middleware Suite.
Composition Engine – is a program that executes scripts that control services and describe interactions
between them. It is used to perform one or more of the services in a composition. Example: Business
Process Executing Language (BPEL) Process Manager in the Oracle Fusion Middleware Suite.
Data Translator – is a program that converts data from one representation to another. Example:
Extensible Stylesheet Language Transformations (XSLT)
Data Security – services to ensure message integrity and confidentiality. Example: WS-Security
Service Bus - standards-based integration platform that combines messaging, web services, data
transformation, and intelligent routing between services. Example: Enterprise Service Bus (ESB) in the
Oracle Fusion Middleware Suite.
Service Registry – enables discovery of services. Example: Oracle Service Registry that is based on the
standard Universal Description Discovery and Integration (UDDI).
Service Repository – enables hosting of metadata for the services, code versions, documentation.
Example: Oracle Enterprise Repository.
The Technology Architecture for enterprise SOA includes:
Technology Portfolio – catalog of SOA run-time infrastructure, SOA development environment,
service components technology, and service interface technology.
Service/Physical System Matrix – shows which physical systems host the services.
Service/Technology Matrix – shows which items in the technology portfolio are used in the
performance of which services.

5. The models provide a view to demonstrate to stakeholders how SOA specific concerns relating to
Technology Architecture are addressed.
Phase E: Opportunities and Solutions
The Opportunities and Solutions phase looks at the implementation options identified in target
architecture (example build vs. buy vs. re-use options), and verify check point suitability of
implementation.
Existing services and solution portfolios in the enterprise are viewed before making a decision on
whether to develop the services in-house, or use the services provider by external companies, or acquire
software products that perform the services. Whether or not existing systems should be replaced all at
once, and options looked at so that the new and old systems can coexist.
Phase F: Migration Planning
The Migration Planning phase is about prioritizing, selecting major work packages, and developing the
plan for the architecture implementation. The cost, benefits, dependencies, and priorities are assessed
and a detailed implementation plan is produced that guides the next phase.
Phase G: Implementation Governance
The Implementation Governance phase provides architectural oversight of the implementation, to
improve the quality of the implementations in general and in particular to ensure conformance with the
architecture.
SOA Governance is viewed as the application of corporate governance, information technology (IT)
governance, and enterprise architecture (EA) governance to SOA. SOA Governance extends IT and EA
governance, ensuring that the benefits of SOA are realized. This means governing, not only the
execution aspects of SOA, but also the strategic planning activities.
Phase H: Architecture Change Management
The Architecture Change Management phase establishes procedures for managing changes to the new
architecture.
Where SOA has not previously been used within an enterprise, this phase is an opportunity to assess
and consider adopting the principles of service orientation.

6. Putting it all together… Using TOGAF for end-to-end SOA
The phases of Architecture Development Method fitting in the SOA Assessment Phase, SOA Architecture
Phase, SOA Change Phase and SOA Implementation Phase.

7. SUMMARY
Effective enterprise architecture covering business operations, people and technology is critical to
business survival and success. Focusing on the Business and IT, the quality of an enterprise's IT
architecture has a direct impact on its business performance. This is where the principles of service
orientation fit in benefitting the IT architecture.
Following TOGAF ADM, a set of key business requirements are identified in phase A, the business
requirements are further defined in phase B, information systems requirements are identified in phase
C, software and hardware infrastructure is identified in phase D. Planning and managing implementation
and changes are dealt in phases E through H.
With SOA, the IT systems perform services that are defined and described in the context of the
enterprise’s business activities. Each service is identified, and what it does is clearly set out in the form
of a contract. This principle enables use of techniques such as service composition, discovery, message-
based communication, and model-driven implementation, which give fast development of effective and
flexible solutions.
TOGAF’s ADM helps to establish clear links between business and IT objects in the enterprise
architecture. SOA brings agility and interoperability to the IT systems in the enterprise architecture.
KEYWORDS
SOA – Service Oriented Architecture
EA – Enterprise Architecture
TOGAF – The Open Groups’ Architecture Framework
ADM – Architecture Development Method
REFERENCES
http://www.opengroup.org/togaf/
http://www.oracle.com/technology/tech/soa/