“For things to remain the same, everything must change”
Lampedusa, “The Leopard”
Preamble
Whatever the understanding of the discipline, most EA schemes implicitly assume that enterprise architectures, like their physical cousins, can be built from blueprints. But they are not because enterprises have no “Pause” and “Reset” buttons: business cannot be put on stand-by and must be carried on while work is in progress.
Systems & Enterprises
Systems are variously defined as:
- “A regularly interacting or interdependent group of items forming a unified whole” (Merriam-Webster).
- “A set of connected things or devices that operate together” (Cambridge Dictionary).
- “A way of working, organizing, or doing something which follows a fixed plan or set of rules” (Collins Dictionary)
- “A collection of components organized to accomplish a specific function or set of functions” (TOGAF from ISO/IEC 42010:2007)
While differing in focus, most understandings mention items and rules, purpose, and the ability to interact; none explicitly mention social structures or interactions with humans. That suggests where the line should be drawn between systems and enterprises, and consequently between corresponding architectures.
Architectures & Changes
Enterprises are live social entities made of corporate culture, organization, and supporting systems; their ultimate purpose is to maintain their identity and integrity while interacting with environments. As a corollary, changes cannot be carried out as if architectures were just apparel, but must ensure the continuity and consistency of enterprises’ structures and behaviors.
That cannot be achieved by off-soil schemes made of blueprints and step-by-step processes detached from actual organization, systems, and processes. Instead, enterprise architectures must be grown bottom up from actual legacies whatever their nature: technical, functional, organizational, business, or cultural.
EA’s Legacy
Insofar as enterprise architectures are concerned, legacies are usually taken into account through one of three implicit assumptions:
No legacy assumptions ignore the issue, as if the case of start-ups could be generalized. These assumptions are logically flawed because enterprises without legacy are like embryos growing their own inherent architecture, and in that case there would be no need for architects.
En Bloc legacy assumptions take for granted that architectures as a whole could be replaced through some Big Bang operation without having a significant impact on business activities. These assumptions are empirically deceptive because, even limited to software architectures, Big Bang solutions cannot cope with the functional and generational heterogeneity of software components characterizing large organizations. Not to mention that enterprise architectures are much more that software and IT.
Piecemeal legacies can be seen as the default assumption, based on the belief that architectures can be re-factored or modernized step by step. While that assumption may be empirically valid, it may also miss the point: assuming that all legacies can be dealt with piecemeal rubs out the distinction pointed above between systems and enterprises.
So, the question remains of what is to be changed, and how ?
EA as a Work In Progress
As with leopard’s spots and identity, the first step would be to set apart what is to change (architectures) from what is to carry on (enterprise).
Maps and territories do provide an overview of spots’ arrangement, but they are static views of architectures, whereas enterprises are dynamic entities that rely on architectures to interact with their environment. So, for maps and territories to serve that purpose they should enable continuous updates and adjustments without impairing enterprises’ awareness and ability to compete.
That shift from system architecture to enterprise behavior implies that:
- The scope of changes cannot be fully defined up-front, if only because the whole enterprise, including its organization and business model, could possibly be of concern.
- Fixed schedules are to be avoided, lest each and every unit, business or otherwise, would have to be shackled into a web of hopeless reciprocal commitments.
- Different stakeholders may come as interested parties, some more equal than others, possibly with overlapped prerogatives.
So, instead of procedural and phased approaches supposed to start from blank pages, EA ventures must be carried out iteratively with the planning, monitoring, assessment, and adjustment of changes across enterprises’ businesses, organizations, and systems. That can be represented as an extension of the OODA (Observation, Orientation, Decision, Action) loop:
- Actual observations from operations (a)
- Data analysis with regard to architectures as currently documented (b).
- Changes in business processes (c).
- Changes in architectures (d).
Moreover, due to the generalization of digital flows between enterprises and their environment, decision-making processes used to be set along separate time-frames (operational, tactical, strategic, …), must now be weaved together along a common time-scale encompassing internal (symbolic) as well as external (actual) events.
It ensues that EA processes must not only be continuous, but they also must deal with latency constraints.
Changes & Latency
Architectures are by nature shared across organizational units (enterprise level) and business processes (system level). As a corollary, architecture changes are bound to introduce mismatches and frictions across business-specific applications. Hence the need of sorting out the factors affecting the alignment of maps and territories:
- Elapsed time between changes in territories and maps updates (a>b) depends on data analytics and operational architecture.
- Elapsed time between changes in maps and revised objectives (b>c) depends on business analysis and organization.
- Elapsed time between changes in objectives and their implementation (c>d) depends on engineering processes and systems architecture.
- Elapsed time between changes in systems and changes in territories (d>a) depends on applications deployment and technical architectures.
Latency constraints can then be associated with systems engineering tasks and workshops.
On that basis it’s possible to define four critical lags:
- Operational: data analytics can be impeded by delayed, partial, or inaccurate feedback from processes.
- Mapping: business analysis can be impeded by delays or discrepancies in data analytics.
- Engineering: development of applications can be impeded by delays or discrepancies in business analysis.
- Processes: deployment of business processes can be impeded by delays in the delivery of supporting applications.
These lags condition the whole of EA undertakings because legacy structures, mechanisms, and organizations are to be continuously morphed into architectures without introducing misrepresentations that would shackle activities and stray decision-making.
EA Latency & Augmented Reality
Insofar as architectural changes are concerned, discrepancies and frictions are rooted in latency, i.e the elapsed time between actual changes in territories and the updating of relevant maps.
As noted above, these lags have to be weighted according to time-frames, from operational days to strategic years, so that the different agents could be presented with the relevant and up-to-date views befitting to each context and concerns.
That could be achieved if enterprises architectures were presented through augmented reality technologies.
Compared to virtual reality (VR) which overlooks the whole issue of reality and operates only on similes and avatars, augmented reality (AR) brings together virtual and physical realms, operating on apparatuses that weaves actual substrates, observations, and interventions with made-up descriptive, predictive, or prescriptive layers.
On that basis, users would be presented with actual territories (EA legacy) augmented with maps and prospective territories.
Composition and dynamics of maps and territories (actual and prospective) could be set and edited appropriately, subject to latency constraints.
Further Reading
- Thread
- Where to Begin with EA
- EA: Maps & Territories
- Legacy Refactoring
- Modernization & The Archaeology of Software
- EA: Work Units & Workflows
- Focus: Enterprise Architect Booklet
- Emerging Architectures
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Caminao & DoDAF
- Models, Architectures, Perspectives (MAPs)
- Views, Models, & Architectures
- EA: The Matter of Layers
- Architecture Capabilities
- Feasibility & Capabilities
- Abstractions & Emerging Architectures
- Why Virtual Reality (VR) is Late
- Focus: Individuals in Models
- Agile Architectures: Versatility meets Plasticity
- A case study