Posts Tagged ‘maturity’

A SOA Maturity Model

May 15, 2010 Leave a comment


Purpose and Scope

This describes proposed Service Oriented Architecture (SOA) Maturity Model that be can be customized for evaluating SOA maturity in your organization. The goal of the model is to provide a framework to evaluate the progress of an evolution to services orientation. Additionally, the model serves as guidance to develop an execution plan for incremental services adoption within an organization. Several existing models were consulted in the development of this model such as the open model currently being developed by the Open Group.

What is Services Orientation

Services orientation is NOT about creating web services. In fact, services orientation does not require web services technology; however, leveraging web services technology is tool for achieving some of the goals of services orientation.

Services orientation from a business process perspective is about defining discrete business processes/offerings and understanding how those discrete business processes can be composed into larger process or new offerings. For example, opportunity identification is a discrete business process that is part of the:

  • network formation
  • creating new client engagement
  • identify savings opportunity



Identifying discrete processes allows organizations deeply understand the processes, identify opportunities for optimization, and monitor the processes to ensure they are efficient. The more the underlying process is reuse, the more valuable these activities become.

Services orientation from a technical implementation perspective is an approach to designing, implementing, and deploying solutions such that a solution can be created from components implementing discrete business and technical functions. These components, called “Services”, can be distributed across geography, across enterprises, and can be reconfigured into new processes as needed.

Characteristics of Service Oriented Solutions

  • Component Oriented – Service oriented solutions are component oriented. Component orientation means that each service performs a cohesive and logical set of activities for a single concept. For example, a payroll service might provide functions such as issue W2s and issues checks or a data access technical service might provide functions such as persist entity.
  • Composability – Service oriented solutions support composition into new services and solutions without impacting the existing service implementation.
  • Platform and Location Transparency – Service oriented solutions do not require that services be implemented on the same technology platform or in the same location.
  • Broad Interoperability – Services oriented solutions should support standard protocols to ensure the highest level of interoperability.
  • Self Describing – Services should be self describing.  The interface to the service and its operations should be discoverable via meta-data, not out-of-band communications (e.g. document)
  • Message Oriented – Information is transmitted to and from services as messages. The focus in the definition of the interface and messages is in “what” a service does rather than “how”. The “how” is internal to the implementation of the service.

Business Benefits of Services Orientation

Service orientation has numerous benefits including:

  • Delivery Time and Cost – Knowledge transfer time is reduced within projects in a matrixed staffing model as resources transition between projects. If developers are trained on enterprise level shared services, the knowledge is transitive between projects. Further, each project does not have to go through the effort recreating  functionality that has been previously delivered. (see Evaluating Existing Assets for Reuse)
  • Business Responsiveness – Delivery of solutions through composition is faster than constructing solutions from scratch as higher levels of service maturity are achieved. This becomes especially tool as tools such as Enterprise Service Buses (ESB) are put in place that can mediate normally complex concerns such as service security and protocol variances across services.
  • Product Stability – Solutions that reuse services instantly gain the benefit of testing and tuning that has been performed. If the same functionality is developed over and over again each project has to potentially goes through the same learning and address the same defects.


Model Overview

A maturity model is a benchmarking system to measure progress toward a goal based on a set of objectives. A maturity model can provide a means for developing a transformation roadmap to achieve a target state from a starting state. The model defines the change, by area of concern, required for an organization to mature.

This maturity model focuses exclusively on services. It can be used as a standalone maturity model or in conjunction with a more broadly scoped maturity model such as CMMI. This model will allow a organiation to objectively assess if it is gaining the capabilities necessary to leverage services in an increasingly more sophisticated and beneficial manner. This model is a customization of the multiple services maturity frameworks such as those  developed by the Open Group (OSIMM) and the services maturity model developed by Gartner. It also recognizes some of the work done in SoMa by IBM.  It is organized in a matrix of seven disciplines and four maturity levels as illustrated below:

Stage 1Introduction Stage 2Spreading Stage 3Collaborating Stage 4Optimized
Business {Goals} {Goals} {Goals} {Goals}
Organization & Governance {Goals} {Goals} {Goals} {Goals}
Methods {Goals} {Goals} {Goals} {Goals}
Operations {Goals} {Goals} {Goals} {Goals}
Architecture {Goals} {Goals} {Goals} {Goals}
Information {Goals} {Goals} {Goals} {Goals}
Infrastructure {Goals} {Goals} {Goals} {Goals}

Table 1 – Maturity Model Matrix

The model details:

  • the benefits that can expect to be gained by matriculation to higher levels of maturity
  • goals for each level

The model is guided by the principles specified in the services Manifesto at

Maturity Levels

Maturity Level Concept

Maturity levels are used to categorize, into distinct stages, how wide and deep transformation has occurred within the organization. The services model is composed of four levels:

  • Initial
  • Spreading
  • Collaborative
  • Optimized

with level 1 being the least mature services adoption and level 4 being the most mature. Higher degrees of maturity are likely to lead to a higher degree of business and technical agility, but also require that the organization become proficient in an escalating set of organizational and technical capabilities.  The organization must be committed to making deep and wide-spread changes in not only in technology but also how business processes are described, implemented, and measured. While this does seem broad reaching every effort should be taken to make an “appropriate bite” for your organization. If your organization has process improvement initiatives in place a top down domain modeling approach might be the best way the starts versus implementing low-level technical techniques for reuse.

This model represents a middle out approach first developing some technical assets for reuse for common cross cutting concerns and then address more coarse-grained scenarios such as actual processes. I am not arguing this the only or even the best way to go for all organizations.

The table below provides a brief overview of the high level goals of each level. Subsequent sections will examine each level in detail.

Stage 1Initial Stage 2Spreading Stage 3Collaborating Stage 4Optimized
Business Goals Address Specific Pain Process Integration Process Flexibility Services for Sale
IT Goals Project Level Guidance
Core Service Standards
Some Shared Services
Service Design Standards
Service Reuse
Service Composability
Business Process Monitoring
Runtime Service Governance
Software as a business service
Event Driven Architecture
Service Scope Single Application/Project Single Business Unit Multiple Business Units Customers and Partners

Table 2 – Maturity Level Overview

Stage 1: Initial

The Initial maturity level is the first stage of the model. Level one is focused on:

  • Achieving component orientation
  • Project level services
  • Establishing a baseline enterprise level technical standards and guidance
  • Defining an approach to services delivery

Within this level, initial R&D activities to evaluate services technologies and techniques are conducted in a laboratory environment. The selected techniques are then applied within projects to solve specific problems. Additionally, it is at this level when basic standards and organizational structures required to support services are defined.

Stage 2: Spreading

In the Spreading level, shared services are developed using the standards and processes defined in the initial stage. This level focuses on services enablement within the boundary of single a business domain. In addition to actual service development, the infrastructure is put in place to more pervasively share services from project to project such as executing service governance processes and a service registry.

Stage 3: Collaborating

The Collaborating level is focused on leveraging the services developed for individual business domains to:

  • Compose cross business domain services
  • Identify business metrics to monitor on a real-time basis (e.g. number of  price comparisons per hour)

In addition, the services previously developed will be evaluated for overlap, redundancy and opportunities for consolidation.

From a services infrastructure perspective, the goal will be to implement tools that support runtime governance and management of services to improve configurability and location transparency which results in improved agility.

Stage 4: Optimized

The Optimized level is most sophisticated level of service maturity. It builds on the accomplishments of previous levels and focuses on service enablement externally to customers.


Disciplines represent different views or concerns of the organization


The Business discipline addresses the organization’s current business practices and policies, how business processes are designed, structured, implemented and executed.

Organization & Governance

The Organization & Governance discipline address the structure and design of the organization itself and the measures of organizational effectiveness in the context of services governance.  The Organization aspect is focused on organizational structure, relationships, roles and the empowerment necessary to adopt a service- oriented strategy. Governance is associated with formal management processes to keep IT activities, service capabilities, and services solutions aligned with organizational needs, guidelines, and standards.


The Methods discipline is focused on the methodology and processes employed by your organization to design, deliver, and manage service oriented solutions. Existing processes such as the Software Development Lifecycle (SDLC), operations management, and portfolio management will need to be updated to include services related check points.


The Operations discipline addresses the structures, processes, and assurances that must be in place for operational supportability of service oriented solutions. If a solution is not supportable are runtime or issues cannot be quickly identified and corrected reuse is unlikely even if the solution is functionality sound.


The Architecture discipline is focused on the structure of the architecture which includes topology, integration techniques, enterprise architecture decisions, standards and policies, web services adoption level, experience in services implementation, services compliance criteria, and which architecture artifacts are produced.


The Information discipline is focused on how information is structured, how information is modeled, the method of access to enterprise data, abstraction of the data access from the functional aspects, data characteristics, data transformation, handling of identifiers, knowledge management, business information model, and content management.


The infrastructure discipline is focused on the physical hardware and tools that are in place to support service oriented solutions.

Assessing Maturity

Maturity Goals Matrix

Stage 1


Stage 2


Stage 3


Stage 4


  • Define business domain prioritization

  • Business Service/Function Catalog
  • Process and Decomposition Models
  • Application and Component to Business Process Matrix
  • Domain Level Services

  • Composable Business Processes
  • Service to Business Process Matrix

  • Services for sale/use by external partners
  • Real-time business process metrics
  • Organization & Governance
    • Services COE Team Created
    • Pilot Services Governance Plan
    • Developers learn component oriented development skills

    • Implement services Governance Plan
    • Design time capture reuse metrics
    • Developers learn service oriented development skills
    • Refine SOA metrics including ROI
    • Runtime Service Governance Standards
    • Services Support Team
    • Runtime capture reuse metrics

    • Integrate Services Management into Product Management
    • Define vendor on-boarding and certification practices
    • Standardize Development Methodology
    • Reuse Evaluation Strategy Defined


    Service  Design Methodology  




    • Binary dependency management guidelines
    • Source management standards

  • KPIs and SLA Categories and Metrics Defined

  • Monitor KPIs and SLAs real-time
  • Service virtualization
  • Service configurability to support non-functional needs (e.g. translation between WS* protocols)

  • Runtime service governance
  • Dynamic exception and SLA management
  • Architecture
    • Service Development Standards and Guidelines



  • Service Design Guidelines
  • Service Reference Implementation
  • Establish architecture repository

  • Transaction Management Standards
  • Best practice guidance for event driven SOA


    • In scope data domains
    1. Domain Level Canonicals

  • Enterprise Business Data Directory
  • Enterprise canonicals
  • Data as a service/data federation

  • Industry canonicals
  • Analytics  as a service
  • Infrastructure
    • Shared Services Physical Environment (UIT, SIT, PROD)

  • Services Repository
  • ESB
  • Shared Services Physical Environment (PERF TEST)

    • BPM/BAM Middleware
    • Runtime Service Governance/Management Platform (with Policy Registry)
    • Security Federation Platform
    • Business Rules Engine
    • XML Firewall
    • Complex Event Processing Engine (CEP)

    Maturity Benefits Matrix

    Stage 1Introduction Stage 2Spreading Stage 3Collaborating Stage 4Optimized
    • Reduction in project delivery effort related to technical asset reuse
    • Improved cross project consistency
    • Increased developer knowledge or core component and service concepts

  • Increased ease of modification
  • Improved operational supportability
  • Reduction in functional defects
  • Project cost and effort reduction

    • Project cost and effort reduction
    • Improved business responsiveness
    • Improved application availability
    • Closer IT alignment to driving business value

    • Enhanced ability to proactively  optimize business processes  (due to availability of real-time process metrics)
    • New revenue opportunities
    • Project cost and effort reduction

    Assessment Process

    It is recommended that services maturity be assessed at least on an a bi-annual  basis. For each goal, by discipline the team should define and collect metrics and information to determine if has obtained the goal.

    Assessment Questions and Metrics