Category: Blog

How can certification help with enterprise transformation?

  By ,

If you don’t think that the economic situation justifies the attention given to the topic of transformation, this post is not for you.

If you think that putting a “transformation” label on everything we usually do (projects, strategies, organizations, architectures…), without changing a single thing about how we think about things, this post is not for you.

Compared to classic approaches, enterprise transformation requires a truly interdisciplinary approach. It has to mobilize different skills coming from varied, and usually quite impenetrable, universes. It has to organize how things circulate between the organizational and cultural silos.

Nothing is less natural! In our organizations, everything conspires to stop this momentum. Managers know this more than most. To save the very notion of transformation, we need clearly established reference points. Can we find them in the reference frameworks of customary practices? No, for a very simple reason: these reference frameworks are always, and without exception, the expression of a professional community (IT architects for TOGAF, analysts for BABoK, managers for other reference frameworks, etc.).

They always approach the enterprise from a particular angle and only ever provide an incomplete glimpse of it. By a natural – and necessary – movement, each profession fosters its own doctrine. These reference frameworks remain perfectly useful and commendable, but their use is restricted to a professional body. To serve transformation, we seek a framework that can channel knowledge from a wide range of fields. At the very least, we have to summon all transformational disciplines and get them ready to work together.

It is precisely the mission of enterprise transformation methodology to establish these reference points and to share them between all actors of the transformation. It proposes a common framework, covering the whole enterprise in all its aspects. It is from such a framework that individual contributions can be positioned and articulated together. The synergy within a transformation program can only be created if each person recognizes the other cultural universes and accepts to go towards them.

For a long time, enterprises and HR departments turned to certifications to support their transitions and their requirements regarding professional practices. Indeed, certification makes us objectify skills and evaluate individual capabilities as rigorously as possible. The result is an assurance regarding the capabilities mobilized in the enterprise and in its projects. However, enterprise transformation is a “game-changer”. As the key to transformation lies in interdisciplinarity, certifications developed around a framework of practices, in the context of a profession, are not enough.

The qualification diagram

The qualification diagram

This is what leads us to the idea of a certification built on enterprise transformation methodology. The difficulty to overcome is due to the area covered by the method: one single brain cannot contain all the knowledge relating to the enterprise and its transformation. The equation is solved, as shown above, in the qualifying diagram. It contains a common core that increases awareness of the enterprise’s holistic approach and provides common reference points. This corresponds to the level that we expect each actor of a transformation to have, from designer to decision-maker, from strategist to IT worker.

This common core enables us to create the conditions of a collective approach. That doesn’t mean that we can neglect highly specialized skills: they are based on the sharpness of the design and the capability to truly innovate. These skills are the subject of specialized certificates. The criterion of this specialization is none other than the enterprise aspect. This choice is along the same lines as indicated earlier: if we had chosen, as a criterion, the function or the discipline of the actors of the transformation, we would have instinctively fallen into the profession itself, impeding thus the stimulation of interdisciplinarity.

Started in 2013, with APMG International, the development of the certification has resulted in the “Foundations” certificate, the second of the common core. The exam is now available and is offered at the end of the “Praxeme Skills” training course, under the supervision of the Praxeme Institute.

The next session will take place in Paris, from September 15 – 17.

For more details:

Four key concepts for SOA

  By

The buzz about SOA seems to have faded away. There are no more conferences dedicated to the topic; the demand for training is declining; market leaders are trying to push new tags. Is it a sign that the SOA approach has been broadly accepted? Does it mean that the SOA logic has been assimilated and understood in depth? After a decade or so, do we have to draw the conclusion that the so-called paradigm has failed?

When considering the low level of modeling practices and the hesitations about architecture (EA, BA, CA…), one might wonder if the topic has really been exhausted. Being confronted with all sorts of issues due to low quality in IT, as a customer, as a citizen or as an agent, we surely expect dramatic improvements in the IT systems to come. At an age when digital business and innovation are commonly acclaimed as the new Utopian myth, the task of overhauling the systems is still on the table. SOA is precisely about rebuilding our systems, drawing up an optimal structure so as to avoid redundancy and to allow for interoperability.

It is about IT, but it is also an enabler for some strategic directions. Indeed, the SOA approach relates to business concerns since it can help by:

  • better serving scorecards by merging the decisional and the operational systems;
  • taking advantage of big data capabilities;
  • adding feedback loops throughout the business processes and the organizations;
  • contributing to enterprise transformation by simplifying and extending the value chain.

As an enterprise transformation methodology, Praxeme promotes a rigorous approach in order to improve our IT systems in depth. It proposes a method for designing services and architectures. This SOA approach can be summarized through four simple messages:

  1. SOA is an IS architectural style (which implies a specific role play between logical and technical architectures as disciplines).Styles
  2. If we are to live up to the expectations raised by the SOA movement, if we are to deliver on the promise of better quality, reusability, and interoperability in IT, we have to choose overhaul SOA over cosmetic SOA (or “False SOA”).FOA versus SOA
  3. To achieve the optimal system that will ease business and spur transformation, we have to summon and link together several disciplines, namely IT city planning, logical architecture and design, and technical architecture. We also have to equip them with proper representation techniques.POS versus Graphe d'architecture logique
  4. Due to the complexity of the systems, the scope of the endeavor and the diversity of skills required, it would be naïve to think we can reach the target without a method.
Positioning the Logical Aspect

Positioning the logical aspect

These four messages are detailed in the article “Praxeme’s four key concepts for SOA”.

French version: “Quatre idées fortes de Praxeme pour SOA“.

Formulating knowledge

  By

Terminology, ontology, semantic modeling

Whatever we do – be it transformation, innovation, automation… –, the starting point is always the same: business knowledge. Not only is knowledge a prerequisite, but it also has to be expressed in such a way that it complies with several criteria. It has to be:

  • complete, so as to avoid any surprises along the way,
  • unambiguous, in order to prevent conflicting interpretations,
  • accurate, reflecting reality, to support a relevant design,
  • lean and efficient, without redundancy (expressing as many things as possible using a minimum number of terms),
  • open and free from the presuppositions that could limit its reach.

This quality of expression is not guaranteed from the outset. It is reached only by constant efforts and endeavors. It is found neither on the business side nor the IT side. Indeed, we are forced to admit that it is not readily available in the enterprise. We only have to bring two business experts together and have them work on some definitions to realize that practices are based largely on what is left unsaid and that expressing ideas in words shatters the apparent consensus.

To gain an appropriate expression of knowledge, several techniques are available to us: terminology, ontology and semantic modeling. Each one has its own benefits and limitations. How can we make use of these techniques? Can they be linked together? What level of requirements should we target following the objective we have set ourselves?

These are some of the questions addressed by the article “Formulating knowledge”.

French version: “Formuler la connaissance”.

The six fallacies of business process design

  By

For decades now, it has been common place to assert the importance of a business process approach. However, when it comes to assess the outcome in terms of productivity, simplification or innovation, one could wonder: Why the hoopla?

This short article examines the six fallacies that hamper the approach to business process and business design. A second part introduces to the Praxeme method for designing processes.

 

Shedding some light on the work undertaken by Praxeme

  By

Enterprise methodology

From the outset, Praxeme wanted to be an enterprise methodology, that is to say an answer to the patent need encountered by enterprises and felt by their management teams: to link areas of expertise, fostering synergy between them. Consequence: the expression “Enterprise Architecture” (EA) was taken literally, to designate a discipline that thinks the enterprise as a whole, in all its dimensions. As a result, Praxeme separates itself from the methods proposed under the EA label and which are all in the IT sphere. Zachman, with his Quintilian questionnaire and matrix approach could have covered the enterprise, but his way of answering (What = Data) meant he missed his target. We cannot blame him: historical and cultural determinations could not, at the time, have produced any other result.

Regarding enterprise architecture

Praxeme is therefore not an architecture method, albeit an enterprise one. If we say “enterprise methodology” or “enterprise transformation methodology” it is to assert the ambition of creating the melting pot into which all enterprise approaches will converge and melt themselves into a new alloy. It is a question, firstly, of identifying the multiple rationalities that extend across the enterprise and bringing them to recognize each other and coexist better. To do that, there is a need to adopt a meta-rationality position (not a hyper-rationality one; the meta-rationality position being fully aware of the limited rationality has thus a hint of modesty). Of course, an enterprise methodology makes room for itself in enterprise architecture, a key discipline in the enterprise transformation (for the same reasons as strategic design, organization and many other disciplines).

Both these points, together, mean that we have to rethink the foundations and even to look for another site to build the new edifice. Certainly, IT tradition plays a not inconsiderable role in this prospect, not only due to our individual trajectories (that would be a little mean) but, especially by the very nature of IT, the necessary go-between the real and the ideal. (I will not go into more details; I will merely refer you to the major work by Pierre Lévy La machine univers in French).

This is how it became apparent that we needed to identify the rules for building the reference framework, the analytical framework to be applied to the enterprise. From there came the new version of the Enterprise System Topology (EST). One figure to judge our research: in version 1 of the EST there were 8 aspects, 4 of which were linked to IT; there are only 7 aspects in version 2 and IT is a component of two of the aspects. The document PxPRD-01, included in the version 2 catalog, will present these rules and the result of their application. This topic was presented in the exceptional training session “Business Architecture & Transformation”.

Coming together of IT management frameworks

Better integration of EA with IT management frameworks like ITIL or COBIT is obviously a step in the right direction, especially as these frameworks have a tendency themselves to broaden their domain and raise their aspirations. But why limit ourselves to IT practices? Is it not also important, to make a success of one’s enterprise architecture, to couple it together with process design, thus to the organization, or with ethics modeling and strategy as a discipline? These domains are also based on frameworks or, at least, on an abundance of literature and a rich tradition. We will have to succeed in making the connection, unless we want to remain confined to the IT field and drastically reduce our ability to innovate.

Regarding agility

Regarding agility, we are faced with a contradiction. It is especially the contradiction of essence between the project mode (local scope and short term) and the system scope (long-term and globalizing vision of the architecture). The necessity to reconcile enterprise stability with agility leads us to reflect on the relationship between:

  •          the agility of transformation activities, on the one hand,
  •          and the quality of the architecture, on the other.

Praxeme’s proposal to resolve the equation consists in reorganizing the transformation activities, including those of architecture and project, around the enterprise description repository. This common pot is, certainly, not easy to build and a subtle and resolute governance is required. But, when it exists, it is the way of winning on both counts: to preserve the power and the ambition of the architectural vision, on the one hand, and to accelerate the projects by guiding them towards the common interest, on the other hand. Here we touch the complexity of the enterprise, complexity that is due, for the most part, to its mixed substance. It is precisely the role of the method to analyze the nature of this material, to separate its elements in order to create working conditions. The propaganda on agile projects, alone, cannot suffice; the Platonism of the ideal architecture (top down…), alone, leads nowhere. We have to combine the two.

In summary

“Reshaping enterprise architecture”: it is what, I think, we have more or less done. It is the almost involuntary consequence of our holistic approach to the enterprise: wanting to embrace all the enterprise reality and arrange all the information and decisions that concern it, we encountered, on our way, the disciplines and gave them responsibilities in the far greater prospect of the transformation.

“Assemble practices”: Praxeme has always presented itself as an interdisciplinary approach, a framework for coordinating the different practices and a vector for brining scientific contributions and putting them at the disposal of the enterprise.

On agility: the major topic is not project agility. At the beginning of the 1980s, James Martin had already said the basic essentials with his RAD method, all too quickly interpreted as authorizing models to be thrown overboard. One day, an economist really must quantify the economic disaster that followed on from this. The major topic is enterprise agility, which rightly calls for a huge architecture effort and a rigorous approach.

Enterprise methodology

  By

Everyone agrees: the enterprise is a complex object, woven from many threads, continually obliged to adapt itself to an ever-changing world. How do we think of this complexity? How do we say everything about the enterprise without running the risk of omitting a decisive factor? How do we find the right ideas that will provide for the future?

It would be wrong to imagine that a single formula, like a magic spell, would suffice to comprehend this complex reality. We have to assemble many disciplines and link various centers of expertise. To foster synergy, we have to place them in an interdisciplinary framework, one that is coherent and able to leverage all the contributions. This requirement defines enterprise methodology.

Praxeme is an enterprise methodology, resulting from the initiative for an open method. It is based on an analysis of the Enterprise System and its internal logic. The procedures it offers cover all aspects of the enterprise, from ethics to infrastructure, from knowledge to logistics, including processes and organization.

It is one thing to have methods available for each aspect of the enterprise (methods for strategists, for organizers, for IT specialists or accountants, etc.); it is another thing to meticulously articulate them so as to obtain a harmonious transformation chain. The original concern for Praxeme was precisely that: to answer the need to coordinate the disparate specialties, all equally legitimate and necessary, but which communicate with difficulty.

This need is felt, first of all, by the heads of businesses and public sector organizations and is particularly strongly felt by those whose organizations are confronted by change. Faced with the heterogeneity of the proposals, decision-makers seek a general framework that can optimize the investment: if they focus the effort on one point of the transformation chain, if they sacrifice themselves to the urgencies of the moment, they need assurance that this action will be part of a broader plan, deployed across all the dimensions of the enterprise. They also seek ways to stimulate innovation, not only by copying what the competition is doing or adopting the latest technologies, but also by taking a fresh look at the business, by moving away from the center, by reinventing themselves. Yet, human psychology, the forces of preservation, the games actors play… all conspire to prevent this transformation.

Consequently, it is an absolute necessity to have at one’s disposal a method that reveals the phenomena at work and which provides concrete means to overcome them. The primary contribution from Praxeme is an awareness of the complexity and the recognition of the cognitive universes that must be connected and solicited. Ethics, terminology, metrology, modeling, sociology and systems architecture are some of the disciplines that enable us to approach the enterprise reality. They produce representations that the method helps to formalize and connect. For example, process design is inspired by ethical requirements, that is to say the values stated by the enterprise. Similarly, the information system follows from the business models, according to the derivation rules that guarantee its alignment and its agility.

Praxeme has been applied on different scales and in all sectors of activity. The applications include the overhaul of information systems, innovation in armament systems, modeling transport systems, evolving practices, the convergence between systems or businesses in a federation of enterprises, interoperability… The French government, in order to carry out its important state modernization programs, recommends using this method.

Given its ambition, Praxeme is a permanent work in progress. The initiative wants to be open, in both senses, where it welcomes contributions and makes its results available to all, royalty-free. Version 1 is available in the form of methodological guides that lay the foundations. Version 2 is currently being written and will complete the corpus with procedure sheets targeting the different actors in the transformation. The Praxeme Institute, a not-for-profit, state-approved association, coordinates the work and ensures the spirit of openness is respected.

For more information:

Ethics in the enterprise

  By

Over these last few years, we have seen charters and codes of ethics flourish in enterprises and the notion of corporate social responsibility become widespread.

We can delight in this phenomenon, which reflects more than just an awareness of the role and nature of the enterprise: it also shows a time where ideologies have come flooding back, institutions usually full of sense and morality no longer suffice to produce and actualize the value discourse.

Yet, is it so natural, for the enterprise, to get itself mixed up in ethics? Are there not side effects and risks?

In preparation for the development of the axiological procedures (on values) in the enterprise methodology, Dominique Vauquier has published a paper on the Praxeme Institute website.

  • Review: the discourse on values; risks and stakes.
  • Issues: enterprise ethics cannot be taken for granted; it comes up against the fact that, within the enterprise, the individual is considered as a resource, in contradiction with the categorical imperative that a human-being must always be considered as an end in himself or herself, never as a means (Emmanuel Kant). It is a good thing that ethics is developing in the enterprise but it can only ever be sincere if we face up to its problematic nature.
  • Methodology: the paper presents two procedures “Elucidate the values” and “Negotiate the values”, as well as the analytical framework for ethical models.

See: Praxeme Institute web page.

Notice: this document is not an element of the method but the preparatory thoughts on the subject. The procedures will be developed according to the contributions and opportunities that arise.

A data model is not a semantic model

  By

We change names and titles more easily than practices. Today, it is fashionable to pay particular attention to business objects. It is a good thing… provided that the models made from them that are not just “old-fashioned” data models. Below, I answer a question that I was asked about what using UML changes compared to Merise.

What is it, fundamentally, that makes the Merise entities distinct from what we call business objects? Aside from the notion of inheritance (and therefore of specialization in UML), what is it that makes UML, in the formalism and principles, more appropriate than Merise to represent business objects? Is it, in practice, the notions of aggregation and composition that change everything?

Firstly, Merise – an IT design method – does not teach us to represent business knowledge but rather imposes, from the outset, the separation between data and processing. The conceptual data model (CDM) is a data model: this means that it is not able to represent all the knowledge of the business fundamentals. Practical consequence: some information cannot be included in the model, on the pretext that it is calculated (e.g., the age of the person when we know the date of birth). This is quite justifiable for a data model, but not so for a semantic model. From the point of view of the business actor, these distinctions between raw data and calculated data are obsolete: he/she sees information that is part of the concept.

More important still: the semantics of a concept or a business object do not stop at the informative properties. They also contain active properties (what the object can “do”) and transformative properties (how it behaves). If we want to express the full semantics, we must associate the business object with the operations and the conditions of use, the constraints (business rules), the states (lifecycles)… in short everything that dangerously complicates our information systems for want of an appropriate approach.

If the UML notation is used well, it can tool the semantic modeling. The classes carry three types of properties: informative (as attributes, including calculated attributes and class-scope attributes); active (operations); and transformative (constraints and state machines).

Obviously, UML connotes “software” (and is, moreover, largely underexploited by IT specialists, for whom modeling practices have considerably regressed over the last few decades). We must not forget though that the notions and axioms that make up the object logic come from the philosophy of knowledge (the term “class” comes from here): it is therefore not by chance that this logic and the notations used to express it lend themselves so easily to the representation of knowledge. It should also be noted that the broadening of the modeling possibilities (in a semantic model compared to a conceptual data model) does not result in properties simply being added to the model: it changes the model’s structure. What I mean by that is, that it is not only the visible elements that UML brings, such as inheritance, aggregation… (these elements could, in part, be reproduced in a classic approach). By taking into account all the properties of the business object and by following the requirements for genericity and factorization, the modeler is led to arrange all the properties in a different manner. The consequences of this change in structure are considerable: if we follow them through the whole transformation chain (process design, automation…) the stakes can run into millions of euros. The textbook example is the notion of Person (or client, employee, etc.). By rigorously applying this approach, we can easily halve the number of information systems! At the same time, we can enhance ease of use because we will have built solutions that are closer to the natural representations.

In conclusion, a semantic model is far more than a conceptual data model (it contains the CDM and we can, at any moment, extract the data model from a semantic model. Praxeme provides several derivation channels from the semantic model, including the one that produces the logical data model).

The name “Business Object Model” has been overused to refer to conceptual data models (sometimes, incorrectly: there are many dreadful examples on the market). What we call a BOM (for example that of IBM) or the Information Model from ACORD are mere data models (not even normalized). The consequences are dramatic. But that’s another story…

This commentary does not call the legacy of Merise into question. UML is a notation, not a method. Merise is a method and many of its recommendations remain not only topical today, but also clearly superior to what can be found in the object-oriented methods and current practices. Thus, it is in our best interests to fructify our legacy. Praxeme readily recognizes its filiation with Merise.

Formalizing knowledge

  By

In response to a customer request, Dominique Vauquier clarifies the different ways of expressing knowledge. It is the opportunity to formulate some of the thinking that has been taking place within the Praxeme Institute, especially since the workshops held by professors Loïc Depecker on terminology and Christophe Roche on ontologies.

The article is based on the idea that the techniques we have at our disposal for expressing knowledge are spread out according to the level of formalization. The greater the effort made, the greater the possibilities of automation.

In practice, enterprises preoccupied by the topic will be able to decide on a gradual approach, taking advantage of different techniques: classifying documents using taxonomies, drawing up the enterprise terminology, developing ontologies, modeling – in particular semantic modeling.

Download the article (in French)