There’s a word that pretty-much describes most of the architects I know.
Pedantic.
And if you subset that list to the ones that are security architects, then I’d say that gives you something like Pedantic++.
Because what we’re really taught to create as security architects are rules based on all the minor details of all the potential exploits that might be possible…
…and then shove them down the throats of the “mere mortals” we’re trying to protect—all the while being shocked and surprised that they couldn’t really give a rat’s arse about the majority of our rules.
Which also assumes they understand them in the first place.
Closely related to the pedantic architect is the perfectionist architect. In this case, it’s not simply enough to find all those minor details and make sure they’re carved in stone…
…they need to be carved with nano-laser PRECISION.
Now the way this tends to play out when you give one of these kinds of architect a tool or a template for building architecture is that they go overboard on the “Collectively Exhaustive” of MECE—where if there’s a link…it must be followed.
…if there’s a risk…it must be mitigated.
…if there’s an asset…it must be identified.
In full disclosure, I was that guy. I was the guy who dug through academic journals, read thick, technical specifications and went through international standards with a fine-toothed comb so that I was damn-near CERTAIN…
…nobody could poke holes in what I’d done, or they could create a compelling argument that I hadn’t “done the right thing.”
The problem with this approach is…it’s feckin’ draining!
And exhausting.
And time-consuming.
And the worst part is…by the time you’ve done all that crap, the people who you were actually trying to do it for have either given up waiting and gone ahead without you…
…or died of old age.
So eventually, I realized that perhaps this wasn’t the most agile approach to architecture—nor was it really delivering the value people really needed.
Because, in fairness, 99% of people aren’t going to read your 350 page architecture description anyway—even with a handy, well developed stakeholder guide starting on page 2 that holds their hand and tries to help them not get documentation indigestion.
I finally realized that a timely bad decision was better than a late good decision.
Why?
Because if you quickly make a bad decision, you’re going to find out quickly too…and then you can go ahead and make a better decision based on what you’ve just learned about the problem that you didn’t already know.
So I looked at all the work I’d done to try and exhaustively document and capture SABSA security architectures—and I looked…really and genuinely looked…at the amount of effort that I was willing to put into the process…
…vs. what everyone else was willing to do…
…and finally, I decided that relaxing a bit about some of the things that I’d held as fixed laws might be worth a try, and I became a “slacker” architect.
Now, you might be wondering about this whole slacker architect vibe, but here’s the thing:
Slacker architects actually know the difference between something that’s necessary right now…
…and something that’s not critical now and can be either filled in, put off or basically ignored another day.
Slacker architects know which corners to cut – safely – and which ones to sharpen until they’ll draw blood – from the other side of the room – as soon as you walk in the door.
And because of all that…slacker architects are the most magical thing:
They’re effective.
And they’re effective because they can prioritize.
And they can prioritize because they understand what matters and what’s commentary.
The best part?
Being a slacker architect is the best way to learn how to develop security architectures that actually reflect the needs of the organization, because they’re not nearly as likely to get lost down some rabbit hole, endlessly filling in templates and architecture models…
…simply because they can.
Or because it’s there.
However, being a slacker architect is a harder skill to develop than you might imagine. But the difference between an overworked, stressed slacker architect and the pedantic perfectionist one…
…is that the slacker architect will have completed 10 projects, gone to the pub and kissed the girls (or boys)…
…in the same amount of time (or less) than the pedantic perfectionist is still toiling away trying to fill in the cells of an architecture catalog spreadsheet—for a single project, which is probably months behind schedule anyway.
Now all of that may not make a difference to you, and hey…you might not even be a security architect…
…but if you’d like to get more done…to provide more value to your organization and the people in it you’re trying to support…literally “work smarter” instead of “working harder”…and be able to actually create the space to deal with the inevitable operational oversight and input requests you know you’ll never really escape…
…then I believe – in my completely biased opinion, of course – that spending the next 7 weeks as part of the next cohort of Building Effective Security Architectures could teach you EXACTLY what you need to know to become the ultimate slacker architect.
A better architect.
A faster architect.
And a less-stressed architect.
If that’s something you’d like to do, then here’s the link:
But you’d better get cracking—because the registration closes on Friday night faster than your date’s legs after you’ve dumped a cold drink in her lap.
You have 3 more days.
And you have 4 ways to pay, so I don’t want to hear any whining about not being able to do it if it’s something you really want to do.
I look forward to working with you over the next few weeks as part of the cohort.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
