How to present EA to Decision-makers


To be brief and to the point a presentation of enterprise architecture at decision-makers is to follow three principles:

  1. Architecture is visual issue
  2. Schemas should contain between 8 and 12 unrelated concepts.
  3. Semantics should be non ambiguous and specific to the issue. 
(Bridget Riley)

To that end, the focus should present architecture as an activity and its outcome. Applied to enterprise, architecture has to deal with more than actual edifices and contexts, and encompasses business environments and objectives on one side, organization, processes, and assets on the other side. Moreover, enterprise architecture is a continuous and dynamic endeavor because change and exchanges are part and parcel of enterprises life-cycle:

  • At enterprise level, architectures are needed to map organizations and systems to changing environments.
  • At system level, architectures are needed to map changing organizations and processes to supporting systems.

Enterprise architecture can therefore be defined in terms of the maps and territories (outcome), and the management of changes across and between (activity).

Mapping Territories

Compared to its bricks and mortar counterpart, enterprises architecture is a work in progress to be carried out all along enterprises life-cycle; hence the need of maps to figure out their environments, organization, assets, and processes:

  • At enterprise level maps are meant to describe business environments on one hand, concepts, objectives, organization and processes on the other hand.
  • At operational level maps are to describe physical and digital environments on one hand, interfaces and platforms on the other hand.

Then, a third level is introduced in between to describe systems and ensure transparency and consistency with regard to territories.

Enterprise Maps & Territories

For all intents and purposes that ternary view of enterprise architectures holds true independently of labels (layers, levels, tiers, etc), or perspective (business, data, applications, technologies, etc). That genericity appears clearly when maps are aligned with traditional models hierarchy: conceptual, logical and functional, and physical.

managing changes

Taking a leaf from Stafford Beer’s view of enterprises as viable systems, their sustainability depends on a continuous and timely adaptation to their environment; that cannot be achieved without a dynamic alignment of maps and territories; hence the need for enterprise architectures to provide for:

  • Continuous and consistent attachments between identified elements in maps and territories.
  • Transparency and traceability of changes across maps and territories.

Regarding continuity, ill-famed Waterfall epitomizes the detached conception of systems engineering and its implicit assumption that requirements are enough to ensure the alignment of systems with their business environments. To be sure, the plights of Waterfall have already marked a significant rip in the detached paradigm, a rift partially patched by agile development models. But while agile, and more generally iterative schemes, are at their best for business driven application with well defined scope and ownership, they fall short for architecture oriented ones with overlapping footprint and distributed stakeholders; that’s when maps are required.

Regarding transparency, enterprise architecture misconceptions come from mirroring its physical cousin, using geometrical patterns without being specific about their constitutive elements, and consequently the dynamics of interactions.

As it happens, both flaws can be mended by generalizing to systems the well accepted view model of software architecture:

  • Logical view: design of software artifacts.
  • Process view: captures the concurrency and synchronization aspects.
  • Physical view: describes the mapping(s) of software artifacts onto hardware.
  • Development view: describes the static organization of software artifacts in development environments.

One that basis changes in systems architectures would be managed in four workshops, two focused on territories (enterprise and operations) and two on maps (domains and applications).

Systems Engineering Workshops

Defining engineering workflows in terms of maps and territories is to provide the foundations of model based systems engineering.


Frameworks: How to Avoid Quagmires


Deciding upon a framework is a choice that bears upon a wide range of enterprise activities and may induce profound transformations in organization and systems. It ensues that the outcome is practically settled at the outset: once on a wrong path the only option is often to cut the losses as soon as possible.

When the first step settles the issue for the whole journey (Gianni Motti)

As it happens, there is no reason to hurry and every reason to take the time before opting for a long-term and comprehensive commitment.

Taking five, simple litmus tests can be used to avert overhasty moves into quagmires. Compared to a comprehensive assessment, the objective would only be to establish a shortlist of frameworks worth of a further assessment. For that purpose forms (but not substance) are to be considered for the consistency of definitions, the specificity of value propositions, and the reliability of roadmaps.

Consistency of Definitions

Frameworks come with glossaries covering generic, specific, and standard terms in various proportions; the soundness of these glossaries can be assessed independently of their meanings.

For that purpose simple metrics can be applied to a sample of definitions of core concepts, (e.g: agent, role, actor, event, object, activity, process, device, system, architecture, enterprise):

  • Self-contained: terms directly and fully defined, i.e without referring to other glossary terms (c,a,m).
  • Number of references used.
  • Circular references: terms including at least one path to itself (d,e,f)
  • Average length of non-circular references
  • Overlaps (i and j)
  • Conflicts (w by (x><e)

Basic definitions graph (x contradict e)

Even computed on small samples (10 to 50), these metrics should be enough to provide a sound yardstick.

Value Proposition Specifics

Pledges about meeting stakeholder needs, holistic undertaking, or enhanced agility are part and parcel of every pitch; but as declarations of intent they give little information about frameworks.

To be given consideration a framework should also be specific about its value proposition, in particular with regard to its description of enterprise architecture and systems engineering processes.

Assuming that the specificity of a value proposition equals the likelihood of a contrary stance (no framework would purport ignoring business needs or being non agile), general commitments must be supported by schemes meant to make a difference.

Roadmap Reliability

Given what is at stake, adopting a framework should only be considered if it can significantly reduce uncertainty. On that account road-maps built from pre-defined activities are deceptive as they rely on the implicit assumption that things will always be as they are meant to be. So, taking for granted that positive outcomes can never be guaranteed independently of circumstances, a framework reliability is to be assessed through its governance apparatus.

Along that reasoning, key stages, steps, or activities defined by a roadmap should be framed into a clear decision-making processes, e.g the observation, orientation, decision, action (OODA) loop.

A framework reliability could then be judged by its ability to support enterprise architects in assessing situations and picking a course of action.

Further Reading