I know it probably shouldn’t, but it still blows me away how many people don’t really get the difference between engineering and architecture—especially in security. A good while ago now, I happened on an infosec conversation in the twitterverse talking about the composition of the ideal security team. And, of course, there were SOC people, threat analysts, incident responders, security engineering, red teams and blue teams…
…and nary a notion of architecture was mentioned ‘tall. Among a group of maybe 10 people who clearly would qualify as “experienced” security professionals.
So, when I jumped in with a “You forgot architecture” comment, the response I got was another one of those slightly heavy-handed, yet not entirely unexpected, slaps in the face:
“I just figured that was part of Security Engineering. I guess maybe it deserves to be separate.”
“Well, YEAH!” screamed my brain. But that thought didn’t quite make it to my fingers. Probably a good thing.
But a conversation I had recently about architecture, and security architects in particular, made me remember that incident, so I thought it was a bit beyond time to bring it up. And it’s relevant, because one of the things I encounter quite often when I reach out to security architects is effectively a vibe of, “yeah, we don’t really get to do much real architecture here.”
And that, my friend, is a bit of a pisser that we need to fix.
However, it’s one that we can’t really address if we don’t recognize the fundamental difference between an architect and an engineer. Because, while both are problem-solvers to the core…
…the nature and scope of the problems they’re attempting to solve is…shall we say…often radically different.
Now, I’d imagine it’s probably been awhile since you’ve read or watched Apo
llo 13. If it has been, it’s worth digging out and going through again. In particular, there’s the critical scene when the 3 intrepid astronauts, far, far from home with a misbehaving spacecraft that’s effectively been shot out of a cannon begin to run out of clean air to breathe.
You see, the systems, for very good reasons, were designed for extremely particular requirements. And those requirements were highly-compartmentalized, isolated, and…dare I emphasize it:
Siloed.
So the situation arises that there are 3 men, 2 spacecraft, and no clean air. However, the reason for the clean air is that one of the spacecraft had been pressed into service well beyond its intended operational cycle carrying about 3 times the capacity of carbon dioxide originally anticipated for the mission.
And, because the mission objectives and requirements were very clearly defined – and highly competitively delivered – different organizations built each of the two spacecraft. And, given their level of assumed autonomy except for the designated interoperability of having to hook the two of them together at two critical points of the missions, the “implementation details” were left to the system designers.
A situation, in fairness, not too dissimilar to the world we face every day. A situation that normally isn’t a problem…
…right up to the point where it is.
A point like 3 guys not having enough clean air to breathe, for example.
So the challenge given to the engineers on the ground from the combined team was effectively this:
“I suggest you gentlemen invent a way to put a square peg in a round hole…rapidly,” because the Lunar Module (LEM) used round round filters to scrub out the dangerous CO2, and the ones on the Command Module were square.
Thankfully, the engineers – being engineers – were crafty problem-solvers, and given a set of items available to the astronauts in space, they managed to create a way to attach the working filters to the system that, under no circumstances, had ever been designed to accept.
To the layperson, it looked rather like something my 5 year old would build out of cardboard, a vacuum cleaner and some duct tape, but it did the job.
So that’s the essence of the engineer: work with what you have at your disposal, whatever it may be, and creatively solve problems until you make it work. You don’t get points for aesthetics. You only win if nobody dies.
And I’d be 16 ways from stupid if I said that we don’t need engineers – and really, really good ones – as part of our security team, because, we most certainly do.
But, you’ve also gotta appreciate the perspective of the architect – which was clearly lacking in the case of the way the Apollo system was ultimately designed (and yes, to an email a while ago, I am “armchair architecting” right now. Get over it.)
Because if there had been an architect on the team with the appropriate level of oversight, and you would’ve been able to run through a proper risk assessment and plan for the potential systems failures that might occur several around 100,000 miles away, the architect would’ve decided that being able to have an interoperable air filtration system across the two spacecraft might’ve been a wise design constraint.
And notice I very carefully used the words “design constraint.” That’s what architects do. They make the decisions that they don’t expect will change, or the decisions that will be hard to change the further down the line you get. The make the tough calls about the trade-offs between conflicting requirements, that, in some cases, do end up making the lives of the engineering team a living hell.
But making those tough decisions – with the awareness of as big a picture as they can hold in their heads – is actually their job.
Because the ultimate difference between the engineer and the architect is this:
Engineers make things work. Architects make things work…with everything else.
And you don’t have to look too far in the average enterprise environment to see that there’s not a lot of true architecture going on. As I’ve said before, there IS an architecture, but it’s certainly not there by design.
It’s there by happy accidents.
Many.
Varied.
Accidents.
Based on decisions made by people focused solely on the problem they needed to solve, and with little awareness of how their decisions might impact everything else. And…fair enough.
It’s not their job. Not really at least.
So the point is really this: there aren’t enough real security architects because there’s not enough people who know what a real security architect does.
The real security architect bridges the gap between the business and the solutions that enable and protect it. They know the score. They understand the worlds of everyone involved – with a stake in the solution – and they have the skills to ask the questions that enable the hard decisions that will last from weeks, to months…
…to decades.
And which will hopefully stand the test of time as being correct.
Hopefully, at this stage, it should be clear that the skills of the architect are more than slightly different, and, dare I say it, a super-set of the skills fo the engineer. And, frankly, there aren’t really that many places to learn them…
…at least efficiently, and based on the hard lessons of actually doing it in practice.
So, that’s where the Archistry Building Effective Security Architectures program comes in. Because in just 7 weeks, anyone who joins the cohort will learn more about being a successful security architect than I learned in the first 10 years I did it for real.
You get to practice those skills in a safe environment, with fellow security professionals. And, as a result, you can achieve measurable skill development. In fact, we prove it as part of the way the program is structured to show you how you appreciated the problem of architecture at the beginning of the program vs. how you’d solve a similar problem after 7 weeks of intensive immersion into the world of the modern security architect.
It’s the only program like this I know, and I built it from the ground up based on the skill gaps I saw working with security teams around the world in very large, highly distributed organizations.
And you can join this cohort – if you haven’t already – independently of any travel restrictions, anywhere in the world, because it’s a hybrid recorded and live program with scheduled exercises you complete with your fellow peers in the cohort.
That’s how you learn the skills. That’s how they get proven. And that’s why it actually works.
If this sounds like something you’ve been missing, then here’s the link to find out more about it and register to join the next cohort kicking off in July:
And, for the next couple of weeks or so, if you join now, you’ll save $1,000 off the regular registration fees.
The world needs more security architects who actually know what they’re doing. Will you be one of them?
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
