SOA maturity Matrix, Agile Chain Management System

Today I would like to present a very nice article in a IT french journal “Solutions logiciels”. This is related to sustainable architecture. I’m working with Pierre Bonnet, the author of this article, on this matter, and try to share experiences on BRMS, as one of the corner stones of the Agility Chain Management System, I will try to summarize the main points of this article in french as it is relevant over the world:

The IT infrastructure in a lot of companies suffers from a lack of investment to modernize the legacy, which adds complexity when development team deploys new applications. Business and IT managers are focusing in short term ROI putting on hold long term investments needed to build a long term sustainable architecture.

Added to these, we can foreseen three layers of IT staff: the senior with their knowledge of the current legacy systems and the business requirements, the intermediate layer with people skilled in client/server and EAI technologies, and the younger one with object oriented skill, and web, web services development backgrounds. Younger are involved in tactical projects, using agile methodology, but most of the time generate rigid systems not able to change and supporting a long term logical architecture. The seniors are starting to retreat leaving a deep gap in knowledge which is most of the time not transferred to younger population. These are future bombs in the IT organization. What to do?

IT management needs to start long term projects to rebuild the IT architecture for the next generation. Pierre proposes to start by looking at what is the current situation at the enterprise level and being able to build a plan to transform the IT architecture for long term needs. The second point is to take risk: we can manage an IT organization just by controlling the existing. The rapid changes in economy, new regulations, and technology progresses force managers to take risky choices. But the risk is also to look at change in IT staff population, skill transfer, and risk to deploy new application on a fragile architecture.

Finally his last point is about clearly communicating to business and executive management about the non quality contract of current IT system, the medium to long term degradation of the IT services, and so the company competitive advantage. The communication has to leverage a strong action plan leveraging a risk management plan.

Three principles support the argumentation:

1- The re-engineering of any IT architecture cannot being done in one shot. The diagram below presents a progressing path to migrate existing architecture to a sustainable one. Starting from a SOA to expose the existing legacy functions as services, then moving to the extended SOA where BPM, BRMS and MDM are used in conjunction to offer agility at the service level for change in referential data, decision logic, and business process. The end of the path references the use of those technologies for the enterprise architecture.

2- The Agility Chain Management System: Using the MDM, BRMS and BPM technologies, IT staff can start by externalize referential data and parameters using the MDM, business rules and decision logic using BRMS, and orchestrate services and support business process with BPM.

3- A Enterprise Level Methodology: the migration path enforces a strong use of methodology like TOGAF, Praxeme, CEISAR)

Pierre addresses in this article some very important points and principles to take care during a SOA migration. Currently we are seeing a lot of project focusing on re-vamping legacy function as web services but this is not the end of the story of a SOA. I like very much the path to the extended SOA and the maturity matrix as a tool to explain to IT management the long term vision. Project managers can position where their project stands on this matrix to clearly articulate what is the value of their project’s product for the long term IT vision.

I modified slightly the original maturity matrix to clearly mention that any project falling into the bottom-right corner is the beginning of decision service re-engineering using the MDM-BRMS-BPM technologies, that IT development team has to leverage for the long run. When people embrace those technologies they are seeing the value and how to leverage them at the enterprise level. As you can see green path is the way to go and the red path is going no-where as it falls back into a rigid application behind a web service...

As an example of this kind of project we can take a claim processing application where the development team and architect decided to migrate one of their service (Claim Coverage Verification) to use business rules to verify the coverage of the insured person around his claim. MDM was used to define all the referential data as the medical codes, the US states, zip code,.. and other application parameters. The legacy application offers some data and business services with a re-vamped web service approach, and the BPM was used to call the services, to dispatch the set of XML documents over the process steps, and to offer the GUI for the claim processors: the actors of the business.

Starting from there the team can enhance the migration of such application and design reusable, agile technical and business services.