top of page
Get Started
Home
AI Disruption
The Software Industrial Complex
The Hype Cycle
Use Case Driven
Decision-Centric Architecture
AI Off-The-Shelf Software
Declarative + Generative AI
The Software Factory
HyperAgility
Disintermediation
Introducing HyperAgility
Certification
The Advisor AI Platform
Use Cases
Advisor :: Architect
Advisor :: Metrics
Advisor :: Transform
AI-Native SWE Catalyst
Blog
Connect
More
Use tab to navigate through the menu items.
Decision-centric Architecture (DCA)
The well established definition of software architecture is described as
"the significant design decisions about the components, their interactions, and the forces and styles that guide these components and interactions"
. At the heart of this definition is the notion of design decisions - meaning that a software architecture is first and foremost about the reasoning process for such high stakes (or not easily undone) decisions.
In the past, design decisions have not been the center of attention for solution architectures. Rather, with CASE 1.0 (Computer-aided Software Engineering) emphasis was heavily geared towards visualization and modelling. The UML and associated toolsets were focused on a translation between various graphical views and loosely coupled to the language of software code-bases.
Hence, modelling for the sake of modelling was a thing, and Model-driven Development became its own paradigm with an associated echo chamber. But software architecture has always been about risk mitigation. Bad things can happen with either non-discretionary or life-critical systems when poor reasoning about technology choices occurs.
This is where the new paradigm of CASE 2.0 comes in - a focus on the central purpose of architecture, with automation, semantic translation and generative AI enabling tight feedback loops focused on risk related to fitness-for-purpose and "merchantable quality".
Decision-centric Architecture represents one of the three pillars within the Decision-centric Capability Improvement (DCCI) paradigm. As an empirical strategy for improving software-intensive system outcomes, we seek to arrive at causality and reuse of proven experience by correlating empirical data to our teams self-organization of technology, practice and staffing choices. Rather than prescribing sets of technologies and practices on teams within highly biased practice-set or technology boundaries, our approach enables choice across the entire spectrum of software development experience.
To ensure causality emerges, all first-order types of decisions that are made within the environment of uncertainty are captured. These also run the risk of bias are captured to provide a holistic view of the ecosystem. This allows for objective observations to be provided to the broader organization regarding efficacy, thereby enhancing credibility when it comes to providing forward looking advice.
Learn More
bottom of page