DVau-en

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

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:

• the official web site, http://www.praxeme.org (for now, available in French);
• Wiki containing the documents, http://wiki.praxeme.org;
• the Philosophy: http://www.enterprisetransformationmanifesto.org.

A new session of the “Business Architecture & Transformation” training course is scheduled in Lyon. It is sponsored by the ADIRA association and by Volvo Group.

Association pour le développement informatique en région Rhône-Alpes

Volvo Group

It follows a session in Paris and another one sponsored by la Française de Jeux (French national lottery), which took place in Vitrolles, near Marseilles, last month.

Française des Jeux

• business ethics,
• performance analysis and improvement,
• enterprise and IT architecture.

You can help our endeavor either by joining or by evangelizing.

Context

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.

Issues

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.

Solution

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.

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.

We can characterize the current situation in most of the complex and large organizations in terms of:

• Failure of imagination (for example, software design has dramatically regressed over the last few decades);
• Lack of willingness (the complication and weight of our systems discourage initiative).

In addition, we are facing an imbalance in the dichotomy: relations versus content. Globalization has led to huge capitalistic empires. As a result, the main job and focus of top-management consists in keeping the pieces together. This means they act solely on relations, relegating content to second place. This directly translates into the manager’s profile. After a while, the phenomenon generalizes and amplifies due to the mimetic factor: managers tend to favor people that look like them and disregard competencies and topics that they can no longer handle. I will let you be the judge of whether or not this theory applies to Enterprise Architecture.

We can see proof of this tendency in the vocabulary and behaviors. For example, the overuse and abuse of terms such as “strategy” and “governance” are meaningful clues.

Here, let me use a metaphor. The relation-oriented manager (or function) is like a harrow: it’s wide and shallow; it scratches the surface. It is not without its use, as it brings homogeneity. But, if the soil has not been correctly plowed, the harvest will not be good. It also requires the soil to be properly prepared. This is where the plowshare is necessary. It digs in-depth. This is the role of the content-oriented resources. Of course, their role can be tedious and unrewarding: they work deeply, thus slowly. Sometimes, they hit the rocks underneath and have to remove them.

For the sake of the harvest, both tools – the plowshare and the harrow – are equally necessary. Similarly, for a proper transformation of the enterprise, both dimensions have to be handled: content and relations (plowing and harrowing). Nevertheless, we observe an imbalance and a potential conflict between these attitudes and abilities (or moments).

A symptom of the imbalance (and a sign of the decline of civilization) is the ratio of PowerPoint presentations we produce against documents and serious models. We can compare this ratio through the decades. This thought can be related to the studies that lead to the conclusion: the more complex the enterprise, the more simplistic the decision-making process tends to be.

The text above is borrowed from a commented presentation used in the Thought Leader Global conference, in Amsterdam on October 6, 2011.

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

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

Caveat

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.

Upfront

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.

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

The Praxeme Institute has published a document which summarizes its philosophy:

Enterprise Transformation Manifesto

This document is aimed at all the different functions of the enterprise (in the broadest meaning that we give to this term), in particular:

• executive management, who will find within, a unified discourse and list of principles to guide their transformation programs;
• communication or marketing directors, for whom signing the manifesto will be seen as a way of affirming certain values of their enterprise;
• IT directors and more specifically within the IT department, the transversal functions who will appreciate the repositioning of enterprise architecture.

The manifesto will also be of interest to the academic world, calling for of a multidisciplinary approach, around which teaching content can be organized (please refer, in particular, to chapter 7).

Two documents are available to date:

• the manifesto itself, a list of principles which guide enterprise transformation;
• the comment on the document made by the Praxeme Institute.

For the enterprises that relate to and see themselves in this text, it offers an opportunity to communicate and affirm their values.

Details regarding the terms and conditions of the endeavor can be found at the end of the manifesto.

See: http://www.enterprisetransformationmanifesto.org