Business Architecture, an asset in enterprise...

Reference: SLB37en-PxBusArch.docx Version: 1.2 Date: 11.08.2012 [email protected]

Praxeme Institute 21, chemin des Sapins – 93160 NOISY-LE-GRAND – France +33 (0)6 77 62 31 75

Article

SLB-37en

“Enterprise Methodology”

Business Architecture, an asset in enterprise transformation

This article discusses the general questions raised by enterprise transformation. In so

doing, it specifies the scope and content of Business Architecture, a key discipline for

ensuring the coherence and effectiveness of transformations, as well as the alignment

of means with the needs and direction of the enterprise. The proposed

recommendations fall within the Praxeme enterprise methodology, which enables the

Business Architecture to be defined from the full understanding of the Enterprise

System.

What needs to be done to transform the enterprise

What needs to be produced to control the transformation

How to go about succeeding in one’s transformation

Conclusion: the resources of the open method

Dominique VAUQUIER

Joanne TOWARD

1.2, August 11, 2012

Objective

Content

Author

Translator

Version

Enterprise Methodology

ii Praxeme Institute http://www.praxeme.org Réf. SLB37en-PxBusArch.docx v. 1.2

Contents

List of tables and figures ii What needs to be done to transform the enterprise 3 What needs to be produced to control the transformation 5 How to go about succeeding in one’s transformation 8 Conclusion: the resources of the open method 13

Appendices .................................................................................................................................................. 16 A reference framework that says everything about the enterprise and articulates the areas

of expertise 16 Bibliography 17 Glossary 18

List of tables and figures

Figure SLB-37_1. Some formulations… as a summary .............................................................................................. ii

Figure SLB-37_2. The four facets of the intentional model ......................................................................................... 6

Figure SLB-37_3. The framework that organizes the aspects of the Enterprise System .............................................. 8

Figure SLB-37_4. The global dynamics (block diagram) .......................................................................................... 14

Figure SLB-37_5. Enterprise System Topology......................................................................................................... 16

“One must know what ought to be in order to judge rightly what is”

Jean-Jacques Rousseau, Emile, or on Education, book V

“Dialectics has a dual law: to view from above and hold close.”

Victor Hugo, Deeds and Words

Figure SLB-37_1. Some formulations… as a summary

Business Architecture is neither a functional architecture, nor an abstract, distant look at the information system.

Speaking about the business, the enterprise, in architectural terms is both a statement of a certain rationality of approach, a desire to control the construction and the requirement for a design effort.

The end goal of enterprise methodology is to make different universes cohabit and to articulate the areas of expertise necessary in the design and transformation of the enterprise.

In practice, enterprise architecture does not correspond to what, in theory, it ought to be. It is a risk for the enterprise.

The drawing is not the architecture, but only one of its means of expression.

The architecture is only deemed valid when we have demonstrated that its general decisions are compatible with each required detail.

Alone, the architect is nothing without a sponsor who truly wants to build something. The grandeur of the architect is in keeping with the ambition of the sponsor.

The value of architecture lies not only in its capability to accompany the projects. Architecture is, in fact, the means of compensating for the negative effects in the project mode.

Epigraph

Article SLB-37en “Business Architecture, an asset in enterprise transformation”

Ref. SLB37en-PxBusArch.docx v. 1.2 Praxeme Institute +33 (0)6 77 62 31 75 [email protected] 3

This paper is aimed at enterprise and government executives1. Its objective is to

demonstrate just how business architecture can help them to transform the

organizations that they are responsible for.

Business Architecture is a discipline whose end goal is to ensure the coherence of any transformation of the enterprise and its systems.

Enterprise transformation can take all forms of intervention in the operations, the enterprise structure, its

production or its interactions with its environment. Its impact can range from simple improvements made on a local

level to deeper and broader changes. In the latter case, the point of view of architecture is, of course, crucial.

However, even in the case of gradual and targeted change, architecture brings value by avoiding redundancy and

confusion.

We will firstly ask the question of what needs to be done to ensure this coherence and to optimize the value of the

projects. Secondly, we will recapitulate the deliverables that embody business architecture and the requirements

that guarantee the results. Finally, the third chapter will answer the question of “how does one go about deploying

business architecture and the vision it carries with it?” This will be an opportunity to position this discipline among

the other transformation disciplines and in relation to management.

What needs to be done to transform the enterprise

Any transformation begins by formulating the goal to be reached. Objectives can be

strategic or they can fit into a more routine process, as is the case with an organization

focused on quality and continuous improvement. They apply to all levels of the

organization, right down to the individual objectives in the case of management by

objectives. In any event, the efficiency of the action and the pertinence of the

transformation require that the objectives be perfectly clarified and analyzed; however, this is never guaranteed. On

the one hand, the set of objectives is complex and can be riddled with contradictions. On the other hand, the

rational analysis of the objectives and their implications is not always carried to completion and can come up

against the insincerity of the approach2.

From the very start, that is to say when the objectives are formulated, we can see that transformation runs the risk

of being led up blind alleys, unable to find a way out. One essential task is, therefore, to maintain the sincerity and

coherence in the objectives tree. This task should be transversal and global at the enterprise level. These features

are characteristic of the activity of architecture.

Recording and managing the intentions that drive the enterprise are necessary conditions to establish readability in

the enterprise and to ensure coherence in the transformation activities. Alone, they are not enough. The

signification and implication of each objective must be made explicit and the relationships between objectives

analyzed, and potential contradictions or support revealed. Substance must be given to the slogans and the concept

behind the term shown. Thus, it is often vital to restore meaning to expressions that have become routine, almost

incantatory, like “customer focus”, “innovation”, “enterprise culture”, etc. Such expressions tend to be rooted in

ritualized management speech and lose their meaning. In order to sidestep this disastrous phenomenon, the only

way is to exercise constant vigilance and to fill the concept with an activity of observation and analysis. This

activity cannot be undertaken by management due to the obvious conflict of interest.

1 We will henceforth use the term “enterprise” to refer to any form of organization or organized action.

2 To give an example: an “innovation” department is set up in response to a strategic objective but, if we do not fully grasp the

consequences of what a true innovation culture requires, the transformation will pass us by.

Introduction

Ensure the coherence and sincerity of the objectives


4 Praxeme Institute http://www.praxeme.org Ref. SLB37en-PxBusArch.docx v. 1.2

There is a prerequisite to the work on objectives: an objective is only meaningful if it is

based on the presuppositions that drive and limit it. Here, more fundamental elements

intervene and provide, as it were, the Cartesian coordinates, against which the

objectives will be able to be defined: namely values. It has become customary for enterprises to communicate

around their values. One can but applaud this as it reveals the fundamental nature of the enterprise as an overall

phenomenon, not only an economic instrument or production force but also a collective space where subjectivity

begins. Values, though, form a subtle phenomenon; many possible deviations from them lie in wait:

Communicated values, artificially established, may differ from the deep and genuine values, patiently built up

over the history of the enterprise.

Each element of the enterprise – down to the individuals – has its own value system. For example, engineers in

the R&D department, as much by education as by function, value certain virtues that have formed the scientific

ideals, whereas, in other functions, we will sacrifice more on the alter of Mammon! It is unrealistic to think that

the value systems of the different elements of the enterprise will spontaneously fit or merge as one.

Ideal values may conflict with actual practices or prevent the enterprise from adapting to its environment…

The value hierarchy of individuals may change, as in the obvious case of parenthood.

These factors, as subtle as they may be, directly affect the behavior and performance of individuals and

organizations. It is with good reason, therefore, that they are taken into account in the equation of the Enterprise

System.

It seems obvious that before changing an object, we need to know about it. However,

when the object is as complex as the enterprise, the knowledge often remains diffuse,

informal, distributed in the heads of individuals, each of them carrying a part.

Moreover, knowledge seems to be valorized in proportion to hierarchical position, at least in some cultures. All too

often, this happens to the detriment of operational knowledge and business fundamentals, even though these forms

of knowledge ought to be considered the greatest wealth of the enterprise.

Besides this problem of recognition, the knowledge is often difficult to share and risks being lost, as it is not

formalized. Yet, when it comes to innovation, optimization or a better customer response, new ideas spring up

purely from the meeting and combined efforts of different cognitive universes. It is therefore essential to create the

conditions that will allow for serious thought about the business to be resumed, anew. Among these conditions,

business modeling, that is to say its formal representation, counts for a lot. It requires an effort of listening and of

abstraction but this effort is more than rewarded by the creativity which arises as a result.

The main function of management is to drive performance. This strategic management

will be all the more effective if the mechanisms of the activity have been analyzed in

detail. This task is not confined only to modeling: it involves establishing the hierarchy

of factors that contribute to the enterprise performance. It requires surveying the field and is translated by a series

of interconnected indicators. These indicators not only make it possible to guide the person driving performance

but also to compare the performances of several entities with each other and to learn from it. Unlike the approaches

that reduce analysis to a selection of indicators present in dashboards, here the requirement is to understand, in an

objective manner, how the value is created, in some situations lost, or in others goes to waste.

Management is involved in the strategy, both in its elaboration and in its

implementation. However, the strategy is not the vision: on the one hand, it does not

describe in sufficient detail the desired future state of the enterprise; on the other hand,

Elucidate the values

Capture business knowledge

Analyze performance

Imagine the future enterprise



it is marked by circumstances and sees its horizon ever closer3. Vision, on the contrary, projects the enterprise into

the distant horizon: the long term is required, the only element able to make deep transformation possible. A

function, separate from management, is therefore required to manage this long-term vision. This prospective and

creative function should not, under any circumstances, dominate the enterprise. Its role is to bring ideas and ensure

continuity in investments over the long term.

Transform, deploy the strategy in concrete actions, and firmly root projects in the

vision.

For the same reasons as above, transformation programs are always at risk of veering off course, taken over by a

new concern, regardless of the consequences for the construction that was underway. Already, breaking down a

program into initiatives and projects can also endanger the coherence of the vision. It is a necessary exercise but

one which may lead to a dilution of inspiration and ruin the initial ambition. A mechanism must therefore be put in

place to thwart these tendencies, firmly root the projects in the vision and continue to instill the spirit of

transformation, against all odds.

In the transformation of the enterprise, the manager expresses the desire and carries the stakes. To succeed, he/she must be assisted so that the coherence and pertinence of the objectives be guaranteed and that certain conditions for success be united, notably: the elucidation and negotiation of values, the formalization of business knowledge, performance analysis, and the design of the target. During the transformation, new elements may surface or initiatives may deviate from their trajectory. The manager must be informed about them and, to this end, must be assisted by resources able to detect the unexpected detail while, at the same time, keeping the vision in mind.

What needs to be produced to control the transformation

The actions indicated above toss around vast amounts of information and call for

countless decisions to be made. If this mass remains expressed in natural language,

spread across hundreds of texts, there is no likelihood of controlling either the content

or the structure. Without this control, the enterprise is condemned to a huge loss of energy and a high rate of

redundancy. Worse still, it may miss out on opportunities for improvement or economy because it is incapable of

bringing that which can be brought closer together. How can we imagine that an object as complex as an enterprise

can be described with several texts and that nothing will escape us?

Enterprises which take transformation seriously begin by describing themselves and their vision: what they want to

become. This description should be quite well structured and formalized so that it becomes an infallible support for

decision-making and action. It therefore conforms to a formalism that ensures certain qualities. This is what we call

a model: a formal representation of a portion of reality for specific ends. We speak of the “enterprise model” to

refer to a set of rigorously articulated models that describe the enterprise in all its aspects.

We can over-formalize or destroy the communicative power of a model. However, one thing is certain: in the

absence of a model, management navigates by sight or rather feels its way along, with its own understanding of the

enterprise as its only guiding light. The enterprise model is that which articulates how management perceives the

enterprise with representations made by other enterprise stakeholders, internal or external. It coordinates the

multiple perspectives, each one revealing a necessary aspect of the enterprise.

It is not necessary to have fully developed the enterprise model, in all its details, before beginning to act, thank

goodness! But it is essential to throw down the foundations very early on, to set the structuring principles, so that

3 Due to an uncertain economic environment, the given time horizon for an enterprise strategy is reduced. In some cases, even,

the strategy can be revised several times in the year (“sliding” strategy). If this phenomenon were to continue, we would have

to admit that we had gone from a strategic exercise to a purely tactical one; hence, the importance of vision.

Stay on course

The Enterprise Model



later the repository can be enriched by all the work done and the enterprise model can be developed harmoniously,

step by step.

The methodology analyzes the Enterprise System through seven carefully articulated aspects, which we will

present below.

To begin with, the so-called “intentional” aspect gathers the elements which make up

the finalization system of the enterprise: values, wants, valorization and vocabulary

(the four facets). These elements are relatively intuitive; at least their nature does not

present any particular difficulty and they have the advantage of being perceptible by all the enterprise actors. The

table below shows these four facets and their contribution.

Figure SLB-37_2. The four facets of the intentional model

Facet Type of element Examples Discipline Action examples

Values Value, ideology Respect of the

individual, enterprise

responsibility, justice

Axiology Elucidate the values

Negotiate the values

Wants Objective,

requirement

"Capture a market"

"Design a new, adapted

product"

Teleology Elaborate the strategy

Motivate the personnel

Valorization Indicator, measure,

improvement

potential

Revenue progression,

productivity, success

rate of sales

appointments

Metrology

Vocabulary Term, definition

Terminology Collect the glossaries,

give a canonical

definition

These four approaches are closely coordinated. For example, the indicators materialize an objective and enable it to

be “objectified”; in return, a potential improvement detected from the performance analysis may itself lead to a new

objective. The terms and their definitions are essential to ensure that the objectives, requirements and indicators are

properly understood. The relationship between objectives and values is a particular sensitive one.

So, the intentional model is the starting point for all transformation: it enables the end goal of the transformation to

be clarified and communicated and plays a key role in employee motivation. Provided that it respects a minimum

of formalism, it also prepares the other models of the Enterprise System.

When we think of the enterprise description, we often think of process models. Indeed,

they enable the enterprise activity and its interactions with its environment to be

represented. However, these representations suffer from several defects, the main one

being their organizational nature: a process always carries with it organizational choices and ways of doing things.

These representations are certainly necessary but, by their nature, are difficult to share and do not encourage

innovation. The essentials should be extracted from these activity models: the business fundamentals that do not

change when the organization changes. This essential model establishes the fundamental business knowledge.

Today, one effective technique of doing that is semantic modeling, which produces a “business object” model. This

model responds to the requirement to capitalize on the business knowledge. It also acts as a platform of support to

revisit the fundamentals and so innovate in a radical manner.

The semantic model answers the question “what?” (what does the enterprise make? what does it handle?); the

activity model – or pragmatic model – answers the question “who?” (who does what?). To fully describe the

The intentional aspect

The “business” aspects



business, the question of “where” must also be answered (where does the activity take place?). A third model, the

geographic model, is therefore needed.

These models are structured according to different criteria. Here is a point with serious consequences. Indeed, the

structure of these aspects should be reflected in the IT and logistics system which must be aligned with the

business.

The aspects presented up until now define the business, its intentions, its practices and

its geographic deployment. The vision – or target state of the enterprise – also includes

aspects linked to the equipments and automation of activities. The method therefore

introduces a “logistics” aspect which includes the machines and software components that are distributed there. As

this aspect is more technical, it requires specialized competences, which makes communication with the business

actors and executive management of the enterprise difficult. To facilitate this communication, the method

introduces an intermediary aspect, a link between the business and the technique. This intermediary aspect is

known as the “logical aspect”. Here, metaphors are used, such as the urbanization of information systems or service

oriented architecture. Due to this, the logical aspect is the common ground for meetings and conversations between

business representatives, particularly the business architect, and the designers of the technical solutions and

logistics and IT system.

The value of the logical model also lies in the opportunity that it offers to effectively rethink the optimal system

architecture that tools the value chain. Indeed, rather than just referring to existing solutions, and in so doing

removing all possibility of innovation, the logical model is derived from “upstream” models which describe the

business as is or as we want it to become. Thus freed from existing solutions and preconceived ideas, the logical

model paves the way for innovative solutions and a full rethink of tooling.

On the other hand, the design work for the optimal technical system requires specific competences from outside the

domain of the business architect. The business architect only intervenes to check the alignment of the design with

the business, its needs and directions. For example, the strategic direction towards the digital economy has been

specified in business model terms, perhaps with a redefinition of the product and services catalog and adaptation of

the processes, under the guidance of the business architect who has ensured the coherence and maintained the

inspiration. The business architect still has to verify that the IT architect has drawn the necessary conclusions

regarding the IT system and that the impact on the system structure has been well perceived. Another example is

customer focus: it occasionally leads to the business model being turned upside down and certain processes totally

overhauled; it does not tolerate the redundancy rate which affects current IT systems well.

The enterprise model enables the target state to be described towards which the enterprise wants to head. Without such a model being sufficiently developed, transformation will remain superficial or will run into serious difficulties. Opportunities for improvement will be wasted and disarray will ensue.

This enterprise model is made up of several models which each deal with one aspect of the Enterprise System. The first of them is the intentional model through which management, followed by the rest of the enterprise, specifies and negotiates their objectives and their values. The business is described through:

a semantic model, which fixes the fundamental knowledge,

an activity model, which describes the organization and the processes,

a geographic model which deals with questions regarding the localization of the activities.

These models are rigorously articulated in such a way as to ensure the coherence of the design. They provide a successful expression of the strategy and specify its implications. Furthermore, because they respect precise rules, they can be reused by the designers of the technical system (logistics and IT) who tool the business.

Projection in the technical system



Figure SLB-37_3. The framework that organizes the aspects

of the Enterprise System

The appendix contains a more detailed presentation of the

reference framework (see p. 16).

How to go about succeeding in one’s transformation

The first condition of transformation success lies in the desire and sincerity of the

change. The second is the seriousness given to defining the transformation. This

presupposes that the existing state and reasons for change have been analyzed, as well

as describing the future state with sufficient rigor. Finally, once the target is known, the most delicate task remains

to be done: establish the trajectory, after having anticipated the difficulties as best as one can.

At each stage of the transformation process, Business Architecture has an important role to play:

As seen before4, it helps to analyze the real intentions and to add weight to the key concept.

With the help of the right models, it specifies the contours of the future Enterprise System, at least in these

purely business aspects.

It contributes to elaborating the transformation trajectory, by bringing its knowledge of the stakes and

constraints of the different enterprise functions. In this exercise, it is characterized by its concern of the whole

and the long-term: preoccupied with the coherence and quality of the whole, it acts as a counterweight to the

decisions focused on the preoccupations of the moment.

The value of business architecture5 lies principally in its holistic approach and its concern of expressing and

structuring the business in an optimal way, through the organization, processes, but also knowledge. Its

contribution is linked to simplification and innovation.

The question becomes: how to go about deploying business architecture and the vision it embodies?

Firstly, we should ask ourselves what those in architecture do. Presenting all there is to

do in order to transform the enterprise may alarm because of the mass of information

that must be gathered or produced. We have spoken of models which can be extremely precise and detailed. Do all

these tasks fall within the domain of the business architect? The practical response is already found in the

organizations: they do not hire enough architects to cover such a workload. In fact, the architect is not the modeler.

What characterizes the architect is his/her scope of view: it covers the whole enterprise. The price to pay for this

effort is, of course, not being able to get down to the details.

All the same, the relationship between global/local or general/detail is not so simple. Indeed, it would be too easy to

map the enterprise and architect it without having checked its behavior and its feasibility6. The architecture is only

4 See Ensure the coherence and sincerity of the objectives p. 4, and “The intentional aspect” p. 6.

5 See “Business Architecture Value Proposal”, cf. bibliography.

6 We must speak out against the abuse of presentations here: a slide is not an architecture.

Conditions of success

The level of detail



valid once we are sure that all the details will find their rightful place without ruining the quality of the whole. It is

important, therefore, that the architect has the capability of anticipating the infinite diversity of the elements that

will be housed within the proposed architecture. This is what makes this job difficult.

From this situation, a skill requirement is derived: the architect must be or have been a modeler; at least, he/she

should understand the problems that the modeler faces, in all the aspects covered by business architecture. Ideally,

architects should have a level, or have had modeling practice to the level where they are able to abstract the rules

and principles that underpin the quality of the models.

This does not mean that the business architect acts as a modeler: it is not his/her responsibility to produce the

details of the models; what we expect the business architect to do, is to elaborate the structures into which the

models will fall. The business architect should do it with full knowledge of the facts and awareness of the

implications. For example, the way the domain boundaries are cut up by the business architect will lead to

organizational effects and may come up against impossibilities when the business architecture is projected in the

technical system.

One point often neglected and yet which determines the effectiveness of the

investments is the continuity between the grand vision of the architecture, on the one

hand, and the local implementations, on the other. This continuity must be perfect and

each element should fit together naturally in the whole.

Let us take an example in the semantic aspect. The architect will not spend the time necessary to develop a true

semantic model: however, he/she must be able to read it and to detect, among other things, whether the genericity

has been taken far enough or not. The architect will check, in particular, that the semantic model is not polluted by

organizational or technical considerations which will reduce its scope and stability. The architect should be able to

detect any difficulties linked to the structure that he/she recommended for the semantic aspect. The architect will

notice, for example, that the coexistence of a Client class and an Employee class will generate redundancy. He/she

will encourage the formal and structural quality of the model and will be capable of estimating the millions of euros

saved and the degrees of agility gained, by applying architecture rules. The vigilance exercised by the business

architect will lead to this type of benefit.

Such rewards rely on a prerequisite: that the architect and the modeler speak the same language and use the same

notation. This is a consequence of the continuity principle between the global vision and the detailed

representation.

Business architecture differentiates itself from other architecture categories by the level

of concern that it considers. Among the seven aspects that make up the Enterprise

System, business architecture is concerned with the intentional, semantic, pragmatic

and geographic aspects. It also intervenes in the logical aspect, although it is not responsible for it. It does however

verify the adequacy of this aspect with the requirements and strategy. At a minimum, it makes sure that the state of

the proposed technical system will not handicap the planned transformations.

Before specifying the relationship that business architecture has with enterprise

architecture, we must first clarify the latter. If we keep to the terms, we understand

enterprise architecture as being the discipline that deals with the enterprise in all these

aspects7. In this view, business architecture is, therefore, a subset of enterprise

architecture, and the business architect is answerable to the enterprise architect. There is no choice but to accept

that this is a theoretical view. In practice, the overwhelming majority of people who have the title of enterprise

architect work within the IT department; this job title is no more that a new name for “IT architect”.

7 This is the definition given in the Enterprise Transformation Manifesto (see in the bibliography).

The continuity principle

The level of concern

The relationship with enterprise architecture



In these conditions, the relationship between the business architect and the enterprise architect develops around the

logical aspect, defined as a link between the aspects and competences connected to business, on the one hand, and

the technical aspects and competences (notably IT), on the other.

Consequently, the role of integrator of the aspects and supervisor of the transformation chain, which goes from

strategy to deployment, falls to the business architect. This remark is of crucial importance for the organization of

the transformation. There are so many wasted opportunities due to the confusion that reigns!

Still in the perspective of the transformation, the critical point for the management is

the coordination of the areas of expertise and the stimulation of the imagination. It is

with this idea in mind that we deal with the competences of the business architect and

the organization of the function.

To answer this concern, the ideal organization consists, for the management, in acquiring a “transformation

department” in which one would find all the key profiles who think about and drive the transformation. One would

find, of course, business architects, working alongside strategists and organizers. Should the transformation have a

large technical or IT content8, representatives from the corresponding functions would also be part of this

transformation department. A more radical solution: the transformation department absorbs the functions involved.

This option, at least, avoids having the transformation department behave as a consultative body, giver of advice

but without the necessary means of action.

Such a transformation department will act more effectively if it reports to the executive management and is seen as

the management’s task force for implementing the change that has been decided.

Regarding the competences, it is important to avoid the error of having a single profile:

transformation requires different skills. The whole art of the person driving the

transformation will consist in maintaining a balance between the specialties and creating synergy. This is

particularly obvious between “business” competences and technical competences. Within the domain of business

architecture, the competences to assemble are many and we cannot always find them within a single profile; they

cover: business knowledge, sensibility to organization and management theories, business watch for those trends

that modify the business (for example in the marketing domain), performance analysis, organization and process

design, modeling techniques, understanding the “business” stakes and strategic directions, the capability of

reformulating general directions into concrete actions… Once again, the architect is not asked to do all this and to

do down into great detail; he/she is asked to come up with the comprehensive plan and to guide the integration of

the elements into this overall plan.

In order to see things more clearly, we can organize the skills into two main categories, corresponding to well-

defined psychological profiles:

on the one hand, content skills (form and content, modeling and business);

on the other hand, people skills (listening and communication, taking expectations into account and

dissemination of the decisions).

If one of these categories were to be missing, then the transformation would be doomed to fail. Yet, the natural path

of organizations leads to favoring a single profile, often that of leader, and so oriented exclusively towards

relationships. This trend considerably weakens the transformational power of architecture and sometimes

condemns the architecture function to enter into a political game for which it is ill prepared and where it loses its

very essence.

8 The textbook case is the adaptation of the enterprise to the digital economy (cf. reference SLB-41).

Organization of the function

Competences



The term “architecture” came to us as a metaphor. We use it to say that the enterprise

must consciously build itself, as a coherent whole, efficient and harmonious. As for

any construction, its size, its message and even its style are decided by the sponsor

before being designed and detailed by the architect. Without a prince, no architect! Often, by choosing the

architect, the sponsor chooses the style and states the ambition.

This goes to show that the relationship between the business architect and the management of the enterprise must

develop at the very top of the enterprise, there where destinies are decided. Otherwise, we can no longer speak of

transformation and the architecture is reduced to mere decoration.

This also shows the necessity of a regular and close relationship between the architect and the CEO. Together, they

discuss and elaborate on the project, make alterations to the plan, adjust the details as the construction goes along.

Decision-making happens according to a subtle process, closer to sharing and co-creating rather than following

orders. This explains that, in the enterprises where the executives are not involved with enterprise architecture, this

discipline vegetates and does not fulfill its potential.

Enterprise strategy is often given as the starting point for business architecture, at least

in its design effort. This should not wipe out the particular nature of architecture, a

nature which opposes it to strategy in many respects.

Indeed, the strategist is especially attentive to the environment and to the positioning of the enterprise in its

environment, whereas the architect looks after the substance and structure of the enterprise: his/her concern is more

internal.9

Another point: the strategist reasons in a shorter term, indeed one which is increasingly short, with the

generalization of sliding strategies which can be re-evaluated several times per year. On the contrary, the architect,

aware of the effort required to transform the enterprise, takes a long-term view and adds to the necessary external

adaptation, the search for internal balance. The strategist can modify the destination and the trajectory of an aircraft

carrier in immediate reaction to changing conditions, but, if the equipment needs to be modified, the architect will

request more time.

Finally, if the strategy inspires the enterprise architecture, it is not the only source: the architect integrates other

elements into his/her reflection, notably the innovations or opportunities that can come out of any of the seven

aspects of the Enterprise System: new forms of organization, new practices in such and such a function,

technological possibilities, etc. It may happen that these opportunities take on such proportions as to affect the

strategy10. In this case, it is the architectural thinking that inspires the strategy. This illustrates that the relationship

between strategy and architecture is not a one-way street and that the enterprise would benefit from a strong link

between these two disciplines, as achieved through a “transformation department”.

When all is said and done, what does the business architect have to do? This article is

not sufficiently long enough to detail the actions; we will instead define the attitude of

the architect, through his/her key functions, at the enterprise transformation level11:

ensure the flow of ideas in the enterprise;

9 This remark does not contradict the interest the architect takes in the interactions of the external systems and the issue of

interoperability. The strategist identifies these external systems and evaluates the need for interactions; the architect elaborates

the modalities of these interactions, both organizational and technical.

10 The most obvious case that springs to mind is that of digital technology which can go as far as modifying sales techniques or

the customer relationship. As it happens, the decision chain leading to the transformation is bottom-up: it begins with the

technology watch, then goes through business architecture which reformulates the technical potential in usage terms and

effects on the enterprise, and results in the strategic decision, having evaluated the predicted impact on the market.

11 Regarding the detailed process of business architecture, see in the conclusion on the methodology.

The relationship with management

The relationship with strategy

The actions of the business architect



elaborate the vision;

help to realize the vision.

The business architect assumes a role of passer-on. In this complex organization that is

the enterprise, made up of highly individualized cognitive universes, with various

rationalities passing through them, the business architect is the one who circulates the

information, decisions and ideas relative to the enterprise construction and transformation.

This role is essential in innovation and adaptation. In particular, it contributes to reducing the divide between

business and IT (or more generally, the technique). The global point of view adopted by the architect enables

possible improvements to be identified and wasted efforts eliminated.

With other functions such as quality, technology watch and innovation, architecture is part of an organization that

lies parallel to the hierarchical line. As much as the latter is focused on the day-to-day operations and performance,

this parallel organization is concerned with long-term improvements and construction. Its mission is to observe the

running of the enterprise and propose improvements. To this end, it is always on the look-out for anything that

steps outside the rules, be it a malfunction or a suggestion.

From the material gleaned by its initial action, the architecture function moves on to its

constitutive activity: design. For business architecture, the design materializes through

the enterprise model, in its future state. It elaborates the overall vision, in any event in

it “upstream” aspects, as detailed above (p. 5).

Several dangers lie in wait for the practice of architecture:

to underestimate this global design action, as its attitude and its horizon run counter to the prevalent ongoing

activity;

to limit the deliverable and the target description to a superficial presentation and a theoretical drawing12;

to disregard the boldest scenarios, because of worries about receptiveness and consensus in the enterprise;

on the contrary, to go too far in the transformation without doing what is required to bring about a real

conviction and involve, at least, the most active part of the hierarchy.

Once the vision has been agreed upon, there are two possibilities:

either the architect remains in charge and takes on the role of contracting

owner;

or the architect retains only a consultative role in accompanying the transformation.

The first scenario remains true to the architecture metaphor: architects leave their design office with the approved

plans and instructions for the different trades under their arm; put on their boots and go to the building site to

monitor the work, perhaps test and rectify the boldest ideas.

However, this is not what is commonly observed with business architecture. In fact, we have to reckon with a major

imbalance linked to the dominance of the project mode. The largest part of enterprise investments is managed

through projects, programs or initiatives. The resources are placed under the aegis of the directors. In comparison,

architecture has no means, other than its authority, at best. In classic architecture, the name of the architect is

associated with the building itself. Who will associate the business architecture function with the transformed

enterprise? 13 This is where the metaphor reaches its limit14.

12 Architecture is not the drawing, even less the “slideware”. The building will only stay standing if the rules of the art have

been respected. The presentation can be a communication tool; it is not the description of the architecture. The reputation and

the value of the discipline are in the process of being ruined by these superficial practices – as has been the case with

Enterprise Architecture over these last years.

13 The same can be said of enterprise architecture.

Ensure the flow of ideas

Elaborate the vision

Help to realize the vision



In any case, for a real architecture function to exist and for it to bring its full value to the enterprise, the architect

has to behave as guardian and promoter of the vision. This means fighting against the short-termism, staying on

course, broadening the horizon. A lot of effort and investment is wasted by being too dispersed and inattentive: the

architect’s role consists precisely in fighting against these natural tendencies of the social organism. This action

rests on the coherence of the vision and the constancy of the will.

Business architecture has a major role to play among the transformation disciplines. It dialogs with strategic design and all specialties capable of bringing new ingredients to the enterprise model. It ensures that ideas flow in the enterprise and reformulates them in a precise manner and positions them in the common framework. Its founding act is to develop the target, the desired future state of the enterprise. Nevertheless, this work is fruitless if it is not supported each time by the CEO of the enterprise. No sponsor, no architect!

The architect’s time is spent between thinking deeply (design of the target) and accompanying (project intervention). The reality of the architecture depends on the balance found between these two moments.

Conclusion: the resources of the open method

The enterprise is a complex object: it is made up of a multitude of interacting elements,

humans, collective entities, physical objects, motivations, knowledge, etc. In order to

be able to transform such an object, an accurate and precise perception is required. The

discipline of business architecture takes on this task, at least for a part of the elements.

Thanks to its analysis and representation techniques:

it helps to clarify and to organize the intentions, values and goals that form the engines of the enterprise actors;

it expresses the business knowledge so that it can be handled and revisited for innovation;

it seeks the optimal structures for the enterprise to operate better (through the organization, the division into

processes and the structuring of knowledge);

it dialogs with the technical functions to equip the activity with the best tooling possible.

Its constant concern is to ensure the coherence of the transformation. An enterprise without an architecture function

deprives itself of the global vision and puts itself at the mercy of drifting towards isolation in its entities. The

architecture function is more than financed by the economies it provides by banishing redundancy. In addition, it

acts as a facilitator for innovation.

To update this transformation potential, the architect should nevertheless avoid certain

pitfalls. The first one is the living contradiction that architecture represents in the

enterprise culture today. Because architecture gathers all the characteristics that have been removed from the

“normal” way the enterprise is run and from its dominant ideology: intellectualist, abstract, holistic, viewing the

enterprise in the long term, it is everything the decision-maker hates! It is especially because this way of thinking is

marginal, albeit vital, that it must find its place, for the common good. Architects must resist the prevailing pressure

to stick to their ideal, no matter what the cost.

Another pitfall is attributable the architects themselves: from the moment they sacrifice the rigor of their practice to

the demagogy of communication or haste, from the moment they choose the easy option by giving up the rules of

14 By repercussion, this limit on responsibility again reflects on the very content of the discipline. What remains of the

architecture metaphor once the creator-transformer responsibility has been removed, is the design of the whole. However, in

part because the business architect has neither the responsibility nor the recognition, he/she finds the legitimacy contested.

From there, comes the compromise and finally the renouncement. As proof, how the time is spent: in practice, the architect

spends more time tagging along behind the projects than in front of the drawing board.

Summary: the value of business architecture

Recommendation



the art, their deliverables will have no more value, their inspiration peters out and they lose their raison d’être.

Consequently, they must remain very particular about the content and rigorous regarding the form.

To help them with their task, the Praxeme enterprise methodology offers business

architects:

1. firstly, a framework that gathers together the types of elements to consider and which rigorously specifies

the content and the quality of the deliverables required in the transformation;

2. secondly, guides that state the modeling techniques for the aspects of the Enterprise System that they are

responsible for15;

3. finally, to facilitate their interaction with the technical, logistics and IT functions, business architects can

refer their interlocutors to guides of “upstream” aspects, so that every actor fits into a global and coherent

approach, each according to his/her own specialty16.

Concerning the process for the architecture activity, the method stresses the distinction between the project mode

and the transformation activities process. This distinction has a strong impact on the organization.

Figure SLB-37_4. The global dynamics (block diagram)

For the decision-makers, differentiating between a true architectural design and a simple drawing is not easy. To

guide them, the method provides architecture rules17.

The Praxeme method results from the initiative for an open method. It has been

developed with the support of the enterprises participating in this initiative and who

have accepted to pool their investments on questions of method. The foundation is established and solid, proven by

15 As a reminder, the aspects that business architecture is responsible for are the intentional (strategy, goals, indicators…),

semantic (knowledge), pragmatic (organization and activity) and geographic (localization of the activities) aspects.

16 In particular, the method explains how to derive the technical and logical models from the “business” models (if they are

well formed). In this way, it valorizes the investment granted on the models: they serve not only to describe and redesign the

business but also to build the tooling and align it with the actual perception of the business.

17 The majority of these rules apply whatever aspect is being considered. There are also requirements specific to each aspect;

for example, we do not treat knowledge and physical means in the same way.

Some help

An appeal



experience, but much remains to be done to thoroughly describe the activities involved in enterprise transformation,

from strategy to deployment.

We therefore invite any enterprise or organization with needs as regards methodology, particularly in the domain of

business architecture, to join this initiative.



Appendices

A reference framework that says everything about the enterprise and articulates the areas of expertise

The reference framework is an essential tool for organizing the mass of information

and decisions to deal with when we approach the description of the enterprise. It would be impossible to do without

it in the case of transformation.

The framework proposed by Praxeme integrates several traditional methodologies and is based on a detailed

metamodel. It is known under the name of “Enterprise System Topology”, “topology” taken in its etymological

meaning as discourse of place: the schema shows where each element of enterprise information should be

positioned, depending on the nature of this element.

The below schema provides a brief overview18.

Figure SLB-37_5. Enterprise System Topology

18 For more details and for a justification of the schema, see the Praxeme General Guide.

Introduction



Bibliography

“Business Architecture Value Proposal”, ref. PCD-02, http://www.praxeme.org/index.php?n=Modus.BusinessArchitecture

“Business Architecture Blueprint – A customer-centric and multi-accessible

enterprise”, to be published

“The Enterprise Transformation Manifesto”, http://www.enterprisetransformationmanifesto.org

Presentation leaflet, http://www.praxeme.org/index.php?n=Syllabus.SLB01

Arguments for an open method, http://www.praxeme.org/index.php?n=Syllabus.Prospectus

“A method at your disposal”, 2-page summary, ref. SLB-39, http://www.praxeme.org/index.php?n=Syllabus.SLB39

The white paper, ref. SLB-02, http://www.praxeme.org/index.php?n=Syllabus.SLB02-WhiteBook

See: http://dvau-en.praxeme.info

The general guide provides an overview of the method.

It is continued with one guide for each aspect.

The business architect will benefit from reading the guides of the intentional, semantic, pragmatic and geographic

aspects. The general notions of the guide of the logical aspect will help him/her to dialog with the logical architect

or the information systems urbanist.

On business architecture

Presentation of

Praxeme

Architecture rules

The guides

http://www.praxeme.org/index.php?n=Modus.BusinessArchitecture

http://www.enterprisetransformationmanifesto.org/

http://www.praxeme.org/index.php?n=Syllabus.SLB01

http://www.praxeme.org/index.php?n=Syllabus.Prospectus

http://www.praxeme.org/index.php?n=Syllabus.SLB39

http://www.praxeme.org/index.php?n=Syllabus.SLB02-WhiteBook

http://dvau-en.praxeme.info/



Glossary

The definitions below are taken from the Praxeme Thesaurus, available online at www.praxeme.org.

Term Definition

Activity Domain An area of activity, which is organized around a role or entity in the organization

Architecture Discipline that embraces an entire system and focuses on its properties as a whole

Aspect Part of reality, which has been isolated for the sake of study, in accordance with its inner

logic

Business Architecture Transformational discipline that translates the strategy and helps to transform the

enterprise

Complexity Quality of an object when it can be understood and its behavior predicted only by

considering numerous inter-related elements.

Complication Unnecessary and artificial complexity

Derivation The action of obtaining something from a source or origin

Design To invent

Domain An area of knowledge or activity

Enterprise Architecture Discipline that analyzes the strategy and determines the main decisions for transforming

the Enterprise System

Enterprise System The enterprise that perceives itself as a system

Enterprise System Topology Frame of reference that organizes the information and decisions concerning the

Enterprise System

Enterprise Any type of organized and willful entity or action

Framework Theoretical foundation upon which the enterprise methodology is built

Geographic Aspect Records the physical location of objects and actions. Notions of sites, locations, and

communication needs appear here

Ideology Set of pre-wired answers that the actors use in their day-to-day actions and decision

making

IT Urbanization Design discipline which aims to structure the information system and align it with the

enterprise’s strategy and business

Logical Architecture Primary description of the IT system

Logical Aspect Intermediary aspect that allows for describing the system in a formal way, regardless of

technical choices

Metamodel Model of models

Method How to do something

Methodology Discourse on the method

Model Formal representation of a portion of reality

Modeling To model is to rigorously represent part of the reality, in conformance with specified

formal rules

Object Domain An area of knowledge, which is organized around one of the main objects of the

described reality

Performance Result or level of results of an activity

Pragmatic Aspect Regroups the different choices as to how business is done: the actors, the responsibilities,

the actions on objects, the processes and the work situations

Praxeme Enterprise methodology that covers every aspect of the enterprise

Semantic Aspect Describes the objects at the heart of the business. Describes the fundamental core

independently of how the business is done

Separation of Concerns Principle by which we consider various aspects of a reality separately

System Set of interconnected elements, perceived as a whole

Target Aspirational state of the future Enterprise System.

Trajectory Way to take the System from its current state to the targeted state

Transformation Collection of activities that define or change the business

Transformation Chain Unified concept of activities linked together for enterprise transformation

Zachman Framework Framework for enterprise architecture

http://www.praxeme.org/

Business Architecture, an asset in enterprise...

Documents

Transcript of Business Architecture, an asset in enterprise...