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

Architecture layers

Enterprise architectures are meant to evolve in line with business objectives, organization, and technologies. Assuming that changes are to be carried out step by step without impairing enterprise performances, some modeling bridge is necessary between enterprise organization and processes and supporting systems; that’s the role of functional architectures

Functional architectures as a level of indirection

But enterprise architects are not directly concerned by the details of business processes or software designs and their focus must be on the alignment between existing as well a planned business objectives and systems capabilities.

The role of functional architectures is to map conceptual models to systems capabilities

That can be best achieved with the Pagoda blueprint that brings together environments (territories), capabilities (systems) and representations (maps):

As befits to architecture blueprints, it puts the focus on systems functionalities: between business and digital environments on one hand, organization and operations on the other hand operations and organa conceptual description of enterprises organization business to systems capabilities

Functional Governance: Assignments

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.

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. On that basis 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.
  • Software engineers will use prescriptive models to design applications with regard to functional and technical architectures (b).

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.
  • Systems architects and software engineers will use prescriptive models to design and build technical architectures.

Engineering: Iterative & Model based

Like geographic ones, enterprise maps can be layered and used to align architecture layers with views and engineering workshops:

  • Territories workshop offers a bird’s eye view of enterprises: business environment and objectives, organization, and physical systems.
  • Operations workshop deal with processes and resources.
  • Maps are symbolic representations of architectures layers: computation independent, platform independent, and platform specific models.
  • Policies are symbolic descriptions of business logic and systems functions and applications.

Systems Engineering workshops and EA Pagoda blueprint

With regard to engineering, crossing maps and territories with enterprise architectures is to be decisive in solving two critical EA quandaries:

  • How to change architectures without affecting the continuity, integrity, and consistency of supported activities.
  • How to combine agile and model-based development models.

With regard to governance, allocating responsibilities for maps (architects) and territories (managers) would render turf disputes pointless, to be replaced by collaboration.

Operational Governance: Decision-making

The weaving of enterprise systems within networked business environment calls for a tightened integration of business processes and IT systems, bringing new challenges for enterprise architects. What is at stake can be illustrated with the OOAD (Observation, Orientation, Decision, Action) loop, a real-time decision-making paradigm originally developed by Colonel John Boyd for the pilots of USAF fighter jets:

  • Observation: operational processes must provide accurate and up-to-date analysis of business contexts as well as feedback.
  • Orientation: transparency of functional architecture is to support business positioning and the adjustment of business objectives.
  • Decision: versatility and plasticity of applications are to facilitate change of tactical options..
  • Action: integration of business, engineering, and operational processes are to ensure just-in-time business moves.

Not surprisingly, the integration of maps and territories can greatly enhance strategic and operational decision-making.

On account of the former (left), the focus is on knowledge management and business policies:

  • 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

On account of the latter (right), the focus is on the operational use of maps:

  • Data analytics: accurate and up-to-date observations supporting relevant orientation.
  • Decision-making: timely decisions and effective action.

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

External Links

%d bloggers like this: