EA: Maps & Territories

[Enterprise architects] “…are like sailors who have to rebuild their ship on the open sea, without ever being able to dismantle it in dry dock and reconstruct it from the best components.”

Otto Neurath

Synopsis

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.

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

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.

Walking Paths, Mapping Territories

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 manage changes in the former with regard to the latter.

Assuming that the proper distinctions are clearly established, tasks and responsibilities can be charted according to scope (enterprise or systems) and level (architecture or local).

Local assignments deal with business processes and operations and are therefore 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 deal with architectures and are therefore 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).

Maps & EA Governance

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

To begin with, instead of coercing external constructs and concerns on customary structures and practices, enterprise organization and systems (maps) could be progressively adjusted to actual territories and business opportunities.

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: