As you might’ve discovered in your own architecture work, it’s pretty easy to get overwhelmed with security architecture documentation. I remember the very first “proper” architecture description I did according to then IEEE1471:2000 (now ISO/IEC/IEEE 42010:2011) was 165 pages.
And that was supposed to only be about the federated identity solution I was working on at the time.
Of course, it wasn’t. I mean, it couldn’t have been only about that part—because the documentation for the rest of the architecture could best be described as…
…not there.
In the work I’ve done personally – as well as the work we’ve done with our security architecture and security program transformation engagements – finding the documentation “sweet spot” is always a challenge.
Make the document too big, and nobody’s going to read it—no matter how insightful it might be.
Build a lot of detailed architecture models, and they’re hard to actually communicate to anyone not familiar outside the tool—because you’d need a paper size of -A42 or something at least billboard sized so you could see all of what’s in most of the views of the model.
Like many things, architecture documentation is a bit of a trade-off. Take the time to document it completely, and it will likely have changed 10 times since you started. Avoid dealing with any documentation, and the view of the architecture exists only in the heads of the team…
…and probably in at least as many versions as there are team members.
So to be successful as a security architect, you need to figure out some kind of balance that not only aligns with “good practice,” but it’s gotta fit in with your organizational culture too.
At this stage, I’ve moved away from heavy documentation a good bit—especially when starting out, because it’s one of the easiest ways to bog down your early architecture efforts and both lose your enthusiasm…
…and keep the people with budgetary approval potentially waiting too long to see anything of value.
It’s one of the reasons I distilled the architecture documentation down to some of the barest essentials and adopted the Agile mindset about what needs to be documented. It’s where the 3 Baseline Perspectives™ and the Architecture Wall™ approach that’s part of The Agile Security System™ came from, and, it’ll actually take you a lot further than you might think.
Is it the only documentation you’ll ever need?
Of course not.
But the one thing it does do is give people a good, accessible way to understand the current state of the world of security—and how our world intersects the world the rest of the organization cares about.
Being able to cut through the reams of potential security architecture documentation and focus on the bare essentials necessary for everyone to get their work down is one of the many things you’ll learn if you’re part of the upcoming February cohort of our flagship, online learning experience, Building Effective Security Architectures. And it’s probably one of the most visible and distinctive aspects of Archistry’s whole approach.
However, if you want to get in – and save 60% off the price of admission by the time we get into next year – then you’ve less than 2 days left to register to get the discount.
If you’re in, here’s the link: https://archistry.com/besa
Don’t dawdle, because after 11:59pm US/Eastern, the price goes up. If you’re frustrated by your ability to reliably and repeatably build security architectures that really drive decisions, then maybe it’s something you’d want to be part of.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
