Today’s Architecture Landscape is a series of complex relationships between
Business {Requirement, Capabilities, Process, Functions, Services, etc}.
Application {Use-Cases, Components, Services, Technologies, etc}.
Platforms {Servers, Databases, Queues, Providers, etc}.
Navigating between Business Goals and the change programmes to realise them is complex and requires detailed knowledge of the Architecture Meta-Model/Conventions, tools and stores. To facilitate navigation rigid standards are introduced to codify taxonomies and regulate interaction between them - resulting in complex governance.
Even when the meta-model has been carefully designed and standardised, conflicts often arise between different parts of an organisation that need to manage their responsibilities differently. Variants and Exceptions are then difficult to reconcile:
Sales and marketing focus on Services and Capabilities as the prime driver
Finance focus on Processes and Controls as the prime driver
Operations and Resources focus on Functions and Events as prime drivers
IT focus on requirements, technology and applications as the prime driver
Strategy and Enterprise Architecture focus on reconciling the differences and driving alignment, whilst avoiding bureaucracy
Summarising {process, function, technology, cost, effort} in terms of business goals is problematic, but assigning ownership/costs/escalation is equally problematic.
TOGAF
TOGAF is one of the many standards and tools that provide templates for capturing Architectures, but is rarely able to add value within the timescales of strategic change. Re-work is often needed when priorities change, and often difficult to keep all viewpoints current/accurate.
Without considering the merits and value of the TOGAF processes, few organisations are stable enough to tailor it to their current and future needs, or able to invest enough to realise the full value within strategic timescales.
A cost reduction driver will focus on function and ownership, improvement/optimisation will focus on processes, and strategic change will focus on capabilities and services. All of them need requirement traceability, resulting in:
Duplication and inconsistency where requirements are mapped and re-mapped at multiple levels, and different viewpoints.
Chasms open up where requirements are mismatched and/or deleted (non-function requirements are assigned directly to components for Service-Levels, and often omitted from business viewpoints).
Out-of-date views are deleted to avoid double-counting.
Butterfly paradigm
The Butterfly model takes its inspiration from the Butterfly Effect that changes to complex/adaptive systems can effect other parts of the system in unexpected ways. Rather than viewing it as the chaotic consequence of change, it can help understand impact.
The butterfly paradigm relates every entity to every other entity through intermediate connections along the path from start and finish. A Business Capability can be related to an Application via any appropriate path through {Process, Function, Service, Contract, other}. The actual intermediate entities, are not as significant as the implied relationship, the path length and extent of connections. Whether a (L1, L2, L3, L4) is related only effects the length of the path.
A Capability might be related to an L2 Function, while an application is related to a use-case that is related to a requirement that is related to two L4 functions (under L2) – the implied relationship has length 6 and extent 2.
The implied relationships are vastly more numerous than the individual connections, but within a finite system the total number of paths is also finite.
Ray Tracing
Computing the length and extend of paths between entities in an architecture model has historically been exorbitantly expensive, but the technique of Ray tracing highlights that it is now computationally possible. Photorealistic simulations and computer games use Ray tracing interactively to compute millions of paths a second.
Meta Model
The TOGAF meta model can be simplified as a map where paths connects every entity to every other entity.
Visualising Butterfly maps
Queries over Butterfly maps are always simple because the details that make up paths are hidden from view.
“Capability -> Capability_Application -> Application” is as simple as “Capability -> Capability_Location -> Location”, but the second query will include Data-Centres/Clouds (by hosting of applications).
When constraints are added to the paths “Cost of Application by Goals” can be queried by “Goal -> Goal_Function -> Function (budget holder) -> Function_Application -> Application” with cost distribution implied by Extend, discounted by length.
Simple queries lend themselves to graphical visualisation and ad-hoc what-if analysis
Butterfly Solution
Butterfly is feasible with powerful modern computers, but to be useful it needs to:
- Provide query integration with a range of data analysis/visualisation tools.
- Source data from a variety of governance sources.
- Source data from a variety of operational sources.
- Hold history over time.
- Reflect current changes, as insights lead to source updates.
- Allow Path definitions to be changed as priorities change without changing the data model.
- Allow synergies from different sources (e.g., EA Application Entity and CMDB Entity) to be recorded.
Implementation
OData provides a Web-API to surface data for modern Business Intelligence tools.
Canonical (graph node/edge) models allow for API integration with common tools for initial-load and event-driven update.
Ray-tracing GPU allow for changes to be fanned out to effected entities in real-time.
Tabular data allows commodity databases to be used for history.