Using TOGAF to Define and Govern Service-Oriented Architectures – Service-Oriented Architecture Defined


Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.

Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports, etc.) and:

  • Is self-contained
  • May be composed of other services
  • Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or expressed.

SOA Features

SOA is based on the design of solutions using services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes. Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, service component, etc.).

SOA places unique requirements on the infrastructure. Because of this, it is recommended that implementations use open standards to realize interoperability and location transparency. For instance, those requiring the use of those services must somehow document the availability of services in a place easily accessible. An SOA-specific Directory Service and an Enterprise Service Bus are two examples of technology implementations that require adherence to relevant open standards to achieve the interoperability that SOA promises.

Implementations are enterprise environment-specific – they are constrained or enabled by context and must be described within that context. Given that, SOA requires strong governance of service representation and implementation.

How Enterprise Architecture Supports Service-Orientation

Enterprise architecture provides frameworks, tools, and techniques to assist organizations with the development and maintenance of their SOAs. Some of the key benefits that enterprise architecture provides include:

  • Consistent abstractions of high-level strategies and deliverables to support planning and analysis
  • Linkage of different perspectives to a single business problem (e.g., business, data, application, technology, abstract, concrete, etc.) providing a consistent model to address various domains and tests for completeness
  • Identification of clear roadmaps to achieve future state
  • Traceability that links IT and other assets to the business they support
  • Support for impact assessment, risk/value analysis, and portfolio management
  • Identified and documented principles, constraints, frameworks, patterns, and standards
  • Governance frameworks and processes that ensure appropriate authority for decision-making

Enterprise architecture becomes a foundation for service-orienting an organization because it links stakeholders together, ensuring that the needs of each stakeholder community are met and that each stakeholder community is aware of appropriate context. This linkage is the foundation for interoperability and re-use.

Through its linking of the business context to information technology, enterprise architecture readily identifies and provides justification for the cost of change programs in relation to the business value to be derived from the effort. Enterprise architecture may provide the context and analysis capabilities to support:

  • Showing how SOA solutions can be effectively architected to support business capabilities
  • Showing which services should be built and which should be re-used
  • Showing how services should be designed

Without enterprise architecture, the risk may increase for:

  • Limited agility
  • Difficulty identifying and orchestrating SOA services
  • Service sprawl
  • Exponentially growing governance challenges
  • Limited SOA service interoperability
  • Limited SOA service re-use
  • Multiple silo’ed SOAs
  • Difficulty evolving and changing SOA implementations