• SOA Source Book
• Service-Oriented Architecture
• The Open Group Service Integration Maturity Model (OSIMM) Version 2
• SOA Reference Architecture
• Service-Oriented Cloud Computing Infrastructure (SOCCI) Framework
• Using TOGAF to Define and Govern Service-Oriented Architectures
• Introduction and Objective
• Overview
• Service-Oriented Architecture Defined
• Using TOGAF for Enterprise SOA
• Summary
• Summary of Adjustments to TOGAF Phases
• Relations to the SOA Work Group Projects
• Architecture Levels and the Meta-Model
• Referenced Documents
• Acknowledgements
• Legal
• SOA Governance Framework
• Service-Oriented Architecture Ontology Version 2.0
• Legacy Evolution to SOA
• Microservices Architecture
• SOA for Business Technology
• Navigating the SOA Open Standards Landscape Around Architecture
• SOA in the Digital Age

SOA Work Group

SOA Standards Discussion Forum

SOA Work Group Members Page

Using TOGAF to Define and Govern Service-Oriented Architectures – Architecture Levels and the Meta-Model

Strategic Level

• The contracts between services are less important.
• The contracts between components are less important.
• It is important to identify areas where SOA will make a great impact so that they can be prioritized when creating segment architectures. Some segments might not be using SOA as a solution pattern at all.
• It is possible to have a top-level view of what type of SOA reference architecture would be needed in the different segments on a logical level and maybe some indication of what product families to use.

Segment Level

• The contracts between application and data services in the different segments are important so identify requirements for segment external SOA services.
• The contracts between components in the different segments are important so identify which components shall deliver the external services.
• The contracts between application and data services in the same segment are important to identify requirements for segment internal cross-capability SOA services.
• The contracts between components in the same segment are important so identify which components shall deliver the cross-capability services.
• The application and data services are important to identify requirements for similar SOA services cross-segment.
• The SOA reference architecture will be instantiated and a more detailed physical solution suggested.

Capability Level

• The application and data services are important to find re-usable services in the service portfolio and possible change requests on the service portfolio.
• The contracts between the process service and the application or data services are important to identify SOA services.
• A detailed logical and physical SOA reference architecture with the needs of the capability will be defined that can be expanded for the next capability project.