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.
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.
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:
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
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]:
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]:
The following are some examples of maturity models found today in the industry:
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].
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's model evaluates three facets, also called Perspectives: Service Administration, Service Consumption (adopted and promoted use of services) and Service Implementation [REF-3].
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].
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:
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:
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).
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.
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.
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.
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.
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:
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.
The tool has two main modules: Extension Points (Management framework) and Management / Enforcement of assessments.
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].
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.
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:
As for the community there is still lot to do, but the priority is given to:
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-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