EA: Maps & Territories

“A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.”

Alfred Korzybski


Enterprise architecture can be defined in terms of territories and maps, the former materialized by the realities of enterprise organization and business operations, the latter by the assortment of charts, blueprints, or models used to describe enterprise organization, business processes, IT systems, and software applications.

Navajo Sand Painting can be seen as a nexus of maps and territories.

Navajo Sand Painting can be seen as a nexus of maps and territories.

That understanding could help to clarify EA assignments, with architects in charge of maps, and managers of territories. But first and foremost, the distinction between maps and territories is to ensure that EA workflows can be carried out without impairing enterprise performances.

Systems & Models

As already explained, models used to describe systems are best organized according to their purpose:

  • Descriptive models tried to capture relevant aspects of actual things or behaviors.
  • Prescriptive models describe how to build things or carry out behaviors.
Business analyst figure maps from territories, software architects create territories from maps

Business analyst figure maps from territories, software architects create territories from maps

As far as enterprises are concerned, descriptive models are meant to provide serviceable representations of business environment; such models are said extensional as their objective is to classify observed occurrences of things and behaviors (aka extensions) into relevant categories. Predictive models can be seen as an executable subset of descriptive ones designed to foretell what could happen to selected aspects of actual things or behaviors. Considering that environments are given but relevant categories are defined according to enterprise concerns, these models are built along a nominalist perspective, i.e from territories to maps.

Prescriptive models go the other way as their purpose is to build systems’ components; corresponding models are intensional as they have to fully describe intended artifacts (aka intensions). Since concepts are being used as blueprints directed at concrete realizations, prescriptive models are set along a platonic perspective, i.e from maps to territories.

Assuming that the main purpose of enterprise architects is to manage the operational and strategic alignment of business objectives with architectures capabilities, the map/territory paradigm will provide the conceptual workbench on which to shape descriptive (business processes) and prescriptive (system architectures) models.

Architecture Maps & Enterprise Territories

Enterprises are by nature competitive entities whose success depends on balancing conflicting objectives with regard to moving targets. That’s especially the case for enterprise governance tasked with the pairing of business expectations with systems capabilities.

Along with the map/territory paradigm, enterprise architects’ job description comes with critical provisos:

  • Maps are works in constant progress: they have to simultaneously drive and reflect changes in territories; frozen maps would be detrimental to enterprise success, if not deadly altogether.
  • Territories know no fallow gaps: maps will have to be updated while being in use, which means that planning will be a primary factor for EAs.
  • Planning must be carried out along different time-scales: strategic, tactical, and operational; and for different realms: actual for business environments and system components, symbolic for functional and technical architectures.

These provisos can be neatly organized by crossing territories (actual business contexts and processes) with maps (descriptive or prescriptive models):

Models are maps of actual business and systems actual territories

EA assignments could then be defined along two dimensions:

  • Mapping of actual and symbolic descriptions: business context and objects on one hand, business processes and logic on the other hand.
  • Between architectures and processes: business operations on one hand, systems applications on the other hand.

Handling and shaping concrete operations and symbolic artifacts under the pressure of dynamic environments is arguably a very challenging endeavor. Framing it in terms of maps and territories could help in defining tasks and assigning responsibilities.

Functional Governance: Assignments

As illustrated by UML’s muddled treatment of individuals and qualifiers, overlooking the distinction between concrete individuals and symbolic categories is bound to put any modeling endeavor into quicksand. That is to be especially harmful for enterprise architects given that, compared to their IT counterparts, their main challenge is to align changes in business operations and supporting systems.

Assuming that the distinction between maps and territories is properly understood, tasks and responsibilities can be charted according to scope (enterprise or systems) and level (architecture or local).

Local assignments are to deal with business processes and operations and therefore be defined by territories, with models added for adjustments to enterprise architectures:

  • Business analysts will use descriptive models to position business processes with regard to business domains and enterprise organization (a).
  • Software engineers will use prescriptive models to design applications with regard to functional and technical architectures (b).
Business analyst (a) and enterprise architects (b) figure maps from territories, software engineers (b) and system architects (d) create territories from maps.

Business analyst (a) and enterprise architects (b) figure maps from territories, software engineers (b) and system architects (d) create territories from maps.

Global assignments are to deal with architectures and therefore be defined in terms of models:

  • Enterprise and systems architects will use descriptive models to chart business domains, enterprise organization, and functional architectures (c).
  • Systems architects and software engineers will use prescriptive models to design and build technical architectures (d).

Allocating responsibilities with regard to maps (architects) and territories (managers) would bring practical benefits to enterprise governance.

Operational Governance: Decision-making

Assuming that the dynamic alignment of enterprise assets (architectures) with business objective (processes) is a primary objective of enterprise governance, the distinction between maps and territories can greatly enhance decision-making. That can be illustrated using the OOAD (Observation, Orientation, Decision, Action) paradigm, with observations and actions associated with territories, and orientations and decisions supported by maps.

The architecture perspective (left) covers the definition of maps and territories:

  • How to best represent contexts and situation (orientation) and alternative actions (decision).
  • How to organize processes as to optimize the coupling between actions and observations.
Business Agility: systems architectures and business operations

Business Agility: systems architectures and business operations

The operational perspective (right) covers the dynamic alignment of maps:

  • Data analytics: observations and orientation.
  • Decision-making: decision and action.

Dynamic governance schemes like OODA bring critical competitive advantage in networked business environments by ensuring real-time integration between operations and supporting systems. And that can be achieved through a continuous and smooth adjustment of enterprise organization and systems functionalities (maps) to actual business processes and opportunities (territories).

More generally, and taking a leaf from geographers, the maps supporting EA could be layered according to assets, concerns, and responsibilities, or whatever criteria befitting existing and planned organization.

Further Readings


%d bloggers like this: