Importance of a SOA Maturity Model

I talked a little about the Maturity Model concept in my blog entry about Simplifying Build Management – Build Once, Deploy Anywhere. One of the more well know Maturity Models is called CMMI (Capability Maturity Model Integration). In the presentation Capability Maturity Model Integration (CMMI) Version 1.2 Overview, there are descriptions of a “Process Model” that helps lay the foundation of the benefits of a Maturity Model.

A process model is a structured collection of practices that describe the characteristics of effective processes.
A process model is used

  • to help set process improvement objectives and priorities
  • to help ensure stable, capable, and mature processes
  • as a guide for improvement of project and organizational processes
  • with an appraisal method to diagnose the state of an organization’s current practices

The Maturity Model helps to define an architectural framework, what different levels of implementation can be achieved with the framework, ability to measure improvement of its usage, and the ability to assess the state of that architectural framework. The Maturity Model puts a subject like SOA into a framework and creates multiple maturity levels that define initial stages, all the way to advanced stages of the SOA process. This tutorial site provides a clear definition around what a maturity level is:

A maturity level is a well-defined evolutionary plateau toward achieving a mature software process. Each maturity level provides a layer in the foundation for continuous process improvement.

So we essentially have two maturity models that we are leaning on with regards to the standup of our SOA initiative. The initial example is from a document written in 2005 by Sonic Software Corporation (A NEW SERVICE-ORIENTED ARCHITECTURE (SOA) MATURITY MODEL). This provides an excellent example view into the different layers of a SOA Maturity Model and then finer grained discussions around each level. The following is the example Service-Oriented Maturity Model from this document:


We can see from this model that we have 5 essential levels for achieving SOA. The 5 maturity levels defined here are Initial Services, Architected Services, Business/Collaborative Services, Measured Business Services, and Optimized Business Services. These different maturity levels allow us to evolve our SOA initiative over time and validate that we are correctly progressing through those levels. For instance, one of the recommended steps for implementing an SOA is to utilize a Enterprise Service Bus to stand up some initial services (in order to create a starting point). It’s easy to determine the success of the overall SOA initiative based on this initial phase, which might give a view that the SOA initiative is not successful. This might be because the right types of services are not being exposed, or composite services aren’t being created, advanced standards aren’t developed, and so forth. But in the context of a Maturity Model, it allows us to evaluate our current SOA initiative against the different levels and determine that we have successfully achieved Level 1, lining up what is necessary for us to move towards Level 2 of the Maturity Model.

primobolan depot

Another Maturity Model for SOA is provided at Griffiths Waite – the Oracle SOA company. This is defined more clearly in the resource document SOA Maturity Model – Quick Reference Guide.


This Maturity Model also provides 5 phases called Opportunistic, Systematic, Enterprise, Measured, and Industrialised. This documents the evolution of SOA from initial services, to the development of standards, to utilizing BPEL for integration of multiple services, then utilizing BAM to monitor and measure services, to the ability to be completely agile via the previously successfully implemented 4 phases.

The following article provides a landing page for quite a few different SOA Maturity Models.

The fact is that starting a SOA initiative is a massive undertaking with many moving pieces and steps. It is easy to become overwhelmed as to the correct processes and architecture necessary to achieve the SOA end state. The benefit of aligning these initiatives with a SOA Maturity Model is that we are able to partition our SOA intiative into individual levels/stages so that we can achieve SOA in more manageable chunks. At the end of each phase of our SOA, we can determine whether or not we have evolved to the next phase of the SOA Maturity Model and what is left to accomplish our current level.

Share and Enjoy

XML Standards for Service Modeling

When designing web services, it becomes apparent that it is necessary to lock in standards for designing the service contracts as well as the service models. In an effort to standup the initial phase of the SOA Enterprise, many services begin to expose themselves on the ESB that either are driven by a legacy system (such as a mainframe generated service) or by developer building the models in isolation. Since the goal is to drive towards a common Canonical Model, it is important to define a set of standards around how Schemas are designed and rules that need to be followed when creating them.

If we do a little googling, you might land on the Oasis XML Coverpages website, which is a great resource for XML based standards groups. The XML Coverpages site has a landing page for Naming and Design Rules. One of the resources made available in the table listing of this page is the “UN/CEFACT XML Naming and Design Rules”, which has two great resources.

UN/CEFACT 8 XML Naming and Design Rules Technical Specification 9 Version 3.0
UN/CEFACT/UBL XML Naming and Design Rules Analysis

The “UN/CEFACT/UBL XML Naming and Design Rules Analysis” is a spreadsheet that can be downloaded in DOC format. It refers to another document called Universal Business Language (UBL)
Naming and Design Rules
. These documents provide some very detailed discussions around the standard uses of XML Schemas and the implementation of the XML Schema to create Models. This might be as detailed as to the types of names of elements, what attributes are expected, and whether or not features in the XML Schema Specification can be used at all (like xs:all).

Another one of the interesting examples is the Department of the Navy
XML Naming and Design Rules
because of the great detail an explanation of all the different types of rules and usage standards.

In reading these documents, it becomes quite apparent how difficult it can be to produce the ideal environment for Service Modeling, let alone the complexities/capabilities in utilizing the XML Schema Specification. These concepts are very important in a SOA that pushes a Contract-First methodology, where the WSDLs and Schemas will be designed and developed first. One of the books for Java web service development talks about a bridged approach between the Contract-First and Code-First called Code-First/Contract-Aware.

Here is the book

This is really about taking advantage of the great annotation support in JAX-WS and JAXB to replicate the standards for Service Modeling within the annotations themselves. While you have more power in developing the XML Schemas directly, the simplicity that is provided through the JAXB annotations cannot be understated. Even with the power of JAXB annotations, standards will be necessary for the names/features that are used with the framework, along with defining how to implement complex JAXB representations such as Maps/Enums/Collections.

For some businesses, these documents and their detail maybe overkill, but there is probably some value at least in having some generalized rules for XML naming and design (such as not having verbs in the Schema names except for the introduction of operations within the WSDL, or the names of elements and what detail they are, etc). Having a set of some core rules and definitions will ease the integration of development teams into the enterprise SOA.

Share and Enjoy

Service Layer and Model Design

When designing services, it is important to create categories that the different types of service requirements fall into. This allows us to establish standards, best practices, and reference implementations for those types of services. Also, we can better understand the problem domain by understanding the service requirement and then being able to apply a solution for all services within that service layer.

Two of the better books for service layers and models are:

These books refer to concepts (such as Thomas Erl talks about at, three types of service layers called task service layer, entity service layer, utility service layer. You can find an explanation for these at the following site: – Service Layers

We can see a similar concept when reading the Oracle SOA Reference Architecture, the following diagram is a representation of that from a technical article. It classifies different service layers and the types of services that exist.

A Guide to Ensuring the Success of Your SOA Governance

There is also a similar reference or description within the Oracle AIA (Application Integration Architecture) documentation:

Understanding the Oracle AIA Reference Architecture

The interesting thing about reading through the materials, is that the concept of designing services or web services is no different from designing proper APIs. The issue is that as teams are new to the concept of designing services, the concept seems foreign and therefore is treated totally different from API design (which is probably a reflection of sloppy API design). So taking these suggested categories, and the concepts for strategies that are used for Java Application development we can define some generic service types.

The following are the types and these services are based on a functional role, some standards that help drive how they are developed, what dependencies they have, and what standards are applied to them.

  1. Access Service
  2. Utility Service
  3. Data Service
  4. Search Service
  5. Messaging Service
  6. Subscribe Service
  7. Business Service

This blog is a work in progress and I will continue to update with additional information.

Share and Enjoy