Shedding some light on the work undertaken by Praxeme

Enterprise methodology

From the outset, Praxeme wanted to be an enterprise methodology, that is to say an answer to the patent need encountered by enterprises and felt by their management teams: to link areas of expertise, fostering synergy between them. Consequence: the expression “Enterprise Architecture” (EA) was taken literally, to designate a discipline that thinks the enterprise as a whole, in all its dimensions. As a result, Praxeme separates itself from the methods proposed under the EA label and which are all in the IT sphere. Zachman, with his Quintilian questionnaire and matrix approach could have covered the enterprise, but his way of answering (What = Data) meant he missed his target. We cannot blame him: historical and cultural determinations could not, at the time, have produced any other result.

Regarding enterprise architecture

Praxeme is therefore not an architecture method, albeit an enterprise one. If we say “enterprise methodology” or “enterprise transformation methodology” it is to assert the ambition of creating the melting pot into which all enterprise approaches will converge and melt themselves into a new alloy. It is a question, firstly, of identifying the multiple rationalities that extend across the enterprise and bringing them to recognize each other and coexist better. To do that, there is a need to adopt a meta-rationality position (not a hyper-rationality one; the meta-rationality position being fully aware of the limited rationality has thus a hint of modesty). Of course, an enterprise methodology makes room for itself in enterprise architecture, a key discipline in the enterprise transformation (for the same reasons as strategic design, organization and many other disciplines).

Both these points, together, mean that we have to rethink the foundations and even to look for another site to build the new edifice. Certainly, IT tradition plays a not inconsiderable role in this prospect, not only due to our individual trajectories (that would be a little mean) but, especially by the very nature of IT, the necessary go-between the real and the ideal. (I will not go into more details; I will merely refer you to the major work by Pierre Lévy La machine univers in French).

This is how it became apparent that we needed to identify the rules for building the reference framework, the analytical framework to be applied to the enterprise. From there came the new version of the Enterprise System Topology (EST). One figure to judge our research: in version 1 of the EST there were 8 aspects, 4 of which were linked to IT; there are only 7 aspects in version 2 and IT is a component of two of the aspects. The document PxPRD-01, included in the version 2 catalog, will present these rules and the result of their application. This topic was presented in the exceptional training session “Business Architecture & Transformation”.

Coming together of IT management frameworks

Better integration of EA with IT management frameworks like ITIL or COBIT is obviously a step in the right direction, especially as these frameworks have a tendency themselves to broaden their domain and raise their aspirations. But why limit ourselves to IT practices? Is it not also important, to make a success of one’s enterprise architecture, to couple it together with process design, thus to the organization, or with ethics modeling and strategy as a discipline? These domains are also based on frameworks or, at least, on an abundance of literature and a rich tradition. We will have to succeed in making the connection, unless we want to remain confined to the IT field and drastically reduce our ability to innovate.

Regarding agility

Regarding agility, we are faced with a contradiction. It is especially the contradiction of essence between the project mode (local scope and short term) and the system scope (long-term and globalizing vision of the architecture). The necessity to reconcile enterprise stability with agility leads us to reflect on the relationship between:

  •          the agility of transformation activities, on the one hand,
  •          and the quality of the architecture, on the other.

Praxeme’s proposal to resolve the equation consists in reorganizing the transformation activities, including those of architecture and project, around the enterprise description repository. This common pot is, certainly, not easy to build and a subtle and resolute governance is required. But, when it exists, it is the way of winning on both counts: to preserve the power and the ambition of the architectural vision, on the one hand, and to accelerate the projects by guiding them towards the common interest, on the other hand. Here we touch the complexity of the enterprise, complexity that is due, for the most part, to its mixed substance. It is precisely the role of the method to analyze the nature of this material, to separate its elements in order to create working conditions. The propaganda on agile projects, alone, cannot suffice; the Platonism of the ideal architecture (top down…), alone, leads nowhere. We have to combine the two.

In summary

“Reshaping enterprise architecture”: it is what, I think, we have more or less done. It is the almost involuntary consequence of our holistic approach to the enterprise: wanting to embrace all the enterprise reality and arrange all the information and decisions that concern it, we encountered, on our way, the disciplines and gave them responsibilities in the far greater prospect of the transformation.

“Assemble practices”: Praxeme has always presented itself as an interdisciplinary approach, a framework for coordinating the different practices and a vector for brining scientific contributions and putting them at the disposal of the enterprise.

On agility: the major topic is not project agility. At the beginning of the 1980s, James Martin had already said the basic essentials with his RAD method, all too quickly interpreted as authorizing models to be thrown overboard. One day, an economist really must quantify the economic disaster that followed on from this. The major topic is enterprise agility, which rightly calls for a huge architecture effort and a rigorous approach.