How to present EA to Decision-makers

Preamble

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

Architecture is visual issue
Schemas should contain between 8 and 12 unrelated concepts.
Semantics should be non ambiguous and specific to the issue.

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.

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