Archive for the 'foundation' Category

Enterprise methodology

Add a comment

Everybody agrees: an enterprise is a complex object, a woven web of factors, continuously forced to adapt to an ever-changing world. How can we consider this complexity? How can we paint the whole picture of the enterprise without the risk of omitting a key element? How can we find the right ideas to provide for the future?

It would be illusionary to believe that one unique formula, like a magic charm, would be enough to address this complex reality. We must involve many disciplines and articulate various centres of expertise. To create synergy, they must be integrated into an interdisciplinary frame, consistent and able to use all contributions. This requirement defines the enterprise methodology.

Praxeme is the enterprise methodology, born from an initiative for an open method. It is based on an analysis of the Enterprise System and its internal logic. It offers procedures that cover all aspects of the Enterprise, from ethics to infrastructure, from knowledge to logistics, through processes and organisation.

It is one thing to have methods for each aspect of the enterprise (methods for strategists, for organizers, for IT professionals, accountants…); it is another thing to link them together accurately, so as to obtain a harmonious transformation chain. Praxeme’s original concern is precisely this, to answer the need for coordination among the various specialities, all equally legitimate and necessary, but which have difficulty in communicating.

Executives are the first ones who perceive this need and even more strongly when their organisation is facing change. In front of the disparity of the proposals, decision makers look for a general frame to optimize the investment which even if focussed on one part of the transformation chain must be incorporated into a bigger plan rolled out to all dimensions of the enterprise. They will also look for means to stimulate innovation, not only by looking at their competitors or using the latest technologies but also by revitalising the business, by stepping back from the usual course of action, by rethinking it. Human psychology, conservative forces, actor strategies… everything conspires against this transformation.

It is absolutely necessary to have a method available that shows the events and that offers workarounds to go beyond them. Praxeme’s first approach consists in becoming aware of the complexity and recognising the cognitive universes that need to be linked together. Ethics, terminology, metrology, modelling, sociology, system architecture are some of the disciplines that allow us to come nearer to the enterprise reality. They produce representations that the method helps formalize and connect. For instance, the creation of processes results from ethical requirements, it has to comply with the values stated by the enterprise. The IT system results from business models according to rules of derivation, which ensure its alignment and agility.

Praxeme has been applied to all types of businesses, at variable scales. These experiences include IT system overhauling, innovation in weaponing systems, modelling of transport systems, practices, convergence between systems or businesses of an enterprises alliance, interoperability… The French Administration recommends the use of this method to manage its large modernisation programmes.

To meet its ambition, Praxeme is continuously under construction. The initiative is open in both ways: it welcomes donations and makes its results publically available, royalty-free. The first version is available through methodological guides that form the foundations. Work on Version 2 is underway and will complete the corpus by adding detailed procedures and methods (basic recipes) dedicated to the several roles involved in transformations.

The Praxeme Institute, a non-profit and state-approved association carries out the development of the method and watches over the spirit of openness.

Dominique Vauquier

For more information, please visit:

Content framework

Add a comment

“Content framework” is the expression used in TOGAF 9. It is simpler than “methodological framework” and I will adopt it, even though one can always argue what content it is about. For us, it is clearly the content we have to deal with through architecture, that is the content of the Enterprise System, so the enterprise itself.

A content framework identifies the big classes of objects we have to deal with. It comprises the selected categories of representation. Of course, a framework is not limited to its graphical expression. It is not enough to display a slide with a few boxes and in-the-hype labels. We have to thoroughly articulate the notions and link all types of elements together. One would deride this endeavor as a theoretical exercise and a waste of time. Certainly, it is theory, the sort of theory that prepares and guides action – the only way of preventing confusion and waste of resources on the scale of the enterprise. In the absence of such an endeavor, not only these resources are wasted, but also innovation or improvement opportunities are missed and the transformation disciplines are loosing their legitimacy and their power of imagination.

NB: Transformation disciplines include strategy, organization, architecture, design… on every aspect of the enterprise.

Rules that a content framework obeys

The rules below help to make clear the meaning of the framework and its implications. They also prepare the deployment of the framework in terms of methods and tools.

1. The framework embraces every aspect of the enterprise. To put it in other terms, it includes every type of information to be collected and decision to be made in order to transform the enterprise and its systems.
2. Every type of element has a single place inside the framework.
3. The framework puts these elements into order, so as to ease the transformation chain and to clarify roles and responsibilities.
4. The framework is not limited to a static view: it specifies the dependencies between its elements and explains how the elements relate to each other.
5. The framework is based upon a metamodel that contains the definitions and relations of the types of elements.


The content framework is about the system itself, as opposed to its development and management.

“System” designates the enterprise through all its aspects. Enterprise Architecture is about this Enterprise System. It encompasses every aspect, from strategy to deployment. Its added value plays precisely on the ability to link together the choices and decisions related to all aspects of this complex reality.

The comprehensive approach to the Enterprise System

Enterprise Architecture is the discipline that analyzes the strategy and determines the main decisions for transforming the Enterprise System. As such, it has to base its approach on a framework that is broad enough to encompass every aspect of the enterprise.


The starting point of the approach to the Enterprise System is the corporate strategy. Broadly speaking, the methodology must prepare us for collecting any considerations that answer the question “Why?”, including statements that cannot necessarily be formalized as models. This includes values, objectives and orientations of all sorts, business requirements, vocabulary… This material will be referred to each time a choice has to be justified.

Thus, Enterprise Architecture endeavour starts with a “political aspect”. The term “political” is understood in its original meaning of something related to the City or community.

Why do  we have to separate the core business knowledge from the business activity?

When it comes to describing the business of an enterprise, we first fall and spontaneously perceive activities. Processes, use cases (elementary working situations), business capabilities… are ways of identifying and documenting the business activities. We need these descriptions and they pertain to Business Architecture.

Nevertheless, as these descriptions result from the same “functionalist” culture, they entail limitations that may hinder our efforts toward convergence and agility:

  • Most of the time, a process description or a use case embed organizational assumption and work habits, making them difficult to be shared. Indeed, these organizational contents are likely to be local and unstable.
  • The breakdown structure of the business activity cannot avoid redundancy.

This is the reason why we need another representation of the business, not to replace the former ones but to complement them. This more abstract representation focuses on the core business knowledge, the semantics – regardless of the multifarious ways of enacting this knowledge.

This imposes a significant constraint on the methodological framework: it ought to distinguish a semantic aspect (the core business knowledge) and the pragmatic aspect (the business activity). This difference takes place inside the Business Architecture.

To complement the business representation

The semantic aspect is about the “What?” of the enterprise (what objects does it create or manipulate?). The pragmatic aspect is about “Who?” and “Who does what?” (the players, their actions…). We can also see the organization as an answer to the question “How does the enterprise deals with the objects?”. Another question that may have significant implications is “Where?”. In order to provide a holistic and exhaustive view of the enterprise, the methodology introduces a “geographic aspect”. This is the proper place to discuss location of resources and activities, mobility, outsourcing, round-the-clock distribution…).

How to build a shared and stable view of the information systems?

As far as the IT system is concerned, the challenges include:

  • designing an optimal structure that can be implemented on the long term;
  • making the description stable enough, so as to accompany the long-term transformation;
  • providing the companies or subsidiaries of the group with a description that makes sense for them, despite the diversity of technical environments.

The response of software engineering has been coined with the phrase “logical aspect”. A logical model describes an IT system, regardless of technical choices. At least, it is relatively independent from the technical target. The advantages of this approach are:

  • the logical architecture is a permanent description, which is in use through the transformation;
  • technically speaking, it is generic enough so that the companies can share a common view of the system, even at a detailed level.

Moreover, the logical aspect is the appropriate level of abstraction for the architects to cope with all concerns and high level requirements imposed on the system. First, they have to choose the style of the system they want to build. Here, SOA is an obvious candidate. Then, they adopt a metaphor that will help them to isolate and arrange the building blocks.

Can we contribute to improve productivity?

Once a logical specification is delivered, to develop software means to translate this specification into technical terms. In an MDA (model driven architecture) spirit, this translation can be partly automated.
In the case of a package solution, integration takes advantage of the logical model. Indeed, the pivot language ensuring the smooth communication throughout the system is derived from the logical model. With the logical architecture in mind, the architects are able to alleviate the impact of package integration.

How to clarify responsibilities between development and production?

The transformation chain ends up with the physical aspect. It can be defined as the projection of the software on the hardware. In order to better clarify the responsibilities, the framework distinguishes:

  • hardware – the infrastructure, strictly speaking;
  • the physical aspect – the infrastructure with its software content.

Conclusion: benefits from a comprehensive approach

As a conclusion, the content framework proposes:

  • an external and simple view with the three categories of architectures, corresponding to three communities or cognitive universes: business architecture, information architecture, infrastructure (see the framework-table);
  • a more detailed and holistic approach to the system, through the notion of aspect.

Praxeme proposes the Enterprise System Topology as a framework which complies with the above requirements. Its metamodel reflects this structure and approach. It clarifies the terminology and is a useful starting point for guidelines as well as for tooling.
As far as method frameworks are concerned, a critical point is how the identified aspects relate one to the other. The Topology of the System Enterprise answers this question.

CEISAR & Praxeme Common Glossary

Add a comment

CEISAR (Center of Excellence in Enterprise Architecture) and the Praxeme Institute joined forces and published a common glossary with a selection of terms in the field of enterprise transformation.

By converging our vocabularies, we intend to ease the communication with business and to facilitate training for enterprise architects and other transformation agents.

What’s new in Enterprise Architecture

Add a comment

Business: the right description

We generally consider the business through its activities. This spontaneous approach of business reality ranks among the functionalist approaches. It entails a difficulty: we are considering the enterprise in its organizational aspect.

Yet, what we see in this aspect are actors, activities, processes, use-cases… All this stuff conveys organizational choices.

Therefore, representations of this aspect can hardly be shared and generalized.

When the purpose is convergence, simplification, agility… we need a more generic representation. We need to isolate the core business knowledge, using abstraction and expelling variability.

The right description of business must include a semantic model

The right description of business must include a semantic model

We must recognize above this “pragmatic” (organizational) aspect a more abstract one, made of business objects, regardless of organizational habits and, of course, independent of technical choices. This aspect, we name it semantic. The semantic model is not only a sort of conceptual data model; it intends to express the business knowledge. We can use here an object oriented approach, which provides us with all the tools we need:

class diagram to structure the concepts,
state machines to catch the transformations and objects life cycles, etc.

Object oriented approach is connoted software but it lies upon philosophical works. That explains its ability to efficiently structure representations. It can really empower the formal expression of business knowledge.

Software: the optimal structure

When equipped with the two business representations – semantic and pragmatic – we can search for a better structure for the software solution.

If we conceive this structure directly in terms of technology and technical choices, we will get a representation which will be subjected to technical change. Also, there will be a risk of entering in excruciating details. Such a representation will make it impossible to drive the IS transformation on the long term.

For all these reasons, our frame introduces an intermediate aspect, between business and IT: the logical aspect. It is the ground where will be made the structural decisions regarding the software system.

For instance, SOA is a style for a logical architecture.

The logical aspect is linked with the previous aspects. The methodology states the derivation rules which help discovering the logical services.

The arrows from the logical package express dependencies and summarize dozens of derivation rules.

For more information, see the “Guide of logical aspect” (ref. PxM-40).

This approach complies with the Model Driven Architecture standard (MDA).

How to determine the proper structure of the IT system

How to determine the proper structure of the IT system

Logical Architecture: the change

By applying this approach, we deeply change the structure of the system.

Indeed, the logical architect receives from the semantic model a list of object domains. Object domains are an alternative way for structuring a model, opposed to functional domains.

The “General Architecture Dossier” goes further into this discussion.

How the comprehensive approach radically changes the structure of IT systems

How the comprehensive approach radically changes the structure of IT systems

As a result of this philosophy, the modeling database set up by the initiative is structured this way:

1.A UML package named “Semantic aspect” is broken down into object domains and subdomains.
2.Another package is named “Pragmatic aspect” and shows the some of the functional domains needed for covering the business activity. At this stage, it mainly contains the identified use-cases.
3.The last package is about the “Logical aspect” and adopts the terminology for SOA.

In addition, the “scope” module compiles dictionaries, requirements and objectives from various sources. All together these materials make up the “thesaurus”.

NB: The General Architecture Dossier and the Thesaurus are additional deliverables of the initiative.

New material

Add a comment

In addition to the page dedicated to English material on the Praxeme web site, we can find introductory presentations on:
Bernard HAUZEUR is a freelance consultant who already did a great job in training and spreading the Praxeme methodology.

Praxeme in a nutshell

Add a comment

Praxeme is an open source enterprise method that intends to bring together the various disciplines for analyzing and transforming the enterprise and its systems.
Launched in year 2004, the initiative for a public method is backed by many companies and organizations, such as SAGEM, SMABTP, the French Army and the French National Family Funding Office…
First of all, Praxeme provides a strong methodological framework, the Enterprise System Topology. This framework identifies eight aspects which enable a comprehensive description of the enterprise, from its strategy toward its transformation.
Modelers, enterprise architects, organization designers, software designers and IT architects will find in Praxeme a set of principles and methods, specially modeling techniques. Each aspect deals with a particular “view” of the enterprise or its information system. Praxeme provides us with detailed guidelines for UML modeling and MDA (see figure below).

The methodological framework at the core of Praxeme

The methodological framework at the core of Praxeme

The semantic aspect includes business objects, lifecycle of business objects, business rules, regulation… The semantic model expresses the core business knowledge, regardless of organizational or techniqal choices.
The pragmatic aspect deals with organizational choices, roles, business processes, work habits… Its representation is made of use cases, processes, and also models of organizational or administrative objects.

The Praxeme methodology strictly applies the principle known as “separation of concerns”. These two aspects – semantic and pragmatic – are enterprise business oriented, they do not integrate IS architecture such as SOA. The logical aspect shelters SOA style. It is the place for a strong logical architecture through components and services that are directly derived from semantic and pragmatic models. Praxeme proposed methods for SOA comply with the MDA standard (Model Driven Architecture). The software aspect derives from logical models and adds a technical UML profile to target the IT infrastructure, in particular programming languages (Java, C#, COBOL…) and XML. Components can be executed through a framework that is defined by a complete open source specification: the Virtual Engine for Praxeme (VEP). Several implementations of the VEP are possible: .NET, Java (in-house development or via a framework such as Spring), Cobol MVS, etc.

We believe that existing Information System, especially in large organizations, demand an in-depth overhaul. In order to manage and drive this kind of projects, we need a global enterprise method that provides us with the detailed guidelines for each aspect of the information system: semantic, pragmatic, SOA, software, VEP…