Archive for the 'methodology' Category

An introduction to enterprise methodology

Add a comment

A short introduction to the open method Praxeme : SLB39bEN-introVitrine

Taking transformation seriously

Add a comment


In today’s economic environment characterized by uncertainty and turmoil, most enterprises recognize the pressing need for adaptation. They find themselves under intense pressure from both economic and regulatory constraints and have realized that they cannot neglect any dimension of their own reality: economic, social, technical, institutional and even ethical.


In such a context, enterprise transformation faces many challenges. Besides the usual resistance to change, decision-makers are faced with the difficulty of fostering synergy between the areas of expertise needed to think about the enterprise as a whole, in all its dimensions.


If we are to take up the transformation challenge, we consequently need to adopt an interdisciplinary approach, one which leverages each and every contribution. This is precisely the purpose of the enterprise methodology. Praxeme, an open method, covers every aspect of the enterprise, thus enabling it to assign all players in the transformation chain to their rightful place.  In doing so, it ensures a certain level of mastery in this new transformation and operational logic.

First and foremost, we have to identify the aspects that make up the Enterprise System. This is the purpose of any methodological framework. Such a framework ought to obey several rules, which guarantee its relevance and effectiveness.


Business Architecture according to Praxeme

Add a comment

It is one thing to articulate a discipline from within its occupational community; it is another to situate it among other disciplines and from a broader perspective, that of the enterprise methodology.
This exercise has been completed through two papers, available on Praxeme website.

Business Architecture

Add a comment

Most of the enterprises find themselves  in the process of transforming in order to adjust to their environment and to fulfill their ambitions.

Transforming an object as complex as an enterprise is not an easy task and we face the risks of wastes and missed opportunities, due to misunderstanding, lack of visibility and insufficient coordination of the various specialties.

As a facet of Enterprise Architecture, Business Architecture ranks among the means in our hands that can help to build a better understanding of the enterprise and to drive its transformation.

As a discipline:

Business Architecture is a transformational discipline that translates the strategy and helps to transform the enterprise.

Beyond this tenet, we have to make clear how this discipline interacts with other ones, like strategy, Business Analysis, Enterprise Architecture, organization design, IT…

As an artifact:

A business architecture is a blueprint of the enterprise that covers its business aspects. It shows the implications of the strategic directions in terms of value, organization, processes… Being an architecture, it embraces the whole of the enterprise and considers its long-term evolution.

Business Architecture adds a sense of consistency and economy to the other approaches. By emphasizing the quality of the whole, it compensates the flaws attached to the project mode. This can be said of any type of architecture. Simply, Business Architecture confines this exacting statement to the business aspects. According to the enterprise methodology, these include: semantic, pragmatic and geographic aspects. In addition to these, the Business Architect may be in a position to negotiate with the IT architect: the logical aspect is the best place for that.

(excerpt of “Business Architecture Value Proposal”. This document introduces and promotes the discipline of Business Architecture and its role in the enterprise transformation. )

The picture below summarizes the Business Architecture’s responsibilities against the schema of the Enterprise System Topology (extract from the presentation available on Praxeme web site).

Business Architetcure Responsibilities against the EST

Architecture rules

Add a comment

An attempt to articulate basic rules that apply to any kind of architecture.

The objective is to increase awareness and quality, as far as architecture is concerned.

Rules are expressed below, at level 3 of title. Text includes comments (normal paragraphs).

1.1. Quality of representation

1.1.1 An architecture diagram describes a single aspect

Avoid mixing elements form different nature.

According to the “separation of concerns” principle.

Only views can mix several types of things, for a specified need for communication.

1.1.2 Every element of an architecture diagram is unambiguous

Given the aspect the diagram deals with, the nature of all elements of the diagram must comply with the metamodel of this aspect.

The list of elements includes the nodes and the connections.

1.1.3 The existing or necessary connections between the elements are clear

A diagram which just identifies the nodes of the architecture without considering their connections is not sufficient.

Architecture is precisely about the way things are linked together.

1.2. Quality of an architecture

1.2.1 Architecture aims at expelling redundancy

The best architecture is one that designs a system without redundancy.

This statement applies also to the business aspects.

Sometimes, decisions are made to consciously add redundancy in the system. In such cases, the rationale has to be expressed. It can be for performance or security reasons.

1.2.2 Architecture aims at reducing coupling

The optimal architecture is the one that minimizes coupling, while delivering the proper services.

The analysis of coupling encompasses:

  • A quality perspective: numbers and places of dependencies, building up a network that defines the architecture qualitatively.
  • A quantity perspective: frequency and volume of the interactions that occur at the interfaces (mathematically speaking, architecture is a valued graph).

NB: there is a balance to be found between redundancy and coupling, whatever the aspect analyzed.

1.3. Continuity

1.3.1 Any architecture representation is continued through more detailed representations or models

1.3.2 For a given aspect, architecture (the overall view) and design (the detailed view) adopt the same notation

That implies that they rely on the same metamodel (which is more important).

1.3.3 The detailed design obeys the high-level decisions and principles that have been stated through the architecture

Relation between enterprise architecture and solution architecture

This statement implies a certain discipline to be imposed to the projects. Related to EAM (Enterprise Architecture Management)

1.4. Justification

1.4.1 All decisions of architecture have to be documented and justified

1.5. Traceability

1.5.1 All decisions and elements imposed by architecture of a given aspect have to refer back to elements situated in antecedent aspects

1.6. Quantification

1.6.1 Whatever its aspect, level or scope, the documentation of a system includes quantitative information

Without this information, the decision-making comes to be difficult or hazardous.

Some examples:

  • Semantic aspect: number of instances for a given concept or business objects, frequency of change…
  • Logical aspect: volumes of flows through the system as it is designed by the logical architecture graph.
  • Physical aspect: consequences for the data storage, for the networks and the machines.

1.7. Capitalization

More about EAM than architecture description.

1.7.1 The architecture description needs to be progressively consolidated

1.7.2 Every significant project delivers models compliant with the target architecture

1.7.3 These models are poured into a central repository in order to enrich the architectural vision and to get available for he community

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