Quantitative Enterprise Architecture

Driving Architecture using Data

Posted by steve on June 09, 2020
Enterprise Lineage | Pathwise Complexity | Data Input Validation

Background

Much has been written about Quantitative Enterprise Architecture, largely starting with the Capability Maturity Model from the US Software Engineering Institute in the 1980’s through Six-Sigma process optimisation through to structured systems testing across a range of business capabilities. The challenge of CMMi level-3 (processes are defined and being followed) is that the assesment is subjective. CMMi Level-4 introduces the capability to capture metrics from the development process, while CMMi Level-5 introduces the capability to use the metrics to improve the development process.

Togaf and Zachman provide frameworks that extenuate the need to consider architecture early with a focus on the principle that addressing risk early reduces overall cost, providing evidence of progress at the early stages of a project.

Model Driven Architecture

MDA was driven as a mechanism to add value to architecture activities, with the observation

  1. That requirements coverage and scope management can be quantitatively measured if there is a maintained trace relationship between the requirements and deliverable
  2. That the net-value of specification can go from positive to negative if the document is misleading because it is wrong
  3. That database design rigour and principles accrue value when applied to system behaviour
  4. That much code is boilerplate where the same concept needs to be applied to database, classes, interfaces and the different abstractions needed at different levels of an architecture
  5. That most integration test failings are due to mismatches in the implementations at component boundaries.

The big driver for MDA were

  • Inability to represent EJB interfaces as normal class diagrams (an enterprise bean does not directly implement is interface, but relies on the EJB container to provide glue)
  • Limitation of the Unified Modelling Language (UML) that many abstractions (e.g. ternary associations) can not be mapped to code

MDA is most commonly manifested as model transformations (PIM to PSM) and code generations

Architecture Compliance

Past Malfeasance has lead regulators to demand that institutions demonstrate evidence of data-sourcing to ensure that all systems are covered with consistent pricing sources and that mandated regulator processes are being performed.

In the absents of an established Enterprise Architecture various point-solution databases are developed

Quantitative Enterprise Architecture

Combining CMMi, MDA and Architecture Compliance introduces the network effect that information combined into an Architecture Repository than can meet multiple needs from a single source, but two issues become apparent:

  • Different models progress at different rates, and becomes difficult to coordinate manually
  • The “forest and trees” pattern emerges where a mass of detail obscures the areas that need focus

The approach taken with Enterprise Hub is to consolidate information from different domain sources, and then use automated metric to prioritize areas for detailed analysis. The metrics that are important change over time, so flexible frameworks and tools are needed for rapid evolution; Enterprise Hub provides a runtime environment and two frameworks for Analysts/Developers:

  • Workflow Foundation - process oriented workflow tool for business analysts to provide simple procedural tools
  • F# Script Foundation - code oriented tool for developers to provide complex (recursive) analysis. Functional languages like F# are ideally suited the to the analytical problems of graph/diagram interpretation because prevent the kind of sider effects that cause imperitaive programs to fail with highly recursive problems.

With each foundation, scripts are automatically executed within the Hub, resulting in metrics properties and issues being created that can feed into the review cycle for architecture work. The Enterprise Hub includes working samples that provided real-world solutions to common quantitative architecture problems:

  • Enterprise Lineage - Recursive derivation enterprise and data lineage as Lineage objects change and when scheduled.
  • Pathwise Complexity - Recursive Process complexity metrics, with property banding {high, normal, low} and issues (for high complexity)
  • Data Input Validation - Recursive search for process issues that cannot be identified with normal QA
  • ChangeStatus - XAML Workflow job to apply change-request status changes to the related items