[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
Objective
Modeling is all too often a flight for abstraction when analysts should instead get their bearings and look for the proper level of representation, i.e the one best fitting their concerns. As a consequence, many debates that seem baffling when revolving around abstraction levels may suddenly clear up when reset in terms of artifacts and symbolic representations.
That is especially the case for enterprise architectures which, contrary to system ones, cannot be reduced to planned designs but seem to emerge from a mix of cultural sediments, economic factors, technology constraints, and strategic planning.
Hence the need to understand the relationships between enterprise contexts, organization and processes on one hand, and their symbolic counterparts in systems on the other hand.
Artifacts & Models
When architectures are considered, a distinction should first be made between artifacts (e.g buildings) and models (blueprints), the former being manufactured objects designed and built on purpose, the latter symbolic artifacts reflecting those purposes and how to meet them.
That distinction between artifacts and symbolic descriptions is easy to make for physical objects built on plans, less so for symbolic objects which are artifacts of their own and as such are begot from symbolic descriptions. In other words symbolic artifacts crop up as designs as well as final products.
Moreover, artifacts being used in contexts, their description must also include modus operandi. For enterprises that would mean business objectives, organization, and processes.
Two kinds of models can be used to figure out actual contexts and activities with their symbolic counterpart in enterprise systems:
- Models of business contexts and processes are descriptive as their aim is to build categories of actual or planned objects, assets, and activities.
- Models of systems and software are prescriptive as their aim is to design and build the symbolic artifacts used by systems to represent business objects and processes.
That distinction can lend support to the main challenge of enterprise architects, namely the seamless and dynamic alignment of enterprise objectives, assets, and organization on one hand, supporting systems on the other hand.
Architecture & Design
Architecture and design may have a number of overlapping features yet they clearly differ with regard to software: contrary to architecture, software design is meant to fully describe how to implement system components. That difference is especially meaningful for enterprise architecture:
- At enterprise level models are used to describe objects and activities from a business perspective, independently of their representation by system components. Whatever the nature of targeted objects and activities (physical or symbolic, current or planned), models are meant to describe business units (actual or required) identified and managed at enterprise level.
- At system level models are used to describe software components. Given that systems are meant to represent business contexts and support business processes, their architecture has to be aligned on the units managed at enterprise level.
Assuming that functional, persistency, and execution units must be uniquely and consistently identified at both enterprise and systems level, their respective models have to share some common infrastructure.
The overlapping of models with regard to enterprise and systems architectures and their yoking into systems design determine the background of architectures transformations.
Abstractions and Changes
If some continuity is to be maintained across architectures mutations, modeling abstractions are needed to frame and consolidate changes at both enterprise and system levels.
From the enterprise standpoint the primary factor is the continuity and consistency of corporate identity and activities. For that purpose abstractions will have to target functional, persistency, and execution units. Definitions of those abstract units will provide the backbone of enterprise architecture (a). That backbone can then be independently fleshed out with features providing identified structures of objects and activities are not affected (b).
From the systems standpoint the objective is the alignment of system and enterprise units on one hand, the effectiveness of technical architecture on the other hand. For that purpose abstract architecture units (reflecting enterprise units) are mapped to system units (c), whose design will be carried on independently (d).
That should determine the right level of abstraction, namely when corresponding abstract units can be used to align enterprise and systems ones.
Once securely locked to a common architecture backbone, enterprise and system models can be expanded according to their respective concerns, business and organization for the former, technology and platforms implementation for the latter. On that basis primary changes can be analyzed in terms of specialization and extension.
Specialization will change the local features of enterprise or systems units without affecting their identification or semantics at architecture level:
- With regard to enterprise, entry points (a1), features (a2), business rules (a3), and control rules (a4) will be added, modified or removed.
- With regard to systems, designs will be modified or new ones introduced in response to changes in enterprise or technological environments.
Contrary to specialization, architecture extension changes enterprise or systems units in ways affecting their identification, semantics or implementation at architecture level:
- With regard to enterprise, entry points locations (b1), semantic domains (b2), business applications (b3), and processes (b4) will be added, modified or removed
- With regard to systems, changes in platforms implementations following new technologies or operational requirements.
Hence, while specialization will not affect the architecture backbone, that’s not the case for extension. More critically, the impact of extensions may not be limited to basic changes to backbones as inheritance may also affect the identification mechanisms and semantics of existing units. That happens when abstract descriptions are introduced for aspects that cannot be identified on their own but only when associated to some identified object or behavior.
That can be illustrated by a banking example of a transition from account-based to customer-based management:
- To begin with, let’s assume a single process for accounts, with customers represented as aspects of accounts.
- Then, in order to support customers relationship management, customers become entities of their own, identified independently of accounts.
- Finally, roles and types are introduced as abstract descriptions (not identified on their own) in order to characterize actual parties (customer, supplier, etc) and accounts (current, savings, insurance, etc).
That modeling shift from concrete to abstract descriptions can be seen as the hinge connecting changes in systems and enterprise architectures.
Eppur si muove
As enterprises grow and extend, architectures become more complex and have to be supported by symbolic representations of whatever is needed for their management: assets, roles, activities, mechanisms, etc. As a consequence, models of enterprise architectures have to deal with two kinds of targets, actual assets and processes on one hand, their symbolic representation as system objects on the other hand.
This apparent symmetry can be misleading as the former models are meant to reflect a reality but the latter ones are used to produce one. In other words there is no guarantee that their alignment can be comprehensively and continuously maintained. Yet, as Galileo purportedly once said of the Earth circling the Sun despite models of the contrary, it moves. So, what are the primary factors behind moves in enterprise architectures ?
Assuming that enterprise architecture entails some kind of documentation, changes in actual contexts will induce new representations of objects and processes. At this point, the corresponding changes in models directly reflect actual changes, but the reverse isn’t true. For that to happen, i.e for business objects and processes being drawn from models, the bonds between actual and symbolic descriptions have to be loosened, giving some latitude for the latter to be modified independently of their actual counterpart. As noted above, specialization will do that for local features, but for changes to architecture units being carried on from models, abstractions are a prerequisite.
Emerging Architectures and Grey Matter
As already noted, actual-oriented models describe instances of business objects and processes, while symbolic-oriented ones describe representations, both at instances level (aka concrete descriptions) and types level (aka abstract descriptions). As a corollary, changes in actual-oriented models directly reflect changes in contexts and processes (a); that’s not necessarily the case for symbolic-oriented models which can also take into account intended changes (b) to be translated into concrete targets descriptions at a later stage (c).
Obviously the room left for conjured up architectural changes is bounded by deterministic factors; nonetheless, thought up new functional features are bound to appear first, if at all, as abstract descriptions, and that’s where emerging architectures are best to be observed.
At that tipping point, and assuming a comprehensive understanding of objective factors (business logic, data structures, operational constraints, etc), the influence of non deterministic factors upon emerging architectures can be probed from two directions: pushing from the past or pulling from the future.
The past will make its mark through existing organizational structures and roles. Knowledge, power bases, and habits are much less pliable than processes and systems. When forced to change they are bound to bend the options, and not necessarily through informed decision making.
Conversely, the assessment of future events, non deterministic by nature, is the result of decision making processes mixing explicit rationale with more obscure collective biases. Those collective leanings will often leave their mark on the way changes in contexts are anticipated, risks weighted, and business objectives defined.
Those non deterministic influences are rooted in some enterprise psyche that steer individual behaviors and collective decisions. Like the hypothetical dark matter conjectured by astronomers in order to explain the mass of the universe, that grey matter of corporate entities is the shadow counterpart of actual systems, necessary to explain their position with regard to enterprises contexts, objectives, and organization.
Emerging Architectures as Systems Epigenetics
Epigenetics can be used as a metaphor to illustrate the relationships between enterprise architectures and environments.
To begin with, enterprises are compared to organisms, systems to organs and cells, and models (including source) to genome coded with the DNA.
According to classical genetics, phenotypes (actual forms and capabilities of organisms) inherit through the copy of genotypes and changes between generations can only be carried out through changes in genotypes. Applied to systems, it would entail that changes can only happen after being programmed into the applications supporting enterprise organization and business processes.
The Extended Evolutionary Synthesis considers the impact of non coded (aka epigenetic) factors on the transmission of the genotype between generations. Applying the same principles to systems would introduce new mechanisms:
- Enterprise organization and use of systems could be adjusted to changes in environments prior to changes in coded applications.
- Enterprise architects could assess those changes, plan systems evolution, and use abstractions consolidate new designs with legacy applications.
- Models would be transformed accordingly.
As for genetics, that understanding of enterprise architectures would put the onus of change on the cells, in that case the plasticity and versatility of applications
Further Reading
- Architecture Knowledge
- Architecture Capabilities
- Objects with Attitudes
- Specialization vs Generalization
- Enterprise Architecture & Separation of Concerns
- Models, Architectures, Perspectives (MAPs)
- Enterprise Governance & Knowledge
- From Processes to Services
- EA & MDA
- Agile Architectures