I was reading something new yesterday that was giving an overview of SABSA from the perspective of someone who was enthusiastic about it, and was trying to do their part to raise the awareness of it and its merits among the wider world. I love it when people do this, because it helps the whole community.
Unfortunately, it’s basically the same intro we’ve all seen before. Here’s SABSA and here’s what the acronym stands for (which John Sherwood reminded us all again at COSAC and in the SABSA Open Forum that it’s now a word, not an acronym, and not the least of which is because of the trademark and licensing rules…). It’s fantastic. Not enough people know about it, and that it all revolves around the Matrix.
Which, we’ll… yeah, it does—kinda. It’s the primary analysis framework of the method, and everything does fit in there somewhere. But when we give people the impression that SABSA is the Matrix and the overlay – especially when mentioning how it’s related to (or worse, “leverages”) Zachman (which beyond having layers and columns and the happy happenstance what I once called “the meeting of the two Johns” really doesn’t share anything significant), we’re trying to take shortcuts that ultimately result in the worst evil of communication:
The making of assumptions.
Without getting into it more, combatting the evils of assumptions by building shared mental models are two of the foundational principles of The Agile Security System™, but that’s not my point today.
Today’s point is that will probably be somewhat contentious to you is that even if you use the two-way traceability and the “standard” multi-tiered attributes as a part of it (which they did), relying on the Matrix as your guide to applying SABSA is really only taking a small sip of the method, and it’s also a good way to get you in trouble, set false expectations with your colleagues and customers and trigger the “it’s big and waterfall-y” fears among the people you want to eventually use and benefit from it.
This is obviously not true of you know how to apply SABSA fully (drinking the full draught), but based on the conversations I’ve had at least—
Most people never get that far.
I know you’ve probably heard me say this before, but I’m going to say it again, both now and on a regular basis:
The key to SABSA is the proper understanding and application of the domain model, because that’s what takes Attributes and the Governance Model from interesting to enabling.
These are the things that hold everything together in the real world, and these are the core concepts that make your architecture hang together and make the traceability model possible. The Matrix is basically a lens – a checklist, essentially – that makes sure we don’t miss anything and that we have at least the coarsest levels of encapsulation present in the work we do.
But it’s not enough.
Sure, you don’t need to know how an engine works to drive a car…
…but is driving the car really our job?
I don’t think so—and neither should you.
It’s like giving you a box of crayons and asking you to do real art. Of course it’s possible, and if you don’t believe me, google crayon masterpiece or something like that, because there’s this guy who does amazing things with crayons.
But while possible, it’s really bloody hard.
There is an easier way to end up in the same place, but by seeing the world – and the method – just a little bit differently. It cuts away the complexity, helps you manage yours, and makes sure you end up with 100% SABSA goodness at the end.
If this sounds like something you want to learn more about, you’re welcome to join us here: https://archistry.com/BESA.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
P.S. I apologize for any formatting and typos in today’s email because I really am writing it on my venerable iPhone SE while sitting in a hospital waiting room. Everything will be fine, but the show must go on, as they say.
