I’m pretty sure you’ve noticed it…the stuffy head…the plugged-up ears…the lethargic responses. No, I’m not talking about the latest cold or the China virus.
I’m talking about the dreaded “IT disease” within security that it’s finally become clear is something that we need to not only identify…
…but we need to WIPE OUT COMPLETELY!
But maybe, you’re not quite sure what I’m talking about, so let me fill you in on a bit of background. In the dim and distant past, I was in charge of a lot of large-scale program implementations as the “enterprise architect” or “technical design authority” or “head honcho” depending who was talking about it.
Now, these were generally large, multi-million dollar projects, and the vast majority of them were public sector. That means that there was a pretty big emphasis on industry standards, interoperability and a lack of vendor lock-in—even in terms of methodology. And it was even more conscious than in many of the public and private companies I’ve worked with since then.
And, of course – and especially given one of the solution partners they’d picked to shadow the particular engagement I’m thinking of right now – you couldn’t swing a cat without bumping into TOGAF and it’s vendor-specific implementation that they were using.
At the time, I was trying to align, integrate and formalize my own architecture work—enterprise or otherwise. And this was also about the time I came across SABSA. It was also about then that I read Ross & Weill’s Enterprise Architecture as Strategy book. Putting the two together (with a side of IEEE 1471:2000) had a pretty profound impact on the scope to which I thought an architect should operate—especially given the role I had at the time.
What I quickly discovered was something that I also eventually included in the original version of the SABSA-TOGAF integration special seminar I was asked to develop for the SABSA Institute, and that was to highlight the distinction I’m now calling the “IT” disease as it related specifically to Enterprise Architecture…
…at least the way most people seem to understand EA.
You see, when most people use the term “enterprise architecture” the DON’T mean the architecture of the entire enterprise, e.g., the elements and the structure of the communications that enable the organizational entity as a whole to go about its business—whatever that is.
Instead…
What they are generally describing is what I dubbed EITA, which is the IT architecture of the organization that is all inclusive of the applications, infrastructure and data supporting every business function and department.
Naturally, when you get someone thinking about the “bigger picture” in a conversation with an EITA brain talking about “enterprise architecture,” it quickly becomes a muddled mess of misunderstanding…
…because they’re often using the same words…in the places the other would expect…
…to talk about entirely different concepts!
If you think I’m making this up, go ahead and dip your toe gingerly into any of the more active EA groups on LinkedIn, and it won’t take you too long to find a discussion exhibiting exactly this sort of problem.
You might be wondering why I’m brining this up. Well, the reason is that a lot of what I see posted by both individuals and vendors in the wider web as well as what I hear when I listen to security people talk about “security architecture”…
…suffers from the same type of “IT disease” plaguing EA shops around the world.
And I realized that this is one of the biggest reasons it’s so hard to “sell” security architecture initiatives in some organizations.
Why would they need a security architecture program—especially if they have an 80% complete CMDB? I mean, it’s just infrastructure and the controls and the way they’re connected…
…right?
Of course, you and I know that this isn’t the case. We know that there’s more to an enabling security architecture (enterprise or not) than what would sit at the Logical, Physical and Component layers of SABSA’s Architecture Framework.
But a lot of our peers…a lot of our colleagues…
…and even some of our bosses…
Don’t.
And actually, that’s one of the reasons I focus The Agile Security System™ so much on delivering tangible results as quickly as possible—and make it as easy as I can to start from a “typical” perspective of security architecture, get that stuff organized in a way that makes sense…
…and then allows you to connect it to the dots of the business objectives, the risks and the measures of success for the scope of the problem you’re trying to solve.
However…this can take some clandestine commitment on your part to actually take the initiative to fill in those gaps as a solo effort…kinda “behind the scenes” and “under the radar” so to speak.
And to be able to think the right way about security architecture that will enable the whole organization…
…while still being able to quickly and consistently make sure you’re building real, business-driven and risk-proportional SABSA spec architectures…
…is not quite as easy as falling off the proverbial security log. In fact, it might take a bit of rewiring and expansion of your brain to do it right.
Which brings me to our flagship Building Effective Security Architectures learning experience. It’s 7 weeks of focused effort that will enable anyone – provided they show up and do the work – to build SABSA security architectures—even in an environment where “SABSA” is taboo and formal architecture is scarcer than teeth on a hen.
If this sounds like just the think to make your life as a security architect a bit easier and a bit smoother this year than it was last year—and keep you from repeatedly solving the same problems and explaining the same solution requirements to your technical implementation teams, then head on over to this link today:
It’s the best, most sure-fire way I know to inoculate your organization from the dreaded “IT disease” infecting your security organization—if it’s not already established a pretty healthy foothold when you weren’t looking.
However, there’s only a few weeks left to make sure you reserve your spot in the next cohort starting on the 24th of February—even if you happen to also be headed to RSA that week.
On the flip side, if sharpening your security architecture skills isn’t in the plan for 2020, then that’s quite ok too. Either way, I’m sure you’ll make the right decision as to how best do the work you need to do this year.
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
