The Open Group Service Integration Maturity Model (OSIMM) Version 2 – Architecture Dimension: Base Model

 

This chapter defines the base model for the OSIMM Architecture dimension base model. The base model defines a set of generic maturity indicators and attributes that can be used to assess an organization’s SOA maturity level against the OSIMM maturity matrix. Additional maturity indicators, assessment questions, and attribute mappings can be added by vendors or user organizations to extend the base OSIMM model.

The assessment questions that follow help elicit the level of formality to which an organization has formally adopted SOA design methods, principles, and frameworks. Maturity ranges from monolithic architecture to dynamically reconfigurable architecture.

OSIMM Architecture Dimension

Architecture Dimension: Base Model Maturity Indicator

The base OSIMM model provides one of many possible maturity indicators per dimension. Organizations, vendors, and consultants can provide additional maturity indicators, assessment questions, and attribute mappings to provide additional guidance necessary for the maturation of an organization’s SOA.

The following Architecture dimension maturity indicator is provided as part of the base OSIMM specification:

  • An SOA maturity assessment of the OSIMM Architecture dimension can be conducted by identifying those service components that have been designed and are deployed using formal SOA methods, principles, patterns, frameworks, or techniques.

Architecture Dimension: Assessment Questions

By gathering information using these assessment questions, an assessor can map a maturity indicator to the associated maturity attributes, thereby determining the Architecture dimension maturity level.

  1. How would you characterize your architectural topologies?
  2. What type(s) of data repositories does your organization utilize?
  3. What is the standard communication style in your architecture?
  4. How is integration achieved in your architecture?
  5. What methods do you use to develop your architecture?
  6. How mature are your services implementations?
  7. How extensive is your SOA?
  8. What architectural principles define your approach?
  9. How extensive and sophisticated is your organization's use of frameworks in your architecture?
  10. How are architectural decisions made in your organization?
  11. Does your organization use reference architectures?

Architecture Dimension: Maturity Indicator-to-Attribute Mapping

The following are the base set of maturity indicators for the OSIMM Architecture dimension. Each maturity indicator is associated with a set of maturity attributes. Maturity attributes are those observed characteristics of a maturity indicator for each maturity level. The assessment questions are used to survey an organization’s Architecture dimension. Survey data obtained through the Architecture dimension assessment questions is used to determine the maturity level by assessing the data and matching to the maturity attributes that best fit the information obtained. The maturity weighting is used to determine an average maturity score across multiple maturity indicators. The model can be extended by adding additional maturity indicators and assigning weighting to the indicator by maturity level according to the value placed on the maturity indicator by the assessing organization.

Maturity Indicators for the Architecture Dimension

Maturity Level
Cell Name

Maturity Indicator

Maturity Attributes

Maturity Weighting

Assessment Question Mapping

Silo
(Level 1)

Monolithic Architecture

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Low or nonexistent

No SOA methods or practices are apparent.

10

 

1, 7

Integrated
(Level 2)

Layered Architecture

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Limited

Limited use of formal SOA methods and practices can be observed.

Methods and practices are limited to integration between applications or systems.

20

 

1, 2, 5, 6, 7



4, 8, 9

Componentized
(Level 3)

Component Architecture

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Cross-organizational

Formal SOA methods and practices are employed by multiple groups within the enterprise.

The organization has a loosely defined enterprise architecture supported by limited tooling and governance practices.

30

 

4, 5, 6, 7, 8




9, 10, 11

Services
(Level 4)

Emerging SOA

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Enterprise-wide

Formal SOA methods and practices are employed across the enterprise supported by a formal governance process.

Applications and services are designed using formal SOA principles and patterns.

40

 

4, 5, 6





1, 7, 8, 11

Composite Services
(Level 5)

SOA

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Integrated Enterprise-wide

Enterprise frameworks and practices supported by the use of a formal SOA method and reference architectures across the enterprise.

A formal enterprise business information model is evolving.

50



7, 8, 9, 11





2, 10

Virtualized Services
(Level 6)

Grid-enabled SOA

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Integrated across the enterprise and externally between business partners.

Service components are designed using formal methods, practices, and frameworks that promote the re-use of assets.

Formal enterprise-wide business information services have been developed and deployed.

60





1, 3, 4, 5, 6, 9




2, 8, 10, 11

Dynamically Re-Configurable Services
(Level 7)

Dynamically Re-configurable Architecture

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Adaptive Enterprise

Service components are designed using formal SOA methods, principles, patterns, frameworks, or techniques.

Formal enterprise business information services have been designed and implemented that include both enterprise and external relationship entities.

70

 

1, 3, 4, 5, 6, 9




2, 8, 10, 11