Archive for May, 2009

Discussion on semantic modeling

Add a comment

A recent discussion with an architect on the semantic modeling approach gave me the opportunity to answer some key questions. It also enabled us to review a document that defines the semantic model, soon to be published on the Praxeme Institute’s web site. Extract.

Inheritance (IMHO) is not a business concept, so I would not introduce it in semantic modeling. Inheritance is used to simplify code. Only in very rare cases is inheritance seen in real life (such as the relationship between parent and child).

[DVAU] “Inheritance” certainly is a technical term but the inventors of the object-oriented (OO) approach consciously introduced it, as it corresponds to a very natural mechanism, introduced by Aristotle, known as “classification”. I agree that it is not a business concept but, classification is a tendency of the human mind that even young children master, as soon as they are able to recognize that tables and chairs are furniture…
Anyway, even if it plays a role in semantic modeling, it is not the purpose of this document to introduce these kinds of details.

How will you ensure the consistency of the model throughout the whole enterprise, taking into account that the same business concept can mean different things to different users (e.g., “customer” means somethings different in marketing, legal, claims…)

[DVAU] Good point! In fact, the methodology proposes another place for that, which I used to call “pre-modeling”. The more positive term is “scoping” (coined by Philippe Desfray); sometimes, we refer to the “political aspect”, emphasizing the values and strategic objectives. Before establishing the models, we capture the vocabulary (I should use the plural: vocabularies) and welcome diversity in the shape of dictionaries. It is at this stage that we encounter the ambiguities of language and business representation. The semantic model (or other models) then formalizes these differences, eliminating all ambiguity.
For instance, there will be many occurrences of the term “customer”, each one related to a specific context. One occurrence will be assumed by the “Party” class; another one by an association role or a class “Role”, etc. In each case, we keep the relationship between the term (terminology element) and the modeling element: that’s traceability.

Separation between object domains and functional domains is very relevant (IMHO). It will (in the more technical layers) result in the separation between:
o the data and the related methods to manipulate this data (in OO concepts: the object)
o and the way to manipulate/combine this data into useful information (the application) to achieve business goals (e.g., selling products)

[DVAU] Yes, it is this distinction in the business representation that helps to structure the IS system. The first place is the logical aspect where we distinguish a “Core Business” stratum and an “Activity” stratum. The former derives from the semantic model; the latter is populated by constituents which come from the pragmatic model (use cases…).

What is the difference between the semantic model and business domain model?

[DVAU] The semantic model is situated at the same level that the conceptual model of traditional methods was. When we refer to business models, we tend to overuse the process approach or use-case approach. Both pertain to the functional culture that describes the business in terms of activity. When identifying the semantic model, we force ourselves to produce a separate description of the essential knowledge, independently of how business actors behave.

 MDA (model driven architecture) is a very powerful way to convert diagrams into working code (to put it very simply), but besides having a very good model there are other prerequisites.

[DVAU] Totally agree. We have to clarify all these prerequisites (appropriate technical framework, “logical/technical negotiation”, good tools, skills, administration procedures… To put it in a nutshell, we need a comprehensive methodology that clarifies the responsibilities and that is embodied in a chain of tools.)

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…

What is Praxeme?

Add a comment

Praxeme is an open method which aims to cover all aspects of the enterprise organisation.

We consider that it is not enough to develop individual expertise and guidelines for each specific area that an enterprise has to deal with — such as strategy, organisation, processes, IT, skills etc. Rather we should look at the bigger picture and provide an overall framework that links the different disciplines. This statement is the starting point for the enterprise methodology.

The initiative for an open method

Many actors share this view. They have joined forces in an effort to take this method forward. For more information, please see the “About” page. The Praxeme Institute, a non-profit making association, coordinates the investments and guarantees the openness of the initiative.

It’s all in the name

“Praxeme”, as a name, comes from two ancient Greek terms:

  • “praxis”, meaning action;
  • “semeion”, meaning significance.

Hence, the motto: “Praxeme, meaning in action”.