Turning theory into practice is always tricky—especially when it’s your first time. And with security architecture, the biggest problems you have aren’t really about security architecture at all. They’re about dealing with all the other problems that you have to suddenly stop ignoring if you’re going to change the way security is actually delivered.
Because that’s actually what it takes in the majority of organizations I’ve worked with. You have to change the way you think about security and how it’s done.
The biggest mistake people make, however, is trying to change everything at once—even when they say they aren’t.
If you want to really change things, you first have to understand that the way things are is a direct function of the behavior of everyone involved. And that behavior is influenced by the way they see the world.
Change the way people think. Change the behavior. Change the world.
And it starts with you – personally – and the way you approach the security work you do.
It doesn’t matter if you’re sitting in design meetings…
…or trying to compile risk assessments
…or doing stage-gate security approvals.
It’s all the same. You have the EXACT same opportunity to start building architecture in each of those scenarios as you do…
…if someone magically rolls out the red carpet and brings out the purple upholstered couch carried by a band of naked virgins.
The irony is that your chances of lasting success are actually far greater in the first case than in the last one.
Because even if you have all the support in the world, and you’re given the keys to the security kingdom…
…you can still make a mess of it if you don’t really know what you’re doing, where to start, or what is actually going to give you the most value, both immediately, and in the long term.
The most agile security you can ever deliver is being agile in the way you think – as an individual – about the way you do your work.
But you can only truly do that if you understand what you need to be producing instead of what someone tells you to produce.
That may sound the same, but it truly isn’t.
Someone tells you they need a document…or a policy…or a checklist…or an approval sign-off.
That’s what they’re telling you to produce, but if you just stop there, and only fill in the blanks without understanding the purpose that…deliverable, if you will, is actually doing in the bigger picture and about what questions it’s actually trying to answer…
…you won’t really understand the function of security, and you won’t really understand the job you’re supposed to do.
And if you’re not willing to make this shift in your own behavior…and commit to changing the nature of the work you do and the way you do it…
…then how can you rightly expect anyone else to change theirs?
Or give you their blessing to force-feed some half-baked, crazy idea you have about the way security architecture “should be done,” if you’re not prepared to eat your own dogfood and demonstrate why it matters.
Being agile starts with you, and once you decide to change your behavior, you need to make a choice about how you’re going to figure out what you should do differently.
Option #1 is figure it out on your own, with little support, while stuck in endless, mind-numbing meetings and getting constantly hounded to solve operational security problems.
It can work, but a) it takes time, and b) how will you know whether you’re on the right track?
Option #2 is learn directly from someone who’s “been there, done that” and made 14 years decisions as to what “best” really means—and who, eventually, got it right more than he got it wrong.
The thing about Option #2 is that you can learn enough – and develop the tangible, practical skills required – to start doing things differently and making a visible, positive impact towards being more effective pretty quickly. And you can do that in less than 7 weeks, because every week, you’ll be learning and practicing new, valuable skills you can apply to your own work—as soon as you’re confident enough you know what you’re doing.
How will you know?
That’s what the peer reviews are for in the Building Effective Security Architecture program. They give you valuable feedback as to what you’re doing right—and where you’re going off track. And based on that feedback – or even before you start trying to solve the exercises – you can engage with me directly for any additional information, clarifications and conversations required to make sure you ultimately know what you’re doing.
But you only get that kind of confidence…from that level of peer and expert support…if you’re part of the cohort. And you can only join the cohort THIS WEEK before the registration closes on Friday at 11:59pm US/Eastern time.
Or maybe you don’t care about any of this stuff, and you’re happy enough doing what you’re doing. Or maybe you think you can’t because you don’t have the company credit card to pay for it in time…or maybe it’s something else.
I have no idea what your answer is right now. But if you do end up registering for the program before the deadline in just 5 days, it’ll give me a pretty good indication of what you might think.
Registration’s open. Link’s here:
Will I see you in the cohort next week?
Stay safe,
ast
—
Andrew S. Townley
Archistry Chief Executive
[NOTE: the registration deadline for this cohort of the program has passed. If you want to make sure you don’t miss out on the next one – and the opportunity to register at a significant, early-bird discount – then you might want to consider signing up for the daily emails via either the pop-up or the form on the right sidebar. — Ed.]
