Seven Principles of Enterprise Architecture

Enterprise Architecture is short of ideas

(french version)
With the break of digital Transformation, discipline of Enterprise Architecture, EA, is shaken on its bases. A questioning is more than necessity. Large consulting firms, carriers of miracle solution, are reduced to simplistic recommendations (bimodal IT) attacked by competitor gurus (see the debate), without real proposal on the bottom.
Confronted on the one hand with an immense IT heritage, and on the other hand with this multiform disruption, Enterprise, CIO, do not know by which end take the problem. One claims to see cleavages everywhere: between the IT into bimodal, between the SQL and NoSQL, between intern and external Information Systems… But, clearly, these dichotomies does not function, because the value chain do not divide thus.

Let us opt for an “Urbanistic” vision, a comprehensive view of the large heritage of IT components, and of their life cycles… all across the silos, technologies, beyond the borders of the company. And see the infinitely complex system of these components like an immense city, where the local action is vain : the city metaphor remains powerful.
Let us explore the “urbanistic” actions in the form of invariable principles , of rules to the long course.

Imperfections of the demography of the components

If we suppose that, by unit of time, a number of components is created, and an other number of components disappears, we have a population whose total volume varies. This volume is the cumulative result of these births and death of components.

In fact, components, even useless, do not disappear naturally in the course of time: their lifetime is artificially lengthened. The global population tends to increase more than necessary, it is the phenomenon of “coral reef”: new components are embedded with old components, sometimes completely useless.
In addition, the connections between components are, to some extent, erratic, redundant, contingent. It is the spaghetti effect. I called these deviations "imperfection of the algebra of composition" (see the document available on Slideshare).

In short, one can explain the dysfunctions by the “imperfect linkage” between components.

These imperfections are of several orders. By objectifying them appear easily some EA rules susceptible to correct these well known faults.

7 Principles of Enterprise Architecture

7 principles of Enterprise Architecture are suggested to correct in egg the defects which appear, in the course of time, in any system.

1.    Correction of the imperfections of temporality

Let us suppose an exchange, an interaction, unambiguous: the same fact, in the same vision, the same cycle of setting in quality, same exchanged information. It is “perfect”. But in fact this can result in exchange in terms of:

• latency (batch mode),
• desynchronization (message mode),
• synchronism (mode service or API).

Thus the exchange is imperfect, variable in its methods, dependent on fortuitous circumstances. This imperfection should be corrected, for example by using a storage to accept or restore various temporalities.
The creation of clones of the same component will be thus avoided. One will avoid perennializing the imperfections of long latencies by propagation, during successive exchanges.

2.    Imperfections of identity

Let us suppose an exchange which one believes perfect, but makes some error on identity, or a defect of synchronism,…
For example the object has changed of state, whereas this change is not known by the partners of the exchange. A checking is to be made before validating the exchange, to avoid the propagation of errors.

3.    Imperfection of genericity

Let us suppose an exchange which would seem perfect, from the point of view of the supplier, this supplier being polarized on a case, a vision silo, etc… Actually, in a more complete view, one can estimate that it is only one typical case, which, in this vision, must be included in a set of vaster cases.
One cannot let transmitting and receiving exchange in all quietude: from the global point of view, their “private” exchange would be imperfect.
This exchange is to be placed in a more general case. The community can thus have a transverse vision, at the adequate level. The generics simplifies Information System, and facilitates its transformation.

4.    Imperfection of granularity

Between 2 levels of exchange, one being located at a “macro” level and the other at the finest level, the level of the grain, the second is amply preferable. It is a fundamental rule of Enterprise Architecture.
Indeed the exchanges of aggregates are disrupted as soon as the logic of aggregation chnages. It is simpler and stable to calculate the aggregates by request, at the need time.

5.    Imperfection of publicity

Let us suppose an exchange, perfect on any criterion, but which, completely or partially, can concern a “public” IS space. It does not have to remain completely private, or under private statute using redundant publishing functions.
Publicity can be organized, with deposit contracts, and managed, under the terms of contracts of subscription.
The mutualisation of this function makes economies of scale, unimbricates the suppliers and the customers, and gives transverse knowledge.

6.    Imperfection of stability

Let us suppose a perfect exchange at a given time. However, after functional evolutions, modifications are introduced, making the exchanges impossible in the state, and implying a management of version, on the supplier and customer sides.
This creates a complexity, which one can compensate for by masking instability, the successive versions being converted into alternatives of the same one version.

7.    Imperfection of subsidiarity

In the absence of management of subsidiarity, two extreme situations possible and are unbalanced:

• To manage all the central level, by choking any management or decentralized initiative,
• Nothing to put in coherence, between autonomous spaces which do not respect any constraint.

Very often, exchanges, either completely centralized, or completely decentralized, are imperfect: they cause associations between components badly positioned, with perverse effects in the long term. For example centralization combines components of any azimuth. With unslung autonomy the inconsistencies are the rule.

Subsidiarity is declined on several axes (organisational, commercial, produced,…), requiring a comprehensive IS view of all the points of balance.

Management of subsidiarity makes it possible to fix the points of balance (for the data and the meta-data) and to create the parameters to make them evolve.

An eternal cleavage

The "city" of the components, to urbanize, is cleaved between:

• shared components, candidates with the public reference: recalling structures, identities, cycles, course,
• subsidiary components, fruits of private autonomy.

This division, copied on the value chains, is permanent. It transcends the so-called bimodal IT, the chapels of structured and of not structured model, the borders of the Company in dilution, the Internet of all things…

These 7 EA principles allows, through organisational or technical solutions, to simplify IS, to make it more economic, transformable by hybridization, and flexible device.

The urbanistic vision is essential, a realistic metaphor, allowing, in long term, to transform the IT heritage gradually, without Big Bang, or heavy methodology.

The principal effort is not any more to relate on the method miracle, or technological cleavage.

It is necessary to act, because, with interfunctionings per thousands, and exchanges intimate to IS, “laissez-faire” leads unrelentingly to the embolism.

It is necessary to put under control the interactions between the atoms of IS. One needs a “mediation” between components, applying these 7 principles. And to nip in the bud congenital complexity and rigidity.