Excerpt from Enterprise Architecture Fundamentals:
***
What Is Represented
Compared to brick-and-mortar architectures, which are tangible and perennial, enterprise architectures are works in progress to be carried out all along the life cycle of enterprises. Therefore, maps are needed to monitor external changes in business and technical environments and to ensure the traceability and consistency of their representation (or surrogates) in enterprises’ organizations and systems.
Whatever the doctrine, these primary objectives should determine the basic structure of blueprints:
- At the enterprise (or organizational) level, blueprints describe business environments, concepts, objectives, organization and processes.
- At the technical (or operational) level, blueprints describe physical and digital environments, systems interfaces, and platforms.
A third level between enterprise and technical ones describes systems and ensures the transparency and consistency of maps and territories between business and physical environments (figure 1-1).
Figure 1-1. Enterprise Architecture Overview
For all intents and purposes, that ternary view of architectures (enterprise, functional, technical) holds true independently of the labels used (e.g., layers, levels, tiers), or the perspective applied (e.g., business, data, applications, technologies). This tripartite understanding also aligns with the traditional hierarchy of models: conceptual and process, logical and functional, and physical or digital. More practically, the layered approach provides a robust framework for problem-solving:
- At the enterprise level, problems are defined by environments and objectives, and solved by organization and processes.
- At the (system) functional level, problems are defined by business processes and solved by functional architectures.
- At the (system) technical level, problems are defined by functional and operational requirements and solved by technical architecture, application design, and platform configurations.
That separation of concerns is critical because ensuring the consistency of changes across the corresponding layers with regard to environments (business or physical), nature (maps or territories), and time frame (external for environments, internal for enterprise) is at the core of enterprise architecture.
Current Shortcomings
While that layered representation often supports EA practices, at least implicitly, its significance is widely ignored. Practical and conceptual reasons for this misunderstanding point in the same direction: enterprise architectures are usually understood as an extension of systems architectures, with the same scope, objectives, and concepts. The ensuing myopia has two key consequences for enterprise architecture as a discipline:
- A double confusion, first, between environments and enterprise, and second, between maps and represented territories: environments, organization, and operations
- A blind eye to change as part and parcel of EA, and consequently to the importance of actionable maps
Attempts to find the foundations of enterprise architecture thus generally end with shallow representations or flights to abstraction:
- Shallow representations: colored arrays of boxes and arrows with generic labels are used to represent EA components and activities without being specific about architectures’ constitutive elements and their relationships.
- Flights to abstraction: generic descriptions are scaled up the abstraction ladder until they become detached from actual contexts and concerns, thus becoming irrelevant truisms.
These shortcomings can only be overcome with a modeling paradigm that weaves together enterprise architecture blueprints and processes.
***