Many organizations tell us they are classifying SOA as mainstream – that is the architectural pattern and associated technologies are mandated for all projects and programs and strategic applications are progressively being modernized with service interfaces. Further, as organizations’ use of SOA matures, we observe increasing commitment to common, cross-cutting capability and core business services which naturally lead to standardization of the service portfolio.
This progressive maturing of SOA capability requires consistency of approach across disparate programs that facilitates collaboration and effective governance and naturally creates the requirement for standardization of reference models and reference architecture.
Whilst there is a plethora of reference materials from the standards organizations such as OASIS, The Open Group, The OMG and ITIL(OGC) it’s clear that in addition to inconsistency of definitions and expression, most of the standards are abstract and narrowly focused on core concepts and ontology. Whilst these standards are often very useful in guiding conceptual understanding, they may not provide the detailed models on thebroader scope required by practitioners to establish best practices for architecture and solution delivery teams.
What’s required from an SOA reference model:
- a basis for common agreement on concepts across disparate groups that allows sharing of models.
- at a level of detail that is unambiguous and supports tooling. A fully detailed UML model, defined, enumerated and attributed.
- across a scope that supports a typical end to end business project covering: business models, service specification, service implementation, solutions, deployment and runtime, technology, testing, policy and organization.
- an attempt at some level of compliance with the various standards groups, recognizing that there is no single model or agreed ontology, nor standardization of definitions or expression.
In order to support use cases:
- integrate SOA into wider business practices:
- - - - enterprise architecture
- - - - solution architecture
- - - - business modeling
- - - - BPM
- - - - application delivery projects
- support common service definition across ecosystems such as industry groups, supply chains, business partners
- define policy relating to reference model compliance (and thereby support governance of same)
- define required traceability
- support seamless interaction between teams (and parties) carrying out business modelling, service architecture and design, provisioning/procurement, implementation, test, service management and operation
- eliminate ambiguity in service agreements with outsourcing and offshore parties
- support common schema definition for what may be a disparate set of tools being used in modeling, asset management, cataloguing, version and configuration management
- support definition of a set of common and or project specific deliverables across the architecture and delivery life cycle
- support creation of UML Profile or domain specific language (DSL)
The Everware-CBDI SOA meta model attempts to meet the above requirements and support these use cases. You can download the V3 model here.