Archive Page 2

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.

http://wiki.praxeme.info/uploads/Thesaurus/THS02-CeisarPraxemeGlossary.pdf

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.

Praxeme Symposium

Add a comment

Don’t waste the crisis!

Do better with less.

The Praxeme Institute is pleased to invite you to its yearly free conference (French-speaking).
This year, the agenda covers business architecture, enterprise transformation and innovation with several concrete illustrations of the Praxeme methods.

Please register on: http://friends.praxeme.org/symposium-en/
till December 15 at 5 p.m.

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:
http://www.artofe.biz/methods/_01_PraxIntro.html
Bernard HAUZEUR is a freelance consultant who already did a great job in training and spreading the Praxeme methodology.

Official acknowledgement

Add a comment

The “General Repository for Interoperability” is an official document, validated by the French Parliament and recently signed by the Prime Minister.
It addresses the topic of interoperability and encourages best practices to be shared among public organizations.
This document recommends Praxeme as the appropriate methodology for designing IT systems.
In the wake of this work, the DGME organization (Direction générale de la modernisation de l’Etat) sent a representative who attended the recent session of the College of contributors. On a yearly basis the College of contributors gathers decision-makers who back the initiative for a public method.
So, the publishing of the RGI report is of paramount importance and acknowledges the value of the methodology.

Download the document here:
http://references.modernisation.gouv.fr/rgi-interoperabilite
Page 35 in the document.

General Guide

Add a comment

The “General Guide” gives an overview of the enterprise methodology. It has been translated from French into English and the translation is being reviewing.

Here is the first part: “Foundation” => General Guide – 1st part

It states the fundamental principles upon which the method is built. It introduces the Enterprise Transformation Topology, i.e. the methodological framework. It also provides a simple definition of the “service” notion. There can be various definitions of “service” but, at the end of the day, what really matters is the procedure that helps specifying services and improving our system. So, we have to consider not only the definition but its role in the entire way of working.

Please feel free to send feedback, questions or advices.

You can use this blog or on friends.praxeme

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”.