Ask ten architects what an architecture is and you’ll get twelve answers. I have always loved that joke. In some ways it makes me quite proud of us.
But it’s not a metaphor. And it isnt funny when it keeps us from being successful. I’ve run those conversations hundreds of times over 20 years, in surveys, workshops, certification reviews, and hiring panels. The profession has terminology. It doesn’t have an ontology. It has favorite techniques du jour, it doesn’t have consistent guides to proven techniques, all of which work together.
We are an argument by nature and given that Im one of us, an architect, I don’t mind that. But we do not succeed unless we succeed together. And to do that we have to deeply understand our shared language.
Terminology is words we use. Ontology is a formal definition of what those words mean, what they contain, how they relate to each other, and what rules govern all of it. Medicine has one. Law has one. Software engineering tried and failed with SWEBoK (and should try again).
Architecture has been faking it with frameworks that are really just classification systems and notation languages dressed up as something more.
TOGAF gives you a process and some artifact categories. It is unbelievably difficult to find out what something is and how to do it. Zachman gives you a classification matrix. ArchiMate gives you shapes and arrows. Arc42 is trying to give templates. The C4 model gives you another model notation for a number of viewpoints. None of them tells you what an architecture decision actually is at the data level. What fields does it contain? What other concepts must it reference? What relationships are enforced versus suggested? What is the cardinality between an ADR and an ASR, and the driver that justified both. Now multiply that times roughly 60 to 70 major concepts we are all supposed to know how to use like masters.
We’ve been practicing a profession without a shared model of what that profession means and what it produces.
What architects actually need to track
When I look at what fails on large programs, it’s not so much a technical problem, though those are still there. It’s mostly a coherence problem. The team can’t answer four questions simultaneously.
What is this architecture supposed to do? Not the requirements. The intent. The design drivers. The principles. The trace from an OKR or a strategic objective down to why a specific structural decision was made. The modern goals of SDD, CALM and others still suffer from this issue. Understanding and guiding Intent is the hardest part of our work.
What does it actually look like right now? The full picture. Functional decomposition, information model, deployment topology, security trust boundaries, concurrency model, integration contracts. All of it, in one coherent system.
Where is it drifting? Where has the realized system diverged from the designed one? What are the quality gates, the fitness functions, the decision records that would tell you?
Where is it going? Not a slide deck. An actual model of momentum. Lifecycle, roadmap, operational governance, the architectural evolution model.
Most frameworks handle one of these. Some handle two. None of them handle all four in a formally defined, internally consistent way.
That’s the gap the Structured Canvas Approach fills. And with the upcoming viewpoint library, we finally have the whole system.
What makes SCA different
The SCA starts with a question that most framework designers never asked. Not “how do we show architecture?” but “how do we define what an architecture is?”
The answer came back as a set of concepts that lead to understanding. These concepts can be defined clearly for a system and the system that controls its direction. Making that ontology work at scale is quite powerful.
CoDL defines what each architecture concept contains. Its fields, their types, which are required, what they reference, how many of each thing can exist. An architecture decision record isn’t just a document with some boxes. In CoDL it’s a concept with a defined data model, typed relationships to other concepts, and constraints you can actually enforce.
The SCA also has MCP, allowing us to use reasoning, LLMs, and other tools to integrate these concepts into our daily workflow.
This matters more than it sounds. It means a decision made in one tool can be traced and validated in another. It means the relationship between an ADR and an ASR is a real, queryable link, not a note in a text box somewhere. It means when someone asks “why did we make this decision and what requirement was it responding to?” the answer is a query, not a conversation.
And before you throw an architect tool in as an answer, remember every tool is a proprietary vendor framework. It is an attempt by a group of investors to capture our shared language into a profit-making engine. They are not non-profits driving a better profession. Don’t believe me? Compare the definitions used in the likes of Orbus, LeanIX and Mega. Try to move architecture between them… and pretty soon you will understand why one vendor CEO told me they had the profession trapped in their meta-model.
The viewpoint library closes the loop
On top of the SCA, we now have 16 viewpoints coming through review. Context, Functional, Information, Deployment, Security, Operational, Concurrency, Development, Integration, Performance, Sustainability, Operations Runtime, Reliability, Maintainability and Evolvability, Interaction Capability, Safety.
110 concerns across those viewpoints. Each concern has a canonical primary model, a set of architecturally significant requirements, decision records, anti-pattern warnings, and stakeholder alignment guidance. All grounded in the actual literature. Rozanski and Woods. Bass, Clements and Kazman. The SRE book. ISO 25010. The sources that the profession has actually used to produce good work.
The viewpoint library handles structure and variance. It tells you what the architecture looks like and what success looks like at every level of concern.
The Structured Canvas Library runs alongside it and handles intent and momentum. Business model canvases, OKR traceability, architecture driver models, principle cards, lifecycle planning. This is where you capture why the structure exists and where it’s going.
Two libraries. Neither subordinate to the other. Used together, they give you all four things: intent, structure, variance, momentum.
Why nothing else does this
I’m not dismissing the frameworks that came before. TOGAF solved real coordination problems for large organizations (it was primarily used as a contract management tool). ArchiMate gave us a shared notation across vendor tools and I still use it. C4 is also valuable as a notation. Those contributions mattered.
But they were built to solve documentation and communication problems. Not ontology problems.
And on large solution outcomes, that gap is not an inconvenience. It’s where programs go wrong. The capability built beautifully in the functional view but never reconciled with the deployment topology. The security architecture that exists in its own document and drifts from everything else with every sprint. The decision made 18 months ago that nobody can trace back to a rationale. The review that can’t reach alignment because there’s no shared definition of what the architecture actually says.
Those aren ontology failures.
We’ve spent 20 years hoping frameworks would get us there. Some got close. The BTABoK’s Structured Canvas Approach combined with the viewpoint library is the first system I know of that addresses intent, structure, variance, and momentum in a formally defined, traceable, machine-readable way.
That’s a strong claim. And together we can back it up.