During 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.
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”.
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 PrinciplesThis 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 visionThe 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 ArchitectureThe 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.
• 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 ArchitectureThe 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.
• 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 ArchitectureThe 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.
The models provide a view to demonstrate to stakeholders how SOA specific concerns relating to Technology Architecture are addressed.
Phase E: Opportunities and SolutionsThe 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 PlanningThe 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 GovernanceThe 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 ManagementThe 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.
Putting it all together… Using TOGAF for end-to-end SOA
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.
KeywordsSOA – Service Oriented Architecture
EA – Enterprise Architecture
TOGAF – The Open Groups’ Architecture Framework
ADM – Architecture Development Method
Referenceshttp://www.opengroup.org/togaf/
http://www.oracle.com/technology/tech/soa/
