SustainableITArchitecture.com is a new working group open to end users, infrastructure software vendors and system integrators that need to devise an approach for the re-engineering of information systems. Pierre Bonnet is one of the co-founder of this working group which counts ILog and Orchestra Networks as their participants. Pierre is the co-author of the Praxeme, a comprehensive Open Source enterprise methodology that encompasses the construction of Service Oriented Architectures. He also co-founded the Praxeme Institute with Dominique Vauquier (methodologist at Axa Group insurance) and Philippe Desfray (Softeam, member of OMG board for UML standard). He is Consulting Manager at Orchestra Networks.
We talked to Pierre to share his understanding of Service Oriented Architecture as a veteran practitioner.
InfoQ: How do you see customers using SOA today?
Pierre: SOA is used in a very light capacity in the enterprise today. For the most part, projects are not changing existing assets. Architects are mostly focused on adding services on top of back-end systems. This is what people call generally Service Enablement. In the Sustainable IT Architecture maturity model we name this level “Cosmetic SOA” (see figure below).
A lot of people, including some vendors, claimed that SOA could create ROI without changing current systems. Of course, in the end, the ROI is not very high and was achieved at a cost of increased complexity and a loss in stability due to a larger number of layers.
InfoQ: How does this approach align with the current needs of the enterprise?
Pierre: In France and in Europe, in the next five years, the problem facing the enterprise is the renewal of information systems. A high number of software developers and architects are going to retire in the coming years. In this context, how can the enterprise keep the control of its information system?
The real debate around SOA is not service enablement or “Cosmetic SOA”, it is rather, how can we create a new generation of systems to replace the ones that we can no longer maintain? The current number of software layers brings too much complexity and a “Cosmetic SOA” approach is not going to be enough to streamline the evolution of aging and clunky assets. We survived the Y2K but we may not survive the retirement of the baby boomers. We are reaching a point of discontinuity in the industry. We have to transition to a higher level of SOA maturity, what we name “Re-engineering SOA”.
InfoQ: How do infrastructure software vendors support the concepts of SOA Solutions and the modernization of the information system?
Pierre: The licenses sold by Infrastructure Software Vendors is decreasing because projects are not ambitious enough. Some organizations are deploying their Service Oriented Infrastructure just to be able to cross a check box and tell financial analysts that “we are done implementing our Service Oriented Architecture”. As a result, vendors are focused today on marketing technologies that do not introduce to many changes in the information system, this is "middleware as usual". In my opinion, there is a sense that the requirements are changing but they do not have yet a coherent strategy to respond to them.
InfoQ: How can an organization move forward in this context and address these challenges?
Pierre: The business is ready, it needs to bring the information system to the next level. Their balance sheets recovered from Y2K and the dot.com bust, but today the business is demanding results, it is not under the same type of pressure as in the late 90s. Companies can no longer afford to throw money at their IT department without significant value being created.
To create value, there are three conditions:
1) We have to create a new kind of information system: we have to build the agility chain (ACMS : Agility Chain Management System). We have to become agile, that's not new, but we have to do it concretely, not just in PowerPoint presentations. The strategy is three-fold: processes, rules and master & reference data management. Today, the association of these concepts in a production environment remains revolutionary. The weakest link in the chain will define the agility of the overall chain. For instance Business Rule Management Systems require access to reference data. But today, reference data is so scattered across the information system that it is still very hard to get at it (more information about ACMS can be found on SustainableITArchitecture.com). The articulation between SOA and ACMS provides us with a more flexible service architecture, what we call, in the SOA maturity model (see figure above) “Extended SOA”.
2) We have to clarify what we mean by SOA governance. In France, customers are adopting packaged solutions based on a registry and repository to manage governance. But the solutions do not distinguish between ”Cosmetic SOA” and “Re-engineering SOA”. In the context of ”Cosmetic SOA”, there is little to govern, service capabilities and to a certain extend their contracts, are imposed by the back-end systems since their implementations rely completely on existing assets. In the context of “Re-engineering SOA” everything takes a new dimension. What is important is to model the new information system properly and efficiently to keep and adjust constantly its blueprint. If you look at Registry and Repository Solutions today, nobody speaks about the connection with domain specific languages and tools such as UML Case and IDE. Metadata can be expressed in UML models but this metadata cannot make its way to the repository easily.
3) We have to develop a public and common enterprise methodology that encompasses “Re-engineering SOA” and based on the principles of Agility Chain Management System. “Re-engineering SOA” can only be successful if based on an enterprise class construction process. This process is not covered by ITIL or TOGAF for instance. We need concrete guidelines to design and manage business data, uses cases, processes, logical architecture (with SOA style), etc. This public methodology must be embraced and supported by infrastructure vendors. Often we get the impression that vendors do not want to come too fast to the point where their customers can build “Re-engineering SOA”. This is why we have created a consortium of end users to develop a public methodology. This is the Praxeme Institute. Praxeme is provided with a Common Creative license. People can use it freely and modify it to suit their needs. Our goal at Praxeme is to establish a public, open source, foundation for the enterprise methodology that encompasses “Re-engineering SOA” and based on ACMS.
InfoQ: Could you give us some more details about Praxeme?
Pierre: Praxeme has been developed over the last 4 years and has been exercised on large SOA Solution projects in France. We have already a lot of practical feedback on what works and what does not work as well. Objecteering is implementing Praxeme as part of their tool suite. Unilog which is a major System Integrator is using Praxeme as their core methodology. They already have ten references of customers having used Praxeme successfully. We are now working on codifying the methodology into the Eclipse Process Framework Composite (EPF). We have also started a 5 day training for both IT and the business. I would like to emphasize that all our documents are accessible without restriction. However, some documents have to be requested. This is a significant intellectual capital.
Praxeme relies on a strong “Enterprise System Information Topology” that acts as an Enterprise Application Framework (see figure below). The eight aspects of this framework streamline business and IT tasks require for managing the risks of redevelopment systems information. For each aspect, Praxeme provides us with detailed guidelines that are not available in other EAF such as TOGAF Open Group. In particular, Praxeme defines a way to design “business objects” (semantic aspect) that are reusable in various organizational processes (pragmatic aspect): it is the famous separation of concerns but, this time, we practice it in the early stages of the design. With the Praxeme topology, the SOA architecture style is integrated inside the logical aspect. All the models are driven by the MDA Standard (Model Driven Architecture by OMG), with a set of derivation rules, for instance to transform a semantic model to a logical architecture in SOA style.
InfoQ: Thank you !
