“A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.”
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.
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.
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.
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
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.
That should be the role of functional architectures: mapping a 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):
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.
Allocating responsibilities with regard to maps (architects) and territories (managers) would bring practical benefits to enterprise governance.
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.
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.
- Thread: Enterprise Architecture
- EA: Work Units & Workflows
- Modeling Paradigm
- Where to Begin with EA
- Open Concepts Will Make You Free
- Projects Have to Lias
- Reflections for the Perplexed
- Open Concepts
- Agile Architectures: Plasticity meets Versatility
- Abstraction & Emerging Architectures
- UML’s Semantic Master Key, Lost & Found