I love this I think its great... now can someone tell me how on earth it maps to anything that MS are doing in the market right now?
Steve 2009/1/18 Gervas Douglas <[email protected]>: > You can read the following article at: > > http://www.infoq.com/articles/soa-contract-maturity-model;jsessionid=A4FA64435750D836AA32113976421FFE > > Gervas > > <<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. ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
