Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
BS ISO IEC 18384 — Reference Architecture for Service Oriented Architecture (SOA) Series
Information technology — Reference Architecture for Service Oriented Architecture (SOA RA) (2016)
📐 BS ISO/IEC 18384 is the British Standards Institution (BSI) adoption of ISO/IEC 18384, a series published under the general title Information technology — Reference Architecture for Service Oriented Architecture (SOA RA). The series was developed by ISO/IEC JTC 1/SC 38 (Cloud Computing and Distributed Platforms), with UK participation coordinated through Technical Committee IST/38 (Cloud Computing and Distributed Platforms). Its ICS classification is 35.100.05.
Service Oriented Architecture (SOA) is an architectural paradigm in which business capabilities are encapsulated as reusable services and then composed and orchestrated through standard contracts. Since the concept gained momentum in the late 1990s, SOA has been widely applied across large-scale enterprise integration, government information systems, and telecommunications. For a long time, however, the community lacked an authoritative and consistent vocabulary: vendors and project teams used terms such as “service,” “interface,” and “orchestration” with subtly different meanings, which created friction in design, integration, and procurement decisions. The purpose of the BS ISO/IEC 18384 series is to provide an authoritative terminology, a reference architecture, and an ontology for SOA so that service-oriented design and evaluation share a common, comparable baseline across organizations.
💡 The core role of the SOA reference architecture is to treat “service” as a first-class citizen of architecture, uniformly defining concepts such as service, service consumer and provider, service contract, service composition, orchestration, and governance. This makes service-oriented design comparable, reusable, and governable across organizations and systems.
1. Structure and Scope of the Series 📌
The BS ISO/IEC 18384 series consists of three parts, each addressing a different layer of SOA standardization:
| Part | Standard No. | Subject | ICS |
|---|---|---|---|
| Part 1 | BS ISO/IEC 18384-1:2016 | Terminology and concepts for SOA | 35.100.05 |
| Part 2 | BS ISO/IEC 18384-2:2016 | Reference Architecture for SOA Solutions | 35.100.05 |
| Part 3 | BS ISO/IEC 18384-3:2016 | Service Oriented Architecture ontology | 35.100.05 |
All three parts are first editions published in 2016. Part 1 answers the question “how do we talk about SOA?” by unifying terminology and concepts; Part 2 answers “how do we design SOA solutions?” by specifying a reference architecture for SOA solutions; and Part 3 answers “how do we express semantics?” by providing a formal SOA ontology. The three parts complement one another and together form a complete, standardized language for SOA.
In terms of applicability, the series targets enterprise architects, system designers, integration developers, and managers who assess service-oriented maturity. It can be used to guide service-oriented transformation, enterprise integration, and cloud migration programs, and to provide a consistent evaluation framework throughout the architecture lifecycle.
⚠️ Part 1 is the foundation of the series: if terminology is not unified, the architectural elements in Part 2 and the semantic relationships in Part 3 lose their shared basis. Organizations adopting the series are advised to proceed in the order Parts 1, 2, and 3.
2. Terminology and Concepts (Part 1) 🔧
BS ISO/IEC 18384-1:2016 specifies the terminology and concepts for SOA. Its structure includes scope, terms and definitions, abbreviated terms, and notations. The notations clause employs UML (Unified Modeling Language) and similar graphical languages to depict conceptual relationships, making abstract architectural concepts visible and directly comparable. Key terms defined in Part 1 include:
- Service: a logical unit with independent functionality that is exposed through a contract and invoked by consumers;
- Service consumer and service provider: the invoking party and the implementing party, coupled through the service contract;
- Service contract: the formal description of interface, semantics, policies, and non-functional attributes;
- Service composition and orchestration: organizing multiple services into larger-grained capabilities according to business processes;
- Service governance: the decision, specification, and monitoring framework applied across the service lifecycle.
Unified terminology is the essential first step in SOA practice. When different teams or vendors interpret the same term differently, interface design and integration testing suffer from systematic friction and rework. The definitions in Part 1 are deliberately vendor-neutral so that they can be adopted broadly as a common language for communication and collaboration.
3. Reference Architecture for SOA Solutions (Part 2) 🔥
BS ISO/IEC 18384-2:2016 specifies the reference architecture for SOA solutions, describing the key architectural elements of a SOA system and their relationships. The clause structure includes terms and abbreviations, notations, architectural elements, and relationships. Its essential content can be summarized as follows:
- Architectural viewpoints: the solution is examined from multiple viewpoints, such as the service layer, application layer, integration layer, and governance layer;
- Architectural elements: service implementations, service interfaces, service registries, enterprise service buses (ESB), orchestration engines, policy management, monitoring, and governance components;
- Relationships and constraints: dependencies, interaction patterns, and deployment constraints among elements that guide concrete design decisions.
The reference architecture is not a blueprint to be followed mechanically; it is a collection of patterns and constraints that have proven effective in practice. Architects may tailor the elements to their business scale, technology stack, and team capability — for example, replacing parts of an ESB with an API gateway, or replacing synchronous orchestration with event-driven choreography. The real value of the Standard lies in providing a consistent thinking framework, so that architecture reviews and solution selections have a shared, evidence-based basis.
✅ Practical value: the reference architecture provides a reusable starting point for service partitioning, integration style, security, and governance design. It reduces “siloed” architectural divergence, lowers cross-project collaboration costs, and accelerates solution delivery.
4. SOA Ontology (Part 3) 🛠️
BS ISO/IEC 18384-3:2016 specifies the SOA ontology, expressing SOA concepts and their semantic relationships in a formal way:
- Notations: the modelling language and graphical notation used for the ontology;
- Concepts and relationships: formalizing services, participants, messages, policies, orchestration, and their inheritance, association, and constraint relationships;
- Semantic consistency: aligning different systems’ understanding of SOA concepts through a shared ontology to support semantic interoperability.
The ontology is not a runtime component, but it underpins automated governance. With an ontology in place, service discovery can operate on conceptual semantics rather than simple keyword matching, and policy matching can understand implicit relationships between concepts. For large organizations, aligning the SOA ontology with the enterprise metadata model noticeably improves the maintainability of service catalogs and architecture documentation.
🚨 Governance note: an ontology requires ongoing maintenance and must evolve together with the business model. If the ontology and the metadata model drift apart, the value of semantic alignment decays quickly. We recommend embedding ontology ownership and maintenance in the enterprise architecture governance process.
5. Engineering Practice Essentials 🔍
- 🔍 Service-oriented transformation: unify terminology per Part 1, then use the Part 2 reference architecture to define service boundaries and select the integration style;
- 🔧 Architecture governance: use the SOA reference architecture as a common baseline for architecture reviews, compliance checks, and vendor selection;
- 📊 Semantic interoperability: align cross-system concepts per the Part 3 ontology to support service discovery, message mapping, and policy governance;
- 📋 Alignment with cloud-native practice: combine the reference architecture with microservices, containers, API management, and service meshes as a roadmap for service-oriented evolution;
- 📚 Team capability building: use the three parts as training material to unify team vocabulary and reduce misunderstandings in documentation and code.
6. Frequently Asked Questions ❓
❓ Q: How do SOA and microservices relate?
A: SOA is the service-oriented architecture philosophy, and microservices are an evolutionary form in the cloud-native era. The SOA reference architecture focuses on service boundaries, contracts, and governance, while microservices emphasize lightweight, independently deployable, fine-grained units. The two can coexist and complement each other.
A: SOA is the service-oriented architecture philosophy, and microservices are an evolutionary form in the cloud-native era. The SOA reference architecture focuses on service boundaries, contracts, and governance, while microservices emphasize lightweight, independently deployable, fine-grained units. The two can coexist and complement each other.
❓ Q: Why is Part 1 (terminology and concepts) so important?
A: It unifies the basic vocabulary of SOA and serves as the common language of Part 2, Part 3, and of enterprise practice. Without unified terminology, architecture discussions and interface design suffer from systematic misunderstandings.
A: It unifies the basic vocabulary of SOA and serves as the common language of Part 2, Part 3, and of enterprise practice. Without unified terminology, architecture discussions and interface design suffer from systematic misunderstandings.
❓ Q: Is the Part 2 reference architecture mandatory?
A: No. It is a tailorable design reference; organizations may pick and choose elements according to business scale and technology stack. Its value lies in providing a consistent design baseline and review basis, not a mandatory template.
A: No. It is a tailorable design reference; organizations may pick and choose elements according to business scale and technology stack. Its value lies in providing a consistent design baseline and review basis, not a mandatory template.
❓ Q: What is the SOA ontology actually used for?
A: The ontology formalizes concepts and relationships, supporting semantic interoperability, automated service discovery, policy matching, and cross-organization concept alignment. It is a foundation for modern governance and integration.
A: The ontology formalizes concepts and relationships, supporting semantic interoperability, automated service discovery, policy matching, and cross-organization concept alignment. It is a foundation for modern governance and integration.
❓ Q: How should the three parts be rolled out together?
A: Proceed in the order Parts 1, 2, and 3: unify terminology first, then design the reference architecture, then freeze the semantic model as an ontology — while iterating governance mechanisms throughout the process.
A: Proceed in the order Parts 1, 2, and 3: unify terminology first, then design the reference architecture, then freeze the semantic model as an ontology — while iterating governance mechanisms throughout the process.