Objective
As understood by Cybernetics (see Stafford Beer, “Diagnosing the System for Organizations“), enterprises are viable systems whose success depends on their capacity to countermand entropy, i.e the progressive downgrading of interactions both within the organization itself and with its environment. And that is what architectures are supposed to achieve.
The emergence of Enterprise Architecture as an autonomous discipline is the logical consequence of the ubiquity of IT across all enterprise assets and processes: as it becomes clear that IT is only a means to business ends, IT architecture has to be reset within the wider context of corporate assets and business processes.
Architectures
Whatever the nature of contexts, architectures can be defined as a structured collection of shared assets and mechanisms whose purpose is to support the sustainable activity of functional entities: houses for dwelling, factories for manufacturing processes, office buildings for administrative ones, human beings for living, etc. Enterprises combine at least two of those blueprints as they usually support operational and administrative processes on one hand, and have to keep their corporate self alive and kicking. Architectures must therefore support the continuity of corporate identities and business processes within regulatory and business environments. And that could not be achieved without information systems.
To be “viable”, enterprises have to monitor their state as well as their environment, and that puts information at the core of enterprise architecture; so much so that, given the ubiquity of information, some may argue that enterprise and information architectures coalesce into a single one. Some will even go further and blend enterprise architecture with the architecture of information systems.
Frameworks like Zachman or TOGAF may provide some guidance, the former for defining relevant artifacts, the latter for walking through the building steps. The Zachman Framework in particular, defines architecture artifacts across six tightly knitted layers set in a corporate context which may be identified with enterprise architecture. While those layers are still focused on information systems, they are organized around IT-independent pillars (Who, What, When, Where and How) which can be used to define architecture capabilities.
Who are the agents ?
Enterprises are meant to support operations, and that will determine the roles held by the active architecture components: human agents, devices, or information systems. Hence the need to identify corresponding organizational units (collective or individual) and the nature of responsibilities they may support:
- Authority: ability to decide how to perform processes and make commitments in the name of the enterprise. That can only be done by human agents, individually or collectively.
- Execution: ability to process physical or symbolic flows between the enterprise and its context. Any of those can be done by human agents, individually or collectively, or devices and software systems subject to compatibility qualifications.
- Control: ability to record and check the actual effects of processes execution. Any of those can be done by human agents, individually or collectively, some by software systems subject to qualifications, and none by devices.
It must be reminded that at this stage organizational units are any active component with the ability to perform a function within the enterprise. Some are identified at enterprise level and can be used to anchor the enterprise to its environment, others are identified locally, e.g within organizational units, unknown to external agents. Depending on business objectives and regulatory contexts, enterprise architecture must set apart agents whose identity and roles will have to be managed continuously and consistently at enterprise level.
What is to be managed ?
Enterprises are meant to deliver products and services and to that end they have to manage information about both their environment and themselves. As noted above, that’s clearly the case for information about identified agents and their relationships with the enterprise. Then the question will be to do the same for passive objects, actual or symbolic, setting apart those whose identity and features have to be continuously and consistently managed at enterprise level through their symbolic representation.
Depending on the nature of flows, physical (e.g wine) or symbolic (e.g menu), actual processing and its counterpart for symbolic representations can be performed independently or jointly. Enterprise architecture will have to match the capabilities of human agents, devices, and software systems with the processing of business flows, actual or symbolic.
Where are processes executed
Architectures must support interactions with the environment and collaboration between enterprise’s active constituents, wherever they are. If those constituents are grouped in the same location, situations can be assessed, resources accessed, and decisions carried out, all without mediation. That’s not always possible as operations and resources can be managed at different locations or set under different authorities. That will imply some mediation: interval of time during which external events may occur, additional operation to get access to resources, arbitrage between conflicting options, etc.
Enterprise architecture will have to ensure that location units and agents will support the distribution of activities and resources as well as the associated flows, collaborations, and timing requirements.
When are processes executed ?
Enterprises must keep tabs on relevant changes in contexts (aka external events). Depending on business concerns, some of those events will have to be dealt with immediately (aka in real-time) while others may be registered pending their processing. But that’s not the end of the story because external events may be the root of their own timescales, each triggering a cycle of execution states and derived events (aka internal).
Given the spatial distribution of activities and resources on one hand, the nature of flows on the other hand, the challenge is to identify execution units at enterprise level and define the communication channels and mechanisms supporting their synchronization.
How are processes executed ?
Processes are made of operations and rules, operations being execution instances of functional units. From an architecture point of view, functional units should be neatly defined according three basic conditions (inspired by Aristotle’s three unities):
- Unity of action: operations should have one main objective that they follow, with secondary ones, if any, set within circumscribed requirements and returning to the main ones after completion. In other words, agents in charge should constantly know about all dependencies.
- Unity of place: operations should be executed into a space within which all resources can be obtained directly and communication carried out without mediation.
- Unity of time: operations should be set within fixed and continuous time-frames. That is a necessity if innards and synchronization of operations are to be managed independently of context contingencies.
On that basis, it would be easier to characterize functional units depending on:
- The nature of changes they induce in the relationship between the enterprise and its environment: no change (reporting, sensor display), change in symbolic representations (billing, payment), change in actual contexts (preparing, pan cooking).
- The level of coupling associated with the operation: synchronous (sensor display, payment, pan cooking), or asynchronous (reporting, billing, preparing).
Rules for their part can be found everywhere and target everything. Moreover, as enterprises are driven by opportunities, rules are supposed to change as fast as business contexts. That seems the opposite of what architecture is about, namely focus, modularity, and continuity. Hence the importance of stereotyped rules defined according the effects and coupling of the operations they govern.
Architecture Capabilities
Enterprises thrive on adaptation to their environment, and architectures are arguably a primary factor of success. Yet, as for live organisms, architectures capabilities are balanced acts made of compromises depending on the specificity of ecosystems, objectives and constraints. Those trade-offs can be figured out by a pentagon linking core capabilities for locations, agents, functions, execution cycles, and symbolic representations.
While in principle capabilities requirements can be cross-examined from any perspective, two should be given precedence, one focused on operations, the other on support.
Business driven approaches (left) to capabilities will begin with use cases or users’ stories and then consider agents in charge (a), flows involved (b), locations for operations and flows (c), and execution states (d). Validation would then be performed for agents regarding locations (ac) and events (ad).
Domain driven approaches (right) to capabilities will begin with business objects to be represented (a): symbolic, agents, objects, or devices; life cycles are to be introduced for business objects associated with a finite set of discrete states (b). Then functional units using those objects will be considered (c), with validation of authorizations (ac) and synchronization (bc).
Complexity and Benchmarks
Contrary to business processes, the performances of enterprise architectures cannot be based upon resources and outcomes. Nonetheless, size and complexity can be assessed from capabilities, and benchmarks defined accordingly.
Assuming that size estimators can be directly derived from units, complexity can be assessed using cross capabilities, e.g:
- Real time representation (po): active objects managed in real-time.
- Coupled organizational units (ca): units participating synchronously in the same process.
- Distributed organizational units (da): units participating in the same process from different locations.
- Distributed processes (dp): processes executed across locations (time constraints, no shared flows).
- Distributed functions (df): functions executed across locations (shared flows, no time constraints).
- Cross authorizations (xa): overlapping access rights defined for objects and functions.
- Collaborations (xu): multiples roles participating in the same function.
- Shared objects (xo): multiples functions accessing the same representation units.
- Synchronized transactions (xt): multiples functions accessing the same representation units synchronously.
Complexity profiles can then be defined and used as benchmarks to assess architectures performances. They may also be used to assess business requirements and systems functionalities.
From Capabilities to Maturity
Enterprise architecture deals with assets and organization, business processes deal with resources and activities. While the artifacts used to describe them clearly overlap, they are set along two different perspectives, structural for the former, operational for the latter. More generally, enterprise architecture artifacts can be set at crossroads between structural (architectures) and operational (activities) concerns.
- Business processes have to know about business domains and activities on one hand, organization and applications on the other hand.
- System engineering has to know about projects, systems functionalities and, platform implementations.
- Services management has to know about locations and operations, services, and platform deployments.
And given that enterprise architectures are meant to support operational processes, their capabilities should also be mapped to processes maturity levels as defined by CMMI:
- Initial: Architecture capabilities are not considered.
- Managed: Architecture capabilities are considered for specific processes.
- Defined: Architecture capabilities are considered at enterprise level, independently of specific processes.
- Measured: Architecture capabilities are measured and controlled at enterprise level.
- Optimized: Architecture capabilities are assessed and improved at enterprise level.
Having them described in terms of agents, locations, events, activities, and objects, there should be no problem to map architecture capabilities to processes maturity.
Further Reading
- Architectures
- Model Driven Architecture
- Architecture Knowledge
- Architecture Capabilities and Requirements
Good point. The problem is that while definitions for systems and architectures generally point to some common understanding, there are still some blurred areas. That’s why I’m using unambiguous concepts for components (computers, people, devices) and capabilities (who, where, what, how, when), together with iconic representations.
The definition “a structured collection of shared assets and mechanisms whose purpose is to support the sustainable activity of functional entities” sounds like a definition of “system” as the term is commonly used. So if I understand well, “architecture” in this context is a synonym for system. Applying this definition to “architecture” seems to be a novelty: in common usage, an architecture is not identical to a system but rather has a relationship to a system: it means either a DESCRIPTION of a system (“the tribes had a collaborative rather than a hierarchical architecture”, “the application had a two-tier client-server architecture rather than three-tier”), or a METHOD (discipline) for designing a system.
Comments and corrections welcome.