This article may be confusing or unclear to readers. Please help clarify the article. There might be a discussion about this on the talk page. (October 2010) (Learn how and when to remove this message)

Praxeme is a methodology for enterprise architecture which provides a structured approach to the design and implementation of an enterprise information architecture.^[1]

Praxeme is an enterprise methodology which aims to embrace all aspects of the enterprise, from strategy to deployment. The name "Praxeme" is a contraction of "praxis" (action) and "semeion" (sense, meaning). The methodology contains design procedures for the information system and IT systems of the enterprise. It reconciles different modeling approaches. In particular, it proposes a semantic modeling technique which benefits from the object-oriented approach, to formalize the knowledge about the business fundamentals.

Praxeme follows in the footsteps of the methodological tradition:

• It takes up the legacies from Merise, TACT, analyze-design methods, Zachman framework.
• It updating them in light of recent advances (SOA, BPM, and ontology, terminology); and
• It has synthesized these approaches and articulates them in accordance with the Model Driven Architecture

Using the standard Unified Modeling Language, Praxeme's modeling techniques enable the “Enterprise System” to be rigorously defined. That is to say that the enterprise, in an effort of rationality, perceives itself to be a system. The notion of “Enterprise System” applies to enterprises and organizations, as well as any action system – organized and striving to achieve an aim. Praxeme has been used in contexts as varied as the insurance sector, drone or weaponry systems, energy and distribution.

Praxeme is initiated in 2003^[2] as open method to respond to the need for enterprises to share a reference method in order to successfully manage their transformation projects. The foundations of the Praxeme method is initially enabled by the Aeronautics & Defense department of the SAGEM company. In 2004 the French mutual insurance company SMABTP supported the design procedures required to overhaul its information system in Service Oriented Architecture (SOA). The method was further supported by the French Army, the Caisses d'Allocations Familiales (Family Allowance offices) and the AXA Group.

The French General Directorate for State Modernization (DGME) in its document "General Repository for Interoperability",^[3] recommends using the Praxeme method for designing IT systems in French public services.

Founded in 2006, the Praxeme Institute is a non-for-profit association pursuant to the French law of July 1, 1901. It is a depository for the Praxeme corpus and guarantor of its open nature (cf. the statutes of the association ^[4]). The Praxeme Institute maintains regular contact with the university and research communities. Its interdisciplinary approach aims at making contributions from the field of science more readily usable in the enterprise.

Praxeme plays on the double meaning of the word “enterprise”: human organization and action. In both cases, they are complex objects. In order to apprehend this complexity and master action, the method distinguishes several formally identified and defined aspects. This is the Merise “levels of abstraction” or the Anglo-Saxon “separation of concerns” principle.

The Enterprise System Topology defines nine aspects, through which the documentation, decisions and projects of the enterprise are structured. As these aspects follow different rhythms and evolve differently, their separation enables us to reduce complexity and to optimize transformation efforts. For example, the technology life cycle is far shorter than that of “business” concepts.

The Enterprise System Topology which represents the methodological framework, distinguishes nine aspects:

• Political Aspect (also referred to as “teleonomic” or “scoping”): This aspect gathers together all formulations upstream of the models: values, objectives (strategic concerns, aims and objectives of the enterprise), requirements and vocabulary.
• Semantic Aspect : This aspect isolates the business fundamentals, leaving to one side the organization and work habits. The semantic model describes the “business” objects from a threefold angle: information, action and transformation (state machines). These elements are represented by attributes and class operations as well as by state machines. The class is a category of representation that corresponds to both objects and concepts.
• Pragmatic Aspect : This aspect concerns itself with the actors, their role, the organization and the distribution of responsibilities in the processes. Praxeme recommends describing the elementary work situations as use cases, this form of representation providing the link with the IT design.
• Geographic Aspect : In this aspect, we concern ourselves with the localization of the means that the enterprise calls upon. We also look at issues like working from home, nomadic activities, service continuity, outsourcing... The geographic model decides on the choices that will enable the design and dimension of the infrastructure to be made (hardware aspect).
• Hardware Aspect : This refers to the infrastructure and logistics required for the activities of the enterprise. Here the IT workers will find the machines and networks that influence some of the technical choices made. Other logistical means for both day-to-day activity and crisis situations are also found in this aspect. The hardware architecture is determined, to a large extent, by the geography of the enterprise (notion of site).
• Logical Aspect : This is an intermediary aspect, bridging the gap between the “business” and IT views. As such, it ensures the decoupling between these two universes. Here the architect designs the optimal structure of the system, with relative independence regarding technical choices. Praxeme proposes derivation rules which, when applied to the semantic and pragmatic models, enable us to deduce the logical services (as defined in an SOA approach). For the urbanization of the information systems, the logical aspect also offers the stable and formal description required to manage this policy in the long term.
• Technical Aspect : This aspect gathers the concerns the designers in charge of the realization of logical components may have, that is to say their translation into software. Technical architecture examines the possibilities and constraints linked to the state-of-the-art technologies available. Besides the technical choices, it establishes the rules of implementation and transposition of the logical model to the software. Praxeme attaches great importance to the “logical/technical negotiation” period and provides the means to reconcile these two very different, but equally necessary, expert opinions (those of the technical and logical architectures).
• Software Aspect: This aspect is that of IT programs and software components. It is here that we can find the IT products, their documentation, test cases, configurations, etc. This aspect also deals with the issues arising from the integration of packages.
• Physical Aspect : The culmination of the transformation chain, the physical architecture results from the projection of the software architecture on the hardware architecture. This is where the method deals with questions on deployment, synchronization, technical services (grid computing, databases, virtualization...).

The Enterprise System Topology articulates these aspects: it enables all the documentation to be sorted out and the rules of passage from one aspect to another to be defined. These rules are detailed in a metamodel. Praxeme proposes procedures for each of these aspects.

Praxeme is the result of an open initiative, based on the mutualization of investments. All its components are published, and may be freely accessed, under the Creative Commons license. Its works are ongoing, with the aim of covering the field of the methodology, delimited by the Pro3 (Pro Cube) schema:

• Products: something which is built or transformed (the enterprise, a process, software, a system of systems...);
• Processes: how the people organize themselves collectively (governance, transformation process, development process, organization of competences...);
• Procedures and methods: how people work (the procedures and methods at an individual level).

The first dimension is structured as presented in the Enterprise System Topology above. The second includes elements of approaches at both an enterprise and project level. As well as modeling procedures, a test method, database design, forms... are part of the third dimension. In order to continue this work and to offer a complete method to the market, the Praxeme Institute is building partnerships with other organizations, seeking to federate available energies (CESAMES and the Ecole Polytechnique, SEMIC.eu, Société française de terminologie, etc.).

• Pierre Bonnet et al. (2007) Le système d'information durable: la refonte progressive du SI avec SOA
• Pierre Bonnet et al. (2009) Sustainable IT Architecture: the progressive way of overhauling information systems with SOA Iste-Wiley 3/2009
• Dominique Vauquier (1993) Développement orienté objet. Eyrolles

• Praxeme Institute's Wiki
• CESAMES
• SEMIC.eu : European Commission
• CSDM talk (Complex Systems Design & Management 2010)