[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
Preamble
Whereas enterprise architectures can be neatly defined in terms of maps and territories, that static description is pointless without its dynamic counterpart.
Enterprise architectures are a combination of culture, organization, and systems with a life of their own. As a consequence change cannot be carried out as if architectures were just apparel but it must ensure continuity, integrity, and consistency of supported activities. On that account phased processes with beginnings and ends are of limited use except for toddlers still without structured organization and activities; otherwise such processes will remain off-soil, detached from concrete implementation; instead one should look for agile and lean workflows. A case study illustrates the proposed approach.
EA as an Ongoing Multifaceted Venture
EA ventures should not be confused with engineering projects about replacing a legacy architecture by a new one. That may be the case for some individual features, but it would be misguided for EA as a whole, better understood as a roll-line factory engineering new components or re-engineering legacy ones.
That shift of paradigm is a key success factor as it does away with a discrete understanding of enterprise architectures and their transformation, in particular:
- Scope cannot be fully defined up-front, if only because the whole enterprise, including organization, could possibly be of concern.
- Fixed schedule is 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, but none with undisputed prerogatives.
So, instead of procedural and phased approaches which are supposed to start from scratch, EA ventures should come as a declarative framework purporting to the planning, monitoring, assessment, and adjustment of projects (business, organizational, technical) and time-frames (operational, tactical, strategic) across the enterprise.
Scope: Concepts, Artifacts, Capabilities
Maps and territories may provide an effective static EA description, but enterprises are dynamic entities trying to keep pace with their business environment, which means that maps and territories are supposed to be continuously updated and adjusted without impairing the enterprise competitiveness. The best way to achieve such architectural agility is to manage changes with regard to their footprint:
- Concepts are used to describe business contexts and objectives as well as enterprise organization.
- Artifacts (physical or digital) are used to design and implement systems functionalities.
- Capabilities are used to understand the relationships between enterprise objectives, organization, and systems.
Taking a leaf from the Zachman Framework, capabilities can be organized around five pillars supporting enterprise, systems, and platform architectures:
- Who: enterprise roles, system users, platform entry points.
- What: business objects, symbolic representations, objects implementation.
- How: business logic, system applications, software components.
- When: processes synchronization, communication architecture, communication mechanisms.
- Where: business sites, systems locations, platform resources.
These capabilities can be directly mapped with UML diagrams for classes (What), activities (Who and How), states and transitions (When), or objects (Who and Where).
Since the distinction between maps and territories is a critical aspect of change management, the “What” capabilities should be set apart due to their role as symbolic representation of business objects as well as architecture capabilities. That duality is made clear if representations are stereotyped with regard to targets: locations (e.g office), actors (e.g customer), processes (e.g invoicing) and associated business logic (e.g pricing), physical objects, passive (e.g inventory) or active (CCTV), events (e.g order) and symbolic business objects (e.g order).
That would put the focus on the primacy of information architecture capability (not to be confused with IT) and will help enterprise architects in defining changes in capabilities with regard to conceptual and functional blueprints.
Capabilities & Architecture Layers
Approaches to Enterprise architecture can be summarily epitomized by the Zachman’s framework and TOGAF: the former puts the focus on capabilities built on principled architectural concepts but haven’t much to say about associated processes; in contrast, the latter is focused on phased processes referring to vaguely defined views and artifacts.
So, while the Zachman’s framework isn’t of much help with processes, TOGAF’s Architecture Development Method (ADM) relies on top-down predefined procedures wherein agility should be a primary concern.
A way out of this dilemma is to define EA workflows bottom-up from Zachman’s architecture capabilities. Instead of numbered phases and generic activities, work units could be directly associated to architectural artifacts, which would greatly improve the transparency and traceability of changes across architecture layers:
- Business and organization: EA capabilities with regard to business environments and objectives.
- Systems and engineering: systems capabilities with regard to enterprise ones.
- Platforms and operations: platforms capabilities with regard to systems and enterprise ones.
Work Units & Workshops
Compared to top-down activity-based approaches, work units defined bottom-up (aka flow based) from capabilities bring a hands-on dimension to EA; that is to further the design of lean workflows by linking work units to systems engineering workshops and so crossing capabilities with architecture layers:
- Enterprise: offers a bird’s eye view of enterprises territories: business environment and objectives, organization, and sites.
- Operations: deal with processes, systems, platforms and resources.
- Domains: symbolic representations of architectures layers: computation independent, platform independent, and platform specific models.
- Applications: symbolic descriptions of business logic and systems functions and programs.
On that basis, enterprise architects should first look for homogeneous work units focused on single capabilities (e.g new business locations, organizational change). For heterogeneous changes affecting multiple capabilities (e.g new business), refactoring could be applied as to set apart a primary capability from secondary ones and so obtain self-contained work units.
It must be reminded that whereas the objective is to identify work units with regard to primary changes, such changes can be set at any level: business, system, or platform. The challenge is to identify dependencies and define work units in a way that will minimize disruptions to enterprise activities.
Business vs Engineering Dependencies
Enterprise architecture can be seen as a hub between two perspectives, external for business, internal for engineering and operations:
Each perspective gives rise to specific dependencies:
- External dependencies are synchronic as they take into account the alignment of capabilities with business contexts and objectives (a>b).
- Internal dependencies are diachronic as they deal with the engineering and deployment of artifacts and capabilities (a>c>d).
Contrary to traditional one-dimensional approaches which overlook the first perspective and focus on engineering, EA is first and foremost about the orchestration of changes between both perspectives; hence the importance of combining marshaling mechanisms.
Engineering Backlogs
As noted above, business, engineering, and operational processes may cut across enterprise, systems, and platforms. As a corollary, changes in architecture capabilities can originate at any layer, and external (aka business driven) dependencies could be directly tied to systems or operational capabilities, e.g:
- Impact of new users’ stories or use cases will be first defined for organization, interfaces, and business logic (enterprise capabilities).
- Impact of new middle-ware will be first defined for functional architecture (systems capabilities).
- Impact of new locations will be defined for resources deployment (platforms capabilities).
Coercing external dependencies (and associated cross-engineering ones) into phased tasks and schedules could arguably induce cumbersome planning, crippling effects, and unjustified overheads. Instead that could be avoided with work units defined bottom-up from capabilities, with business and engineering dependencies to be managed using backlogs and declarative constraints assessed dynamically.
Scaling agile principles to EA workflows would deliver two critical benefits:
- External (business) and internal (engineering and operations) changes and dependencies could be managed distinctly yet through a common and smooth decision-making mechanism.
- Delivery (from engineering) and operational deployment (for business processes) could be set separately, enabling dynamic planning of architecture changes.
In theory that could be achieved with some kind of differentiated backlogs as figured above; in practice it would be easier to distinguish between responsibilities and combine engineering backlogs with a more distributed scheme for business and enterprise dependencies.
EA Workflows & Roundabouts
If EA is to operate as a hub between business and engineering processes, workflows must be carried out seamlessly and continuously. Regarding engineering projects, the agile development model can be taken as the default option providing conditions regarding shared ownership and continuous delivery can be met. That may not be possible for EA projects which by nature encompass shared architecture features involving multiple stakeholders. On that account, roundabouts appear as a good complement to backlogs.
Traffic roundabouts are circular intersections where vehicles travel counterclockwise around a center island without the help of any traffic lights. Drivers yield at entry to traffic then enter and turn around at will until picking their exit according to destination.
Applied to EA, roundabouts would be tasked with the synchronization of projects across the enterprise, with vehicles representing work units, and exits pointing to architecture layers: enterprise, systems, or platforms.
Along that understanding, the life-cycle of work units would follow three stages:
- Before roundabout: engineering (inception, refactoring, development) is carried out by self-contained projects until business dependencies have to be taken into account and quality conditions are met.
- Within roundabout: once given access, work units are developed in sync taking all dependencies into account.
- After roundabout: exits (aka deliveries) are conditioned by acceptance but don’t necessarily coincide with immediate deployment.
Roundabouts are used to manage work units insofar as their visibility is necessary at enterprise level; as a corollary:
- Roundabouts are meant to serve territories wherever and whenever needed; they can be temporary or permanent, specific (organization, systems, platforms), or set across architectures.
- The visibility of work units is limited to their architecture footprint; and given that exit conditions are set with regard to architecture layers (enterprise, systems, or platforms), work units must enter roundabouts with single destination.
Besides organizational, functional, and technical dependencies set at enterprise level, roundabouts are also used to synchronize EA workflows with regard to time-frames.
EA Workflows & Time-frames
If EA is to ensure the continuity, consistency, and efficiency of enterprise activities, workflows have to smooth disruptions by tallying changes with enterprise core time-frames:
- Strategic changes affect business objectives and enterprise assets; they necessarily encompass multiple production cycles (a).
- Tactical changes affect artifacts, logical or physical; they can be aligned with production cycles (b).
- Operational changes affect the deployment of resources, logical or physical; they can be carried out within production cycles (c).
It must be noted that time-frames are not necessarily aligned with architecture level, as illustrated by the impact of communication architectures on enterprise and business capabilities. See EA: Legacy & Latency for a more detailed analysis.
EA Workflows & Framework
Assuming that the primary objective of EA is to harness enterprise architectures, strategies, and governance, EA workflows must be anchored to maps and territories. That can be done through the association of work units to workshops.
The business side of EA workflows is tasked with the mapping of contexts and objectives (territories>maps) and the monitoring of their deployment by operational units (territories>territories).
The engineering side of EA workflows is tasked with monitoring the development of applications (maps>maps) and their delivery to operational units (maps>territories).
Both sides are carried out iteratively, combining four operations at work units level:
- Update the maps of current and planned architectures; create work units (1).
- Review the status of work units and carry out with impact analysis; manage entries in roundabout (2).
- Manage roundabout and exits of work units (3).
- Carry out changes in territories (4) and update corresponding maps.
Taking a leaf from the agile model of development:
- These operations are carried out through the collaboration between managers, analysts, and architects.
- Time-boxes are set with regard to enterprise specific time-frames.
- Work units are continuously delivered according to relevant time-frames.
Scaling up agile principles so provides a comprehensive, consistent, and effective solution to the core EA challenge, namely how to ensure architectures changes without impairing enterprise effectiveness.
Case Study
A case study has been developed with OWL and the Caminao Ontological Kernel.
Further Reading
- Case study
- Case Study with Ontology
- Thread: EA
- Enterprise Architectures & Separation of Concerns
- Where to Begin with EA
- EA: Maps & Territories
- EA: Legacy & Latency
- Caminao & CMMI
- Models Transformation & Agile Development
- Modernization & The Archaeology of Software
- Agile Architectures: Versatility meets Plasticity
- Agile & Dynamic Programming.
- Abstraction Based Systems Engineering
- Caminao & EACOE
- EA & MDA
- Abstractions & Emerging Architectures
- Conceptual & Functional Blueprints