May 25, 2020
You heard me talking about it yesterday. Those lov-er-ly “solution architecture” one-pagers that generally are either highly abstracted so as to fit on a single 16:9 slide or so detailed, the largest font size used on an A0 sheet would be 4 points. Either way, the one thing you can count on is you’re gonna have to drop everything, hit the garage and dig out the weed-whacker…
…because we’re gonna need to do a good bit of “trimming” before we will be able to identify very much that we’d consider “architecturally significant”—you know, it’s those things that it’s either going to be damn hard or damn expensive to change later.
Wanna buy a Dell vs. HP server?
I’m an Architect. I don’t normally care, thanks very much.
Care to revive the old Oracle vs. IBM database wars from the heady days of dueling billboards down Highway 101?
Nope. Been there, and I still have some of the Informix swag in my closet.
Want to play “What’s the browser YOU love to hate?”
Nah. They all have issues. It just depends on what we’re really trying to do with them.
The thing I’ve noticed over the years now that I really don’t care that much about the implementation details is that there’s a great deal of IT and security time consumed with arguments about which shade of green each blade of grass should be and which exactly how many of them there should be. And that’s often time better spent worrying about bigger problems that might make it actually easier to do your job rather than what label’s on the box.
Of course, like most things, it doesn’t matter…until it does.
If you’re going to tell me that we have 500 different, unique information classification schemes in the average organization, then yeah, that’s a problem. And it’s an architecturally significant one because there’s far too much complexity in the system to enable people to operate it correctly, reliably and predictably.
And if we can’t do that, then we have somewhere south of zero-levels of confidence that anything worthwhile’s going to get done at all…
…let alone trying to demonstrate how much value’s ultimately delivered by the security team.
Or, if you tell me we have 25 separate versions of operating systems running in our environment, I’m at least going to ask the question why. Maybe it’s necessary…but many times it’s not.
See the thing about “architecturally significant” is that it’s a slippery little devil, and he can sneak around for months – and sometimes even years – before he finally ends up sitting in your chair the one time you don’t think to preemptively peer precisely where your posterior will be planted. When you don’t, then you’re gonna probably end up with some 6” rattlesnake fangs in your butt, and the equivalent of someone dropping the first 10 volumes of the old print encyclopedia Britannica on your desk with a grumpy:
“Well? You’re the architect. What’re you waiting for? Fix it!”
Unfortunately, at this point, people tend to dive in with the weed-whacker of their choice – machete, electric or 2-cycle, gas powered – and start waving it around just enough to get their bearings, cut a path outta the problem, and high-tail it back to the safety and security of their inbox.
At least the dragons there might not be quite so big, quite so scary, and not quite so ancient.
I know how this goes, because for 2 years of my life I will never get back, I found myself digging through 6+ years of project documentation to try and figure out why in the hell someone would possibly think what I’d inherited was a good idea.
Sure, it was a good idea…on paper.
But why, oh why did someone hit with the literal-stick end up being put in charge of the solution design that implemented – concept directly into code – the high-level abstraction that was meant to explain the overall value to the business project sponsors?
And had I known then what I know now about doing architecture archaeology…and about where to focus…and about how to get the most leverage out of my documentation…and how to do it with the least possible amount of effort…
I dare say, I’d have a good fewer white hairs on my head.
Whether we like it or not, being able to take a half-baked view of a complex solution as a starting point – be it on a slide, in a binder or on a whiteboard – and turn the crank on our architecture development engine and burp out a security strategy and supporting architecture to give it the best chance of success is one of the “essential skills” of the modern security architect.
But that doesn’t just mean taking some infrastructure kit and control icons out of the bag and dumping them all over the diagram. It means actually trying to understand all the background, intent, context and business value that’s supposed to be delivered…
…and then integrating it – or not – with your existing enterprise security program.
While it’s not technically hard, it can be overwhelming. And that’s why for the upcoming June issue of the print Security Sanity™ newsletter, I’m going to walk you through a hypothetical example of the kinds of stuff I’ve seen in project charters and show you a reliable and reputable plan of attack that gives you a good view of what “security” should mean in that instance and how near or far you might be from already having those requirements in place in your existing control environment.
If you want it, you’ll need to be a paid subscriber to the newsletter before the deadline at the end of the month. And to do that, you’ll need to go here:
Stay safe…and try not to wrap the trimmer string around your ankle or something this holiday weekend.
ast
—
Andrew S. Townley
Archistry Chief Executive
