OSIMM may be used to support an SOA assessment of a single project or for an entire line of business, the entire enterprise, a service eco-system, or industry. The purpose of the OSIMM assessment method is to assess the current maturity and determine the target maturity level (goal state) necessary to meet stated business objectives.
Extending the OSIMM model to assess maturity against additional maturity indicators such as SOA industry frameworks is expected and encouraged. The OSIMM assessment method is iterative and evolutionary. As an organization adopts an SOA strategy, becomes more familiar with OSIMM assessments, and accumulates experience implementing SOA systems, it may add its own maturity indicators to the model.
The value of OSIMM as an assessment tool is to provide SOA transformation and adoption guidance for the SOA governance process.
Analysis consists of the following three activities:
These activities are performed in an OSIMM analysis, which has the following steps:
OSIMM Analysis Process depicts the OSIMM assessment process as outlined above.
OSIMM Analysis Process
Pain-points define where the organization considers that its processes need to be improved, and can be used to focus the subsequent OSIMM analysis. The assessor should gather material that can help determine the desired goal states of the SOA maturity levels. This material includes strategy documents, user requirements, and enterprise architecture artifacts. At this stage, an initial list of pain-points or strategic goals is determined. Once this is done the scope and structure of the SOA roadmap and transformation can be determined. The dimensions and domains in the OSIMM may be used to assist the definition of the scope.
On the basis of the agreed scope and objectives, an assessment matrix must be created, based upon the full OSIMM matrices, but tailored to focus on the key pain-points. The OSIMM model may be extended by adding additional maturity indicators. Additional maturity indicators can be used to focus on specific pain-points or strategic requirements for the adoption of services. This requires the assessment team to carefully map maturity attributes to any additional maturity indicators. Adding maturity indicators to the OSIMM base model should be conducted by experienced SOA practitioners.
The assessor uses the extended OSIMM model produced in the previous step to interview key staff in the organization in order to assess the current state of the organization and hence its current maturity level. The interviews should be based upon the base assessment questions provided within the OSIMM and assessment questions added as part of the extension, and can include additional questions considered relevant by the assessor that may help to map indicators to maturity attributes. On the basis of the answers to the assessment questions, the current maturity level and score value ranging on the 10-point scale of the weighted score is determined for each domain, and aggregated (summed) through the dimensions to the overall state of the organization.
The future desired state is determined using requirements documents, enterprise architecture artifacts, and interviews with the key staff. It is important to focus on those individuals who possess a good understanding and vision of the future requirements for business-based services and SOA infrastructure. The desired future state is determined by assessing the return-on-investment for higher-level SOA maturity within each OSIMM dimension against business requirements. Target domain scores are set and the organization maturity is calculated by summing the target domain scores.
The previous steps have identified the current and future maturity levels across all of the domains and dimensions in the assessment matrix created in the first step. The assessor should now determine the gaps between the current and future maturity levels, and create a roadmap that takes the organization from current to target. The maturity indicators for each domain must show the current and desired state, and the steps in the roadmap must be constructed in order to take the domains from current to desired, and to achieve business objectives or alleviate pain-points. The assessor should also consider constraints and prerequisites that will exist between the different IT and business entities that need to be put in place. It should be noted that the output of the OSIMM roadmap is intended to provide a relatively high-level statement of the activities that need to be undertaken, and that further, more detailed analysis can be undertaken, outside of the OSIMM analysis, of the precise nature of the activities.
The conclusions of the OSIMM assessment, including pain-points, assessment matrix, current maturity level, future maturity level, alleviation of pain-points, and roadmap, should be documented in a report to be used to guide the next stage of analysis and planning and provide input into future SOA roadmaps, SOA governance activities, and enterprise architecture spirals.
Periodically, the maturity should be reassessed. Current state domain scores and single scores can be compared to target maturity scores for an organization to show progress towards maturity goals. However, maturity scores are not meant to be compared between organizations since each organization is unique.