Archistry

Survivability by Design™ since 2006

  • Home
  • About
    • Who Is Andrew?
    • C2T System™
    • The Agile Security System™
  • Contact
You are here: Home / Archistry Daily / Foxy frameworks

April 3, 2020

Foxy frameworks

What better way to kick off a few Friday thoughts on our insatiable desire for security frameworks than with a hat tip to one of my favorite Jimi Hendrix songs, Foxy Lady? Which he just happened to have played as song number 7 (no coincidence, I’m sure) during the iconic 1969 Woodstock concert. That’s right, friends and gentle beings, today’s email is all about the next of the 7 security architecture sins:

Lust.

In particular, it’s all the time we spend lusting after all those foxy frameworks that just never cease to keep popping up, swishing their tails at us, and driving us crazy.

Cute little heart-breakers, indeed.

Because, you see we just looooooovve frameworks. And, I’m no exception here. I just try to exercise a little bit of moderation. But it doesn’t take much to make your eyeballs pop out of your sockets…your heart start racing…and getting all hot and bothered about all those security frameworks out there.

There’s. Just. So. Many!

And, as far as architecture frameworks? Well, doing a quick Google search will score you a hit of a whole leash of foxy architecture frameworks compiled and maintained by WG42 of the ISO committee in charge of the care and feeding of the ISO/IEC/IEEE 42010:2011 standard for Systems and software engineering – Architecture description.

78 of ‘em, to be exact.

I’m sure it’s not all of them, but it’s a list that includes a whole host of them that I’ve never even heard of before. Sure, they’re not all frameworks for security architecture.

But they ARE all frameworks for creating and maintaining architectures either directly or indirectly related to technology elements.

And if they’re related to technology elements, then there’s gotta be come “cyber” in there somewhere. Even SABSA’s on the list, so it’s fair to say that we’re at least talking about potential descriptions of architecture that have some aspect of security requirements in them…again, implicitly or explicitly.

Why do we love frameworks so much?

Well, we have a good reason: they’re often pretty damn useful. 

The best definition I ever came up with was: a structured approach for making a decision, solving a problem or deciding a course of action.

That’s why they’re good and useful. It helps us structure our thinking and approach so we don’t go off on wild tangents trying to boil the ocean, flail around the place knocking over furniture and crashing into walls, and generally get ourselves distracted from the problem at hand. And you can even find frameworks that go so far as to define tools, information structures, data formats, processes and even the specific standards to be followed.

But here too is where the cart potentially starts to go off the rails…because if a framework is something we use to make decisions, solve problems and define a course of action based on decisions we’ve made…

…then that means that in any given day we could conceivably use THOUSANDS of frameworks.

Thousands.

And, since you and I may have different backgrounds and experience, we’re going to have our own internal frameworks that guide our activity and behavior. After a while, we might even write them down, introduce them to our friends…

…and spend hours and hours going on about the virtues of those frameworks over other approaches we’ve seen – or someone else has developed – to do the same thing.

It’s like the song says:

Now-a I see you come down on the scene
Oh…fox-ey
You make me want to get up and scream
Foxy, oh baby listen now

I’ve made up my mind
Yeah, I’m tired of wasting all my…precious time
You got to be all mine…all mine

We hear about a new framework. We get to know it a little bit. We chat it up, and scope it out to see what it might be capable of…

…and then we take it for a spin.

It doesn’t matter that we might already have a framework (or 300) at home. This one’s new. This one MUST be:

…better

…faster

…easier

…more general

…more specific

…more supported by our tools

…helps us justify buying new tools

…supported by vendor/guru/industry

…or any one of a bazillion things that might just trip our framework fancy.

Whatever it might be, we want it. We NEED it. We must make it ours.

However, before we’ve really gotten to know it…ya know, what it does well…what it doesn’t…what it likes for its birthday…

Before we’re really ready to settle down into a long-term relationship with it…

…it bites us – maybe a little…or maybe a lot – but it does.

And WHAM! Right there. Right in front of us is a bright, shiny, new “pretty little thang” struttin’ right on by…and we’re off to the races.

Again.

Leaving a trail of discarded, neglected and probably underutilized frameworks that were probably perfectly capable of doing the job…

…and probably doing it pretty darn well, too…

…if we’d have just stuck with them long enough – and we’d been willing to put the work in it really required – to make it happen.

Now, from a practical point of view, all this fox hunting gets kinda expensive—in both time and money.

And, it ultimately takes a lot of energy.

It’s also really, really…REALLY easy to get lost down the den of a particularly foxy-lookin’ framework so far that we’re not actually managing to deliver anything of value to our customers.

That’s bad.

And if we do it often enough…it’s our job on the line.

So we need to figure out how we can chose wisely…how we can pick the right balance of just a few frameworks for the widest possible set of problems we need to solve.

And then…we need to have a reliable and repeatable way to allow us to focus on our own personal selection of foxy frameworks…

…and then figure out how to align, integrate and support anybody else’s chosen set of foxes…as quickly and easily as possible.

When you think about it…it’s all really knowledge and wisdom we’re talking about needing to develop. But knowledge and wisdom don’t always come easy—especially if you’re trying to figure it all out on your own.

If you want to get some practical advice on how to steel your will against the temptation of getting lost lusting after any ol’ foxy framework that may come along – today, tomorrow or 10 years from now – then maybe you should make sure you’ve subscribed to the Security Sanity™ print newsletter in time to have the March issue delivered directly to your door.

To do that, you need to scoot on over to this here link before Saturday night (tomorrow at 11:59pm) when the shopping cart turns off:

https://securitysanity.com

It costs the same, no matter where in the world it needs to go.

I can’t promise you it’ll cure your framework fixation, but what I can promise is that it’ll show you some key aspects of frameworks worth keeping vs. those that might only be fun for just one dance.

The choice is yours. The clock is ticking. What are you going to do?

Stay safe,

ast
—
Andrew S. Townley
Archistry Chief Executive

Article by Andrew Townley / Archistry Daily / "Selling" Security, 7 Deadly Security Sins, Security Architecture

  • Email
  • LinkedIn
  • Twitter
  • YouTube

EMAIL NEWSLETTER

Want to get DAILY email tips on how to build a more effective security program so you can prove your security investments deliver value to the business?

You can always unsubscribe at any time, and we won't sell your data to third parties.

About Us

Archistry works with you to ensure what you want to achieve actually gets done, linking strategy, risk, governance and compliance to enable sustained exceptional performance Read More…

Testimonials

Andrew is a highly skilled and experienced information systems architect and consultant, which in my view is a rare thing. He is innovative in his thinking and merits the title of 'thought leader' in his specialist domains of knowledge—in particular the management of risk. Andrew has embraced SABSA as a framework and, in doing so, has been a significant contributor to extending the SABSA body of knowledge."

— John Sherwood, Chief SABSA Architect

"Fabulous person to work with. Very engaging and insightful. Extremely good technical knowledge with ability to relate concepts together and overcome differing opinions. Makes things work."

— Kevin Howe-Patterson, Chief Architect, Nortel - Wireless Data Services

"Andrew was able to bring clarity and great depth of knowledge to the table. His breadth of thinking and understanding of the business and technical issues along with a clear and effective communication style were of great benefit in moving the process forward towards a successful conclusion."

— Doug Reynolds, Product Manager, MobileAware

"Andrew is a fabulous consultant and presenter that you simply enjoy listening to, as he manages to develop highly sophisticated subjects in very understandable way. His experience is actually surprising and his thoughts leave you without considerable arguments for any doubts in the subjects he covers."

— Biljana Cerin, Director, Information Security and Compliance

Recent Posts

  • If you want better security, you’d better have a better security architecture
  • The ultimate security song to keep you focused on what you’re doing
  • Security heroes
  • There’s always a people problem
  • Putting your data flow diagrams out to pasture…for good

Looking for something else?

  • Home
  • About
  • Contact

  • Terms of Service
  • Privacy Policy
  • Cookie Policy
  • Copyright © 2006-2025 Archistry Incorporated or its affiliates

"Archistry", the stained glass window logo, "Pragmantix" and the Pragmantix™ logo, "Archistry Execution Framework (AEF)", "Archistry Execution Framework, Cybersecurity Edition (ACS)", "The Agile Security System", "The Agile Business System", "Baseline Perspectives", "Architecture Wall", "Archistry Execution Engine", "Renegade Security", "Renegade Security System", "Security Value Delivery System (SVDS)" "Collapse-to-Traction", "Collapse-to-Traction System", "Adaptive Trust & Governance Model (ATGM)", and "Adaptive Trust & Governance Model for Organizations (ATGM4O)" are trademarks of Archistry Incorporated or its affiliates.