Hector Fabio Meza

Hector Fabio Meza

Biography

Hector Fabio Meza is a Software Architect at Dacartec, a Spanish-Colombian company dedicated to the development of integration and collaboration software solutions based on IBM technology. He has been working in the software field for 12 years, developing projects for insurance, health and financial companies.

Hector is a Sun certified java programmer and Web Component Developer.

Contributions

rss  subscribe to this author

Paul Escobar Mossos

Paul Escobar Mossos

Biography

Paul Escobar is a technology architect at Colsanitas, leading health company at Colombia. Electronic Engineering and Telecommunications and Software Engineering specialist with 13 years experience in the software industry. Throughout his professional life has participated in R&D, telemedicine, health and telecommunications IT projects for organizations like Colciencias, Telecom, ETB, Gilat Perú and Colsanitas. Interested in free software world as economic and reliable alternative in countries with emerging economies. Paul is a SOA Certified Architect and SOA Certified Trainer.

Contributions

rss  subscribe to this author

Bookmarks



An SOA Maturity Ecosystem Published: June 11, 2014 • Service Technology Magazine Issue LXXXIV PDF

Abstract: Incorporating SOA in an organization is basically a migration initiative, and as such it should have an associated transition process inside it. An important part of this process is the establishment and periodic evaluation of a SOA maturity roadmap. There are several models created to perform this task, most of them tied to a specific vendor, which reduces the possibilities to openly use them. The Open Group has a model which, additionally, is an industry standard, and besides, it's not only a maturity model but a framework, which is to say it lays a foundation which can be extended and personalized, plus it has an associated method. This landscape has two consequences, first, it leaves organizations, independent consultants, open source vendors, etc, orphaned of a tool that will automate their maturity assessments and second, it leaves them lacking a wide and tested set of maturity indicators to assess according to previous experiences or vertical markets.

With the goal of giving organizations, independent consultants, open source vendors and other actors interested in measuring the evolution of SOA migrations what they need to be agile, effective, systematic, rigorous and to rely on their environment experiences, improving SOA implantations in organizations, it's necessary to have additional elements to a maturity model which will complement, potentiate and lever the way we evaluate and define roadmaps for SOA initiatives, filling the void of systematization of assessments and lack of collaboration based in the experiences of different sectors.

This article will describe the way to cover these shortages, detailing a maturity ecosystem for SOA, comprised by 3 main elements that give each other feedback:

  • Maturity framework. Based on the Open Group's OSIMM, which is an ISO standard and can be used by any vertical market
  • Automation Tool. Open source tool that implements the flexibility of the OSIMM framework so organizations and consultants can perform measuring and evolutions in a systematic way. It has its own community that permits its maintenance and evolution.
  • Community. People interested in sharing and re-using experiences around the subject of SOA maturity. The community materializes itself around an Internet portal where indicators, attributes and questions can be shared directly from the software tool with all members so they can be re-used by others, avoiding effort duplication and propelling this kind of practice in organizations.

It will show how these three elements give each other feedback and produce niches with its own feedback and growth dynamic. Finally it closes with the future work expectations to keep nurturing this ecosystem

Introduction

Incorporation of Service Oriented Architecture (SOA) in an organization is a transition or migration process, as it essentially changes the way we do things in both technology and business logic. Technological change focus on different key areas: infrastructure (administration and monitoring, security), methodologies, design, organizational structure and culture.

A migration should be carefully planned. The essence of good planning begins with determining what is the current status of the organization, moving on to decide where it wants to be. Finally, to reach the desired goals, it must be decided how to get there. These steps are fundamental in an adoption plan. Certainly, this is a general concept, which in practice requires a greater level of detail and application of other components [REF-1]:

  • Scope of planned service inventory and the ultimate target state
  • Milestones representing intermediate target states
  • Timeline for the completion of milestones
  • Available budget and suitable funding model
  • Governance system
  • Management system
  • Methodology
  • Risk assessment

These components enable the organization to define an adoption plan, a roadmap that allows it to define precisely the steps and stages to follow in order to achieve the desired goal. This roadmap, of course, can take longer or shorter depending on the current situation of the company.

Maturity in the SOA adoption plan is established by means of states or levels for different aspects, and periodic evaluations to measure how the organization is evolving through them. Therefore, a maturity model offers support to a governance system that allows increased rate of success in SOA transitions.

What is a maturity model?

A maturity model is an optimization mechanism that sets an evolution path in a practice, evaluating different aspects or views. It allows establishing a level for that practice and a roadmap for evolving on it. Specifically on SOA, these models not only measure technological issues related with IT systems, but also aspects that reflect the impact in organizations addressing an SOA initiative. They show the implications (structural, governmental, etc.) to be considered when trying to embark with such an initiative. Not every organization must necessarily achieve the highest level of maturity. According to their specific needs, it is perfectly acceptable for an organization to stay at one of the intermediate levels.

Thus, a maturity model provides the ability to support the planning and government in an evolutionary adoption of SOA within an organization. Furthermore, a maturity model is a guideline to SOA adoption, hence its importance within organizations, considering that: [REF-2]:

  1. Allows establishing where is the organization at the starting point of the initiative (this is one of the activities of adoption plan)
  2. Allows establishing what is the target state or objective that the organization wants to reach (another activity of adoption plan)
  3. Sets intermediate levels that should be transited in the path between initial and target states
  4. Finally, enables actions and projects to be executed, allowing the transition from one level to another

The following are some examples of maturity models found today in the industry:

Common models

Oracle model

Oracle's model evaluates a very specific set of facets. On the technological side they include Architecture, Infrastructure, Information and Operations-Administration-Management. From the organizational point of view, it evaluates Business-strategy, Organization, Governance and Projects-Portfolios-Services [REF-2].

img

Figure 1

Each one of the facets evaluated scores a set of maturity levels: No SOA, Ad Hoc, Opportunistic, Systematic, Managed, and Optimized. For Oracle the scope of adopting an SOA initiative (the extent of SOA within the company) is also important and measured. It is in fact used as a formula parameter to infer the target level at which the organization should aim. The model defines the following target levels: No Implementation, Project Level, Program Level, Division Wide, Cross Division, and Enterprise Level.

Microsoft model

Microsoft's model evaluates three facets, also called Perspectives: Service Administration, Service Consumption (adopted and promoted use of services) and Service Implementation [REF-3].

img

Figure 2

The amount of maturity levels decreases compared to Oracle, since are only four in this model: Basic, Standardized, Advanced and Dynamic. Finally within each perspective and level there are capabilities that must be provided (36 in total).

Open Group model (OSIMM)

Built by a neutral agency for providers and technology, focused on the strengthening of open standards and interoperability within and between companies, the Open Group model (OSIMM) is a framework rather than a static model, i.e. it can be extended. It has an associated methodology for conducting assessments and supporting the development of a roadmap [REF-4].

img

Figure 3

Facets evaluated in this model are called dimensions and are seven: Business, Organization and Governance, Methods, Application, Architecture, Information, Infrastructure and Management. Moreover for each of these dimensions are also levels that are seven: Silo, Integrated, Componentized, Services, Composite Services, Virtualized Services and Dynamically Reconfigurable Services. Within each dimension and level, maturity indicators handling attributes for each level are evaluated.

Problems in the models

Most of the models found in industry are developed by providers and in some cases are used for promoting their products. Also, due to its commercial nature, they tend to force organizations into reaching the highest level, something that is not necessarily the most appropriate approach for all companies, so its use can lead to selecting a wrong target level.

Access to these maturity models is not necessarily free. Some of them offer free online assessment tools, but they are usually not full featured versions. The proprietary part of the evaluations (full featured and robust) is associated with the purchasing of products. As for the dynamism of proprietary models, it can be said that none of them is open to expansion, and there is no a way to enrich evaluations with proven indicators and / or according to vertical markets.

Who does this situation affect? Directly affects consultants, organizations (self-evaluations) and open source providers, making them difficult to be agile, effective, systematic and rigorous, to rely in experiences of environment or improve the implementation of SOA within organizations.

This creates two important gaps in this aspect of SOA adoption:

  1. Lack of assessment systematization (automation). Some providers like Oracle and IBM, for example, provide tools to assess maturity, which can be accessed online but are not complete versions, they are designed for a potential client to make a quick self-assessment and provide their contact details. However, IBM has a complete tool but can only be used by customers.
  2. Lack of collaboration based on experiences from different sectors. There is not a common and public bank of aspects to be measured based on customer or general industry experiences, with which to refine the adoption of SOA in organizations. There are even aspects to be measured according to the vertical market (healthcare, government, and banking) but the models do not take them into account or they are not publicly available.

Maturity Ecosystem

Why is this happening? Because the maturity model alone is not enough. Additional elements must be created in order to complement, enhance and leverage the way evaluations are made, and the SOA roadmap of initiatives are defined, forming an ecosystem.

But, what is an ecosystem? The term has its origin in the biological sciences, so the following three definitions provide a starting point for analyzing its application to a technological environment.

According to the University of British Columbia Botanical Garden, "An ecosystem is a community of plants, animals and smaller organisms that live, feed, reproduce and interact in the same area or environment".

Wikipedia defines it as "An ecosystem is a community of living organisms (plants, animals and microbes) in conjunction with the nonliving components of their environment (things like air, water and mineral soil), interacting as a system. These biotic and abiotic components are regarded as linked together through nutrient cycles and energy flows".

The Smithsonian Institute defines it as "Ecosystems are defined as communities of plants, animals and microorganisms found within a particular area, interacting with each other and with the environment. Hence, the term "ecosystem" encompasses both the biotic and abiotic (living and non-living) components of a particular environment. Ecosystems are complex and dynamic entities that use energy, produce wastes and recycle nutrients".

What do these definitions have in common? Components (living and non-living), i.e. entities that have independence but are in community, they have interaction, there are bonds; there is conjunction between them and the environment, i.e. a particular area. Finally all they form one system. In an ecosystem, each organism has its own niche or plays a specific role.

Maturity Ecosystem Elements

So, what is the goal of having a SOA ecosystem maturity? Similar to what happens in nature the goal is to have a number of components that interact among each other to strengthen the adoption of SOA in organizations, eliminating the above mentioned gaps.

The components of this ecosystem are described below:

  • Maturity Model: OSIMM, chosen because it is an industry standard (ISO / IEC 16680:2012), which is in the process of becoming in national standard in China and Korea. At the same time it is a framework (that is extensible) and a process. In other words, it was chosen due to its completeness, possibility of being enhanced and it does not depend on a specific provider.
  • Automation Tool: Open source app inspired by OSIMM framework flexibility, so systematical measurements and evolutions in organizations or by consultants can be made. It has its own community that supports its maintenance and evolution.
  • Community: People interested in sharing and reusing experiences around the topic of SOA maturity. The community is materialized around a web portal where indicators, attributes and questions can be shared directly from the computer tools with other members, so they can be re-used by anyone, avoiding effort duplicity, and promoting such practices within organizations.

The energy source of this maturity ecosystem (as opposed to biological ecosystems where the source is the sun) is the need for organizations to make SOA adoption. Figure 4 shows how these three elements interact (it must be kept in mind that interaction is another ecosystem key concept).

img

Figure 4

The model motivates the existence of a technological tool that automates it. Software provides a mechanism for sharing and reusing indicators, questions and experiences thus strengthening the community. Community experience promotes use of the model and springs up suggestions to enhance the OSIMM framework.

These relationships are analog to the flow of energy and nutrients between biological ecosystems. It was previously mentioned that each of the components of an ecosystem has a niche or role within the system. Continuing with the analogy between the biological and technological spheres, each one of the niches of maturity ecosystem components will be detailed next, knowing its internal feedback and growth dynamics.

OSIMM Framework

Model

The effort of this framework starts with the IBM SIMM model as a base and with the participation of several other companies with great experience in topics around SOA, such as: Capgemini, HP, EDS, Deloitte, and Marriott, among others. In 2009 version 1 is converted into an Open Group Standard, later in October 2011, version 2 is created, basically some adjustments were made in order to postulate it to the ISO (clarifications to questions are made).

In January 2012, ISO confirms it as standard, becoming the first international SOA standard. It should be mentioned that is not the only effort the Open Group makes around this issue, other important standardization works carried out by the group are: a framework standard of SOA governance, a SOA standard reference architecture and an ontology for SOA.

The model consists of a series of levels that indicate the maturity of an organization to perform service orientation (Silo, Integrated, Componentized, Services, Composite Services, Virtualized Services, and Dynamically Reconfigurable Services). But evaluation is not monolithic, it is divided into dimensions, this means aspects or views more or less independent and well-defined, submitted to evaluation (Business, Organization and Governance, Methods, Application, Architecture, Information, Infrastructure and Management). Within each dimension, there are maturity indicators which are characteristics present in the business or in IT, which are able to be measured by means of a questionnaire and have some attributes according to the level of maturity. Figure 5 allows a graphic visualization of the mentioned concept hierarchy.

img

Figure 5

As mentioned above, there is a questionnaire or evaluation questions that allows the assessment of maturity indicators, these questions are used for surveying an organization (project, business line, company, consortium and vertical industry) in order to classify the maturity attributes it has and know the level of a given indicator. It should be noted that the questions, as defined in OSIMM, are open, i.e. they not only answerable with "yes" or "no" or a multiple choice. Each attribute is mapped to a set of questions of the maturity indicator.

The first 3 levels are known as Service Foundation Levels and can be viewed as prerequisites to enable legacy environments.

Among the roles and work teams proposed within an organization to perform the assessments are: IT Operations Team, Service Development and Deployment Group, Line of Business staff supporting a service or business area, Enterprise Architect and CIO Organization.

Extension Points

The exposed base model can be extended by adding maturity indicators, attributes (within each dimension), evaluation questions, and corresponding mappings to attributes. All this in order to include, for example, specialized or specific attributes for an industry or company. It must stated that levels and dimensions are not to be modified within this framework.

It can be seen from the framework how it is possible to find support for an experience exchange community, a major reason for choosing it as a part of the ecosystem. This is how particular industries such as retail, healthcare and the financial sector can have specialized sets of indicators and evaluations that help bring more adjusted and finer SOA adoptions, reducing risks and time, and therefore being more cost/effective.

When adding these attributes, it is possible to give them weights within each dimension to match the expectations and requirements of a sector or organization.

Methodology

The model such as conceived by the Open Group can be applied to either a project, a line of business, a company or a vertical industry.

The methodology associated with the framework has a number of steps whose general purpose is described below:

  1. Identify relevant business objectives. This refers to identify the pain-points where the organization believes its processes need to be improved, or the goals in order to improve its business capabilities.
  2. Extending the model. Create new maturity indicators focused on eliminating the pain-points or business requirements that can be supplied with SOA adoption
  3. Evaluate the current status. The current organization status in SOA is compared against maturity indicators, mapping them with the corresponding attributes and determining the level for each of them
  4. Determine target levels. Indicate the maturity levels the organization wants to reach according to pain-points and its internal capacity.
  5. Identify gaps and determine the roadmap. Based on current maturity and desired status for each attribute in each dimension, actions to cover the gap are established, thus progressively establishing a complete roadmap. Restrictions and prerequisites should be taken into account for the different areas, IT and business teams.

Automation Tool

Concept and Objective

In order to automate maturity assessments and implement the second of the components of the maturity ecosystem, an automation tool that is aligned with the concept of OSIMM framework has been defined. It can be used by consultants or directly by the organizations to systematize the maturity evaluation, in a way that use a centralized information repository, with access being possible from anywhere, without the need to use tools such as spreadsheets.

Functionality

The tool has two main modules: Extension Points (Management framework) and Management / Enforcement of assessments.

  1. Extension Points. Although the app comes with OSIMM standard indicators it is possible to add new indicators and combine them into new assessments. For each indicator, basic data, maturity attributes by level and questions are defined. These indicators should be associated with a dimension. New types of assessments can be created grouping the desired indicators. The system comes with a default evaluation called "OSIMM Standard Evaluation" with attributes defined by the framework.
  2. Administration / Enforcement of assessments. It is possible to create new assessment elements which may be: Project, line of business, company or vertical industry ecosystem, which corresponds to the same scope that can be evaluated by OSIMM. For each one of the assessment elements the following can be scored: Pain-points, business objectives and new capacities (capacities are for new desired services and / or products to be offered). Within each evaluated element, for example, a company can create evaluations of a particular type. Once an assessment is created, it is no longer possible to change its type for next evaluations, unless it is deleted. Once inside a given assessment, with a defined name and description, questions are answered and qualify the maturity level for each of the dimensions and maturity indicators. To assess the target maturity, the same procedure is performed, with the difference that it is marked as an target.

    There is a graphics area, displaying the current evaluation status and the target status as a spider chart. At the top, the list of indicators for each of the assessments made and its values are shown. At the bottom, a spider chart with each evaluation is shown in a different color (FIGURE 6).
img

Figure 6

The tool is presented in two languages: English and Spanish, both for the application and the pre-filled information (indicators, attributes, questions and types of assessment). Lists of questions and their answers can be exported to PDF or Excel files, to create reports with the purpose of sharing results.

The application is called Darwin. It was named in this way in honor of Charles Darwin and the close association of his name with the evolutionary theory. Thus it intends to represent the path of SOA maturity as a business evolution close to this paradigm.

Darwin has been released under GPL license and has been set as a project on Sourceforge [REF-5]. It is implemented within the OpenXava framework, which is a Java framework for agile development of applications focused on development by domains. It enables the generation of portlets, allowing it to be the technological basis of the community, which is the third component of the SOA maturity ecosystem proposed [REF-6].

Community

The idea around of the community is to strengthen the efforts of the various groups performing maturity assessments and in general SOA roadmaps within organizations, so efforts are not duplicated and knowledge can be reused in different industries.

For the community to have an effective way for communicating and sharing experiences, a web portal is proposed, where maturity indicators and questions from the same application can be shared, and from where these experiences can be downloaded to be used directly from Darwin. Figure 7 shows this dynamic.

img

Figure 7

Currently the site has not been implemented and its construction and connection to Darwin is under study. This is part of the future work that is displayed below.

Conclusions and Future Work

The theme of the SOA maturity is a key point when tackling an initiative of this type within organizations, but to have or adopt a certain model is not enough. Evaluation automation and systematic experience sharing of the entire community associated with SOA must also be part of the evolution of a company, in order to bring this task to a truly engineering level, apart from an handmade approach.

Currently the initiative outlined in this article is in development state. The Darwin tool already exists in Beta version as a project at Sourceforge where it can be downloaded and tested in a demo page, however the community does not exist yet. The work to come is interesting, and includes but is not limited to, seeking sponsorship to strengthen the project, enhancing Darwin and creating the community.

The first step is to look for sponsorship sources in the field, starting with organizations in Colombia that sponsor innovation and development, such as Colciencias, INNpulsa, Industrial Technological Innovation Colombian Center (CITIC), etc.

For the Darwin tool, the following roadmap have been projected:

  • Adding questions-attributes relation.
  • Adding weight management when a dimension has multiple attributes
  • Internationalization for other languages
  • Adding share / import functionality
  • Broadening the scope to a SOA government tool

As for the community there is still lot to do, but the priority is given to:

  • Establishing a web portal, with support of the portlets generated by the technology used by Darwin, where indicators, attributes and questions are displayed, and can be downloaded for its use.
  • Adding forums to stimulate debate on the field
  • Adding related news to attract consultants and manufacturers

Individuals and organizations wishing to join and/or support this effort are always welcome.

[REF-1] T. Erl: "SOA Governance. Governing Shared Services On-Premise and in the Cloud", Prentice Hall Service-Oriented Computing Series. p. 82

[REF-2] T. Erl: "SOA Governance. Governing Shared Services On-Premise and in the Cloud", Prentice Hall Service-Oriented Computing Series. p. 56

[REF-2] Oracle: SOA Maturity Model - Guiding and Accelerating SOA Success. http://www.oracle.com/technetwork/topics/entarch/oracle-wp-soa-maturity-model-176717.pdf

[REF-3] Microsoft.

[REF-4] The Open Group: OSIMM Version 2 Technical Standard. http://www.opengroup.org/soa/source-book/osimmv2/model.htm

[REF-5] P. Escobar: Darwin 1.0.0b. http://sourceforge.net/projects/soavolution/

[REF-6] OpenXava: Java Web Application Framework. http://www.openxava.org/web/guest/home