May 30, 2020
Strategy, architecture, architecture/design, design, artifacts, elements, activities…the questions swirling around what each of them really is, where they start and stop, what purpose they’re supposed to serve and just how they all fit together can sometimes almost escalate to fisticuffs. And our human, psychological need to draw boundaries and establish our “territory” and area that we control often works against the greater good of our teams and our organizations…
…and even our society, as you can see playing out right now in about a gazillion different ways, no matter which news, social, or experiential source you happen to choose.
Fortunately, there are solutions that can be found within the security team, but you’ve gotta be willing to be flexible. Unsurprisingly, the best way to do this is to focus on a common objective. Because once everyone has a focus, the default barriers of “it’s not my job” tend to come down almost automatically.
The astute reader would also realize yet again, that this is proof that knowing the theory and tactics of security architecture – or anything, for that matter – is only the price of entry into actually doing it. If you want to actually do it, and if you want to do it well, you’re going to have to understand the murky mess of human interactions, because using policies, procedures and other organization politics to force people into caring about – or acknowledging the necessity of – architecture and security just doesn’t work.
Here’s a couple of freebie tips included in the upcoming June issue of the Security Sanity™ print newsletter that might help you get things done better in your own teams, although they’re said a bit differently in the pages this month:
First, a lot of the confusion people have about the differences between design, architecture and what is and isn’t part of it comes from the same issue plaguing effective governance: a lack of understanding and awareness that a lot of the definitions depend on the context of the observer. Just like one person’s accountability is another person’s responsibility once they’ve agreed to do the task, one person’s architecture drives the other person’s design…
…but given that the best definition of architecture talks about “carefully designed structures” that work together to achieve an objective, you can see how it’s somewhat recursive and tends to spark context-specific arguments about who does what.
But what about the rest of it? What about the things you produce? What about, in SABSA terms, the components you buy, and the operational tasks it takes to manage them?
If we take that architecture is the decisions that are hard or expensive to change later, then even these too are relative, so it all ultimately gets, to quote the Fifth incarnation of The Doctor, “a bit wibbly-wobbly, timey-wimey” when you put it under the microscope.
And those structures?
They’re made of elements, and elements, architecturally speaking, can be…anything, including decisions, artifacts, expressions, mental models, and the components and activities people use and perform every day.
Architecture is the decisions that drive the creation of something that gives value and solves a problem, tangible or abstract tho that creation can be. So, you see, academically, the whole architecture argument tends to quickly devolve into a bit of abstract, navel-gazing and seemingly arbitrary boundaries that are permeable once you poke them.
I guess that means it must be hard, huh?
Well, not really. Harkening back to a favorite analogy:
You don’t have to know how to build a car to drive it safely…
…and so it goes with security architecture. You don’t have to know and be able to properly pontificate about the theory of architecture and how to do it, to be able to do it well.
You just need to stay focused on what value you’re trying to enable—while recognizing that everything that’s ultimately created as part of working towards that end will become a part of the living architecture you must maintain the moment it manifests itself.
And to prove that security architecture, design and actually delivering value doesn’t have to be hard, overly bloated and stilted in detailed process, even when you’re given only a glimpse of the whole problem you need to ultimately, I give you exhibit A:
The June issue of the Security Sanity™ newsletter, printed on real paper and with pages you must actually turn with your fingers and arms rather than an electronic swipe.
Because in its pages, I’m going to walk you through the security architecture development typical to where many of our customers and clients start in their role as security architects every day, so that you too can apply this, practically and quickly, to your ongoing projects…
…while increasing your individual skills and effectiveness as a security architect at the same time.
However, if you want it, you’d better get moving if you’re not already a subscriber, because the deadline to get it is just over a day away. Any subscriptions created after 11:59pm US/Eastern will NOT receive the June issue. Instead, they will start with the July issue.
So procrastination isn’t your friend. It’s just going to make you wait.
And if you’ve already decided that the whole print newsletter thing isn’t for you, then that’s totally cool as well. It’s not for everyone. It’s only for people who are ready to rip it open, devour its contents, and start trying to apply what they learn immediately—sometimes, even before they’ve finished reading the whole thing.
If that’s you, and you’re not already subscribed, this is the link you’ll need:
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
