BT

Sustainable IT Achitecture Working Group Formed

| by Jean-Jacques Dubray Follow 3 Followers on Oct 09, 2007. Estimated reading time: 6 minutes |

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 !

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Is it a joke ? by Reg Sciavo

We aren't on April Fool, J-J !
I had a deep look to Praxeme docs (yes I read some french) and found them very marketing oriented and confusing. How can this be even compared to ToGAF, EAF, or SOMA !
I'm surprised to read Unilog has ten references with this crap... isn't it overestimated ?
open source methodology does not mean quality, for sure. Where is the ROI for the SOA consultant who gave just before every bit of his experience in the public domain ?

Re: Is it a joke ? by Jean-Jacques Dubray

Reg:

I am not sure we might be looking at the same documents, I did get additional presentations after requesting them. As far as I am concerned there is original and valuable content in Praxeme.

It is also important to realize that Praxeme is an enterprise methodology which is broader in scope compared to a SOA methodology.

I have not looked at SOMA directly since it is proprietary but I spoke with one of the co-author of this redbook: www.redbooks.ibm.com/abstracts/sg247356.html?Open and will publish his interview shortly.

There is also the CBDI forum which has published some materials in this area.

As you mentioned there is TOGAF, which started a SOA initiative a couple of years ago.

There is also SAP which has published a lot of content focused on methodology and EA as part of their ESOA initiative.

The way I see Praxeme is that they leverage modeling and UML quite a bit and they are less focused on "processes" (but they are there, I have seen them). For instance, they make a heavy use of State Machines. Again, I cannot compare it with SOMA. Based on the content of the redbook, I can see that SOMA has its foundation in RUP and is also using modeling extensively.

I would argue that many organizations are facing the challenge of developing a "home grown" SOA methodology, and this is quite a challenge.

I would definitely consider looking at all content available before designing one for my organization.

It is also important to note that there seem to be a consensus towards using EPF to manage methodologies. An EPF file would have been helpful to make an accurate assessement of the scope and capabilities developed in Praxeme. It is coming.

Re: Is it a joke ? by Pierre Bonnet

Response by Pierre Bonnet, co-author of Praxeme

Reg,

Praxeme is managed by three co-authors, included Philippe Desfray that is also co-author at OMG for UML (search “Philippe Desfray OMG” with Google!).
Praxeme doesn’t compete against TOGAF. But we know that TOGAF doesn’t define the detailed guidelines to deliver the business modeling (semantic and pragmatic aspects) and the SOA logical architecture. The vocabulary of logical components and services (coarse grained, meduim grained, fine grained) is not standardized by TOGAF. Other approaches such as Peter Herzum have tried to standardize the concepts of logical architecture (Business Factory…) but are now deprecated due to SOA momentum and also because they have not integrated business modeling. You also may quote Herzum Framework with its matrix of 30 models: too complex to be achieved in concrete projects.

So, in this context, we need a strong enterprise method that embraces business modeling, logical architecture with SOA and software implementation. This method is complementary with best practices such as TOGAF but also other guidelines such as ITIL, COBIT, and CMMI. This enterprise method has to provide us with modern guidelines to design, with UML notation and MDA, large-scale information systems. The SOMA proposal of IBM is a proof of the enterprise method need. But SOMA is a private method and you must pay to use it; Praxeme is a public (open source) method and is free of charge. Furthermore, Praxeme defines a very strong Enterprise Information System Topology with its eight aspects. Each aspect is defined by detailed guidelines that rely on UML notation and MDA (derivation between the aspects of the Topology):
Semantic aspect (business objects, master data, and life-cycle of business objects, business rules, regulatory), treats business core modeling whereas Pragmatic aspect deals with organizational modeling (uses cases, processes, organizational rules, right definition): it is the separation of concerns at the design level. These two aspects are enterprise business oriented; they do not integrate architecture such as SOA. Logical aspect integrates SOA style and delivers a strong logical architecture through components and services that are directly derived by semantic and pragmatic models, according to MDA (Model Driven Architecture) approach. The Software aspect inherits from logical models and adds a technical profile to target the IT infrastructure, in particular programming languages (Java, C#, COBOL…). The components may be executed through a Virtual Engine for Praxeme (VEP) that is defined by a complete open source specification.

Finally, on the top of the method Praxeme, we add two other concepts: SOA maturity matrix (Cosmetic SOA, re-engineering SOA, and Extended SOA) and ACMS (Agility Chain Management System).

To leverage the quality of information system and to foster large-scale re-engineering projects, we need to define and use a strong enterprise method. This method is enriched by an open community that shares vocabulary and UML guidelines: don’t forget: UML is a notation not a method.

If you believe this point of view, do not hesitate to join us at www.sustainableitarchitecture.com.
To join me directly: pierre.bonnet@orchestranetworks.com
Best regards.
Pierre Bonnet
Co-founder of Orchestra Networks, co-author of Praxeme, manager of Sustainable IT Architecture community.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT