The Contract Versioning, Compatibility & Composability article at InfoQ covers a wide range of SOA aspects, both design-time and run-time design and governance aspects. This article is about showing how the recommended contract design policies from the versioning article relate to a SOA Maturity Model. This relationship offers a roadmap for how to achieve the full feature set of contract versioning and composability described in the InfoQ article. Policies are intentionally not covered here.
The SOA Maturity Model (SOAMM) is used by Microsoft to assess the state of SOA at a customer and provide a roadmap for getting in position to deliver the business agility promised by SOA. SOAMM is based on CMM, and SOAMM has four levels of increasing maturity:
- Basic
- Standardized
- Advanced
- Dynamic
SOAMM consists of 36 technology-independent capabilities and serves as the guide for what is possible and what is required of your IT systems to realize the value of a service-oriented approach. The model was developed in conjunction with Microsoft product teams, technical evangelists, and our customers, and is based on our global best practices.
The capabilities are grouped into three perspectives:
Service Implementation
This model perspective describes capabilities of an enterprise to implement efficient best practices, patterns in building and providing services. Achieving this capability strengthens and optimizes the design and development of enterprise business and system services.
Service Consumption
This model perspective describes capabilities of an enterprise to effectively adopt and promote use of services. This capability provides foundation for support and enhancement the consumption of enterprise services by others.
Service Administration
This model perspective describes capabilities of an enterprise to support the cross-organization governance and operational aspects of services.
You can target your SOA initiative at selected capabilities at level 3 or 4, but without having the related foundations from level 1 and 2 in place, you risk building a system with clay feet – and someday your services architecture will require a major restructuring and rewrite to align with recommended practices.
Basic Maturity Level
Studies show that approximately 82% of companies are at this SOA maturity level. Don’t be disappointed if your maturity level is basic, it is perfectly ok to be at this level when starting your SOA efforts or having only a small number of services.
Explicit Contracts:
This Consumption capability is based on one of the four classic SOA tenets: “Services must share schema and contract, not implementation”. The contracts for services and schemas (messages and data) must be based on the business capabilities and related business documents that the SOA system is intended to support. A contract should never be just a thin wrapper around some RPC-based object model, but rather use service-oriented messaging based on service interfaces using a logical data model as shown in the foQ article.
This basic capability is a starting point that I recommend to quickly evolve into using standardized contract design policies and a common information model (see “Design Patterns”, “Uniform Contracts”, “Common Entities”, “Consumable Type System”).
Service Identification (Promote Services):
This Consumption capability is the basic variant of the Standardized maturity level “Service Discoverability” capability, i.e. it is the typical manual service metadata distribution to potential consumers.
As we described in the InfoQ article, service discoverability is central to service composition. Service metadata comprises both machine readable metadata and other relevant information such as service description and SLAs. Both types of metadata must be subject to a versioning policy as described in the versioning article.
Note that the service-oriented modeling design task service identification is is part of the “Service Boundaries” capability.
Service Boundaries:
This Consumption capability is really about enabling discoverability and reuse through applying business process modeling and domain driven design modeling techniques to group business capabilities into services. It is about enabling potential consumers to discern through contract metadata which service and capability may best meet their need.
The identified service boundaries (domains) should be combined with a service model and a data model to evolve them into becoming standardized service contracts (see “Enterprise Governance” , “Uniform Contracts”, “Common Entities”, “Consumable Type System”).
This capability is classified as Consumption, and not Implementation, to adhere to the “Service Loose Coupling” principle in the classic book “SOA Principles of Service Design” b” by Thomas Erl. The best practice is to avoid tight coupling of the service interface and schemas to the underlying implementation and technology. It is also a strong indication that contract-first design is to be preferred.
Development Process Efficiency:
This capability is supported by the recommended contract design policies (indicated by the dotted oval in the SOAMM figure).
The process for designing, implementing and evolving services must follow a well defined software development lifecycle (SDLC), supported by applicable tooling. The SDLC model must be in place from the very beginning, but will benefit from the guidelines and policies defined by the other SOA capabilities as your maturity level improves (see “Design Patterns”).
Revisit this basic capability as the other capabilities evolve to improve your development process efficiency. E.g. the time and effort to design, implement and deploy a new service operation to provide a needed business capability will benefit from having standardized contract design guidelines, a common information model, policies for service abstraction and loose-coupling, and a well defined test and deployment process.
Standardized Maturity Level
As the number of services grows to satisfy the demand to provide more and more business capabilities, it is strongly recommended to include the Standardized maturity level capabilities in your SOA architecture and design practices.
Enterprise Governance:
You should always have a service model that classifies services according to taxonomy. In addition, I strongly recommend that you create and use domain data models that your schemas are based on. Such as data model is known as a Common Information Model (CIM). See also “Common Entities”.
In In addition to the design-time governance aspects, run-time governance aspects related to service versioning will be covered in the “Deployment Management” and “Advanced Monitoring” capability sections.
Uniform Contracts:
This Consumption capability is the same as the “Standardized Service Contracts” principle. It extends the “Explicit Contracts” basic capability with standardized uniform design policies for the contract artifacts. Having standardized contracts is important to make it easier for potential consumers to discover, discern and use services. Just as Thomas Erl recommends using a common data model, this capability is closely related to the “Common Entities” Implementation capability.
Service Discoverability:
“Service Discoverability” is one of the central SOA principles. As we explained in the oQ article, composition is not only dependent on services and schemas being designed for reusability, they must also be easily discoverable by potential consumers. It is recommended to use a repository as your service inventory management system, giving you SOA governance tooling and a registry publishing mechanism.
Service Discoverability is central in SOA governance to keep the number of contracts and their versions down, benefitting both development and operations of services. It is strongly recommend that the contract metadata artifacts such as services and schemas is versioned and governed. This is the main message of our InfoQ article.
Loosely-Coupled Compositions:
This Implementation capability is a bit of a misnomer as it mixes the pertinent “Service Loose Coupling” principle with the “Service posability” principle. Loose coupling together with the “Service Abstraction” principle and the “Service Reusability” principle are central enablers of composable services. As we point out in the data models section in the InfoQ article, you must strive to achieve loose coupling when designing your schemas (and also your services), don’t expose the implementation details of the underlying logic or system in the contracts.
Designing for reusability and having a versioning and compatibility policy is central to achieve composability. Note the distinction between reuse and reusability; don’t try to do speculative contract design for a broad range of potential future consumers that may (re)use the service. Rather design the service to be a textbook constituent in composite services and processes – reusability. It is of course beneficial if multiple consumers can share the provided service.
Design Patterns:
This Implementation capability is closely related to the basic “Development Process Efficiency” capability. The policies and guidelines identified as your maturity evolves into using principles such as “Uniform Contracts”, “Common Entities” and “Consumable Type System” must be defined and enforced as part of your SOA governance design policies. Using common design patterns is a central enabler for adhering to the “Standardized Service Contracts” SOA principle.
Common Entities:
This Implementation capability is about having common formats for the data used in business processes across the enterprise. This enterprise data model is known under a multitude of names, the most common seems to be Common Information Model (CIM). It is the service-oriented sibling of the EAI Canonical Data Model (CDM) as defined by gor Hohpe and Bobby Woolf in the classic book “Enterprise Integration Patterns”.
Note that employing a CIM is not to be interpreted as a recommendation to try to enforce a “one true schema” model across all your systems. Rather, use several federated CIM models based on the Domain Driven Design approach.
As described in the InfoQ article, the data model is the basis for creating and maintaining the schemas flowing through services and business processes. Both messages and data schemas must be based on the data model - the message schemas being projections of one or more data schemas. Data schemas must be designed for reuse, while the message schemas by design will be specific to their operations. This modeling concept is part of the Advanced maturity level “Consumable Type System” capability.
Advanced Maturity Level
A truism in any software system is that the only constant is change. Changed business requirements will compel your services to evolve, which should cause you to include Service Lifecycle Management (SLM) capabilities in your SOA architecture and design practices.
Deployment Management:
Service Lifecycle Management is a central part of SOA governance. SLM comprises both design-time and run-time aspects. Together with versioning, SLM is the core of the Administration “Deployment Management” capability. Your SDLC process needs to have a clear model for how to deploy new services and new versions of services, in addition to how to decommission existing services.
“Deployment Management” must be combined with the “Enterprise Governance” capability to aid the service inventory steward (custodian) with the soft aspects of SLM, e.g. communicating service lifecycle changes to affected consumers.
In the InfoQ article we recommend having an “active service versions” policy as part of this capability, in combination with selected enterprise service bus patterns as part of a service virtualization mechanism. Refer to the article for more details on service virtualization.
Advanced Monitoring:
This capability supports the recommended contract lifecycle policies (indicated by the dotted oval in the SOAMM figure).
As part of your Service Lifecycle Management model, you should monitor all your individual services to give the service inventory steward (custodian) visibility into the usage of the services. This will aid their work when introducing new versions, by letting them communicate to relevant consumers that they’re using a deprecated or decommissioned service and need to upgrade.
Consumable Type System:
This Implementation capability is about having a consumable definition of all the components in your SOA ecosystem: services, entities, processes, rules, implementations, policies, bindings, and other service components.
The common information model that defines the schemas of the “Common Entities” will be an essential part of this type system. The message and data schemas used in services and processes must also be part of this type system.
This capability will trigger the need for having a metadata repository if you’ve managed without one so far. A repository is needed to promote development efficiency, discoverability and reuse, versioning, impact analysis and visibility into how the components are used. E.g. make it possible to see where common entities are used in services and messages.
The repository will be a natural source for modeling the common entities and also for modeling the related message and data schemas. Generating all contract schema artifacts from a single source will benefit schema compatibility and service composability. Refer to the InfoQ article for more details on modeling contract schema artifacts.
Versioning Support:
Contracts need to evolve to adapt to changed business needs, and this affects both services and schemas. You will find that as your SOA systems grow and change, you will need to have versioning polices for all contract artifacts: service interfaces, messages and data schemas, policies, etc. The versioning policies must comprise both design-time and run-time aspects, and should be enforced through SOA governance. I recommend reading the Contract Versioning, Compatibility & Composability article at InfoQ for guidelines on how to implement this Advanced capability.
Note that even if “Versioning Support” is an Advanced capability in SOAMM, as it is closely related to doing Service Lifecycle Management, it is strongly recommended to start designing your contracts for compatibility as early as possible. Having a service and schema compatibility policy is not dependent on doing full-fledged versioning and SLM capabilities. Versioning will become required when the number of services that are just multiple variants of the same service becomes a pain for consumers, for operations and for provider maintenance. In the long run, with an increasing number of active service versions, your service inventory will become utter chaos without versioning and SLM governance.
A lot of people try to avoid moving to this contract maturity level by extensive use of wildcards to avoid versioning. This is absolutely not recommended, as it leads to vague contracts that don’t express semantics very well, countering service discoverability. However, judicious use of unambiguous wildcards can help minimize service versioning by providing schema compatibility.
Versioning lets you control the effects of changes; compatibility helps you alleviate some of the negative effects of versioning.
Dynamic Maturity Level
These days the main value promised by SOA has shifted from reuse of services to business agility. The Dynamic maturity level is about being able to quickly model, compose and change processes built from your service inventory in response to changed business requirements.
Progressive Composition:
This capability is supported by the recommended contract design policies (indicated by the dotted oval in the SOAMM figure).
The services in your service inventory should be designed according to the “Service Composability” principle, adhering to the recommendations for having a service model and a data model, and the other recommended design guidelines and policies - enforced through SOA governance.
Provided that you have the foundation capabilities in place, you should be in position to implement composite services and orchestrations in response to business needs. It is my claim that having versioned services and schemas based on compatible, federated information models will enable progressive composition of services.
Trying to compose services that are not designed according to the recommended contract design policies will be hard. It will e.g. require extra effort to transform the data in messages between different formats when advancing through the steps of a process. Designing for service composability will lessen the need for using complex enterprise service bus patterns (ESB) or for investing in a full-blown ESB platform.
ThiThis Dynamic Implementation capability provides the platform for composing and executing business process.
Process Modeling Support:
This capability is supported by the recommended contract design policies (indicated by the dotted oval in the SOAMM figure).
This Dynamic Implementation capability is about support for modeling of services from the inventory into processes and workflows. It also includes modeling of decision rules for process flow. This capability provides the necessary tooling to allow the appropriate roles in the organization to define and manage the business capabilities and processes they are responsible for. Modeling processes using e.g. BPMN diagrams or UML Activity diagrams is facilitated by having an inventory of composable services with compatible data models.
PolPolicies can also be applied to the modeled processes. Such policies are e.g. permission checks, confidentiality and integrity requirements, and Business Activity Monitoring (BAM) logging for visibility into how the business processes perform (KPIs). Note that modeling dynamic policies driven by rules is a separate capability.
Conclusion
As this article has shown, the aspects of contract versioning and composability cover the full spectrum of SOA maturity levels. There is, however, no need to do a big bang approach and try to cover all the different capabilities at once - start small at Basic and aim to become Standardized as your number of services grows. This should concur with the need for SOA governance; in fact design-time governance is needed to enforce standardized services.
As your services become widely popular and heavily shared by a multitude of consumers, you will need to implement some Advanced maturity level capabilities such as versioning and deployment management to do professional service lifecycle management.
As your maturity evolves, you may end up at the Dynamic maturity level, being able to support the promised service reuse and business agility – reaching the renowned benefits of SOA.