A personal message from Andrew S. Townley, Archistry's Founder and Chief Executive

Dear Security Architect,

My name is Andrew Townley, and I’ve been implementing SABSA as a basis for security and enterprise architecture for over 14 years. During that time, one of the startling discoveries I made was that, in fact, there are two types of “security architect” out there. And if you’re anything at all like me…where you understand that security is about more than just technology…

…where you deeply believe that the only way you can be truly effective in your role to enable and protect your organization, is to understand where it’s going and the true risks it faces in getting there…

…where you recognize the value of creating reusable, easy to explain artifacts that control the hydra of the inherent technical complexity of our day-to-day worlds. The beast just waiting for that moment of crisis to snap it’s snake-like jaws and spit chaos across the fevered security response teams battling on front-lines of the issue…

…where you have the foresight to realize there is no possible way you can be successful as a modern security architect without a set of essential communication and interpersonal skills. The same skills allowing you to speak just as easily to the Board and Senior Leadership team – with their decades of business acumen and experience – as you can to all levels of the technical project implementation teams who probably share your own background and skills…

…then, without a doubt:

You are the 1% of security professionals who claim the title of “architect” for the work they’re paid to do.

After all, we do work in an industry that will nearly get into knock-down, drag-out fistfights arguing the nuances and the distinctions between “information security” and “cybersecurity” while the rest of the world stares at us, open-mouthed, wondering, “What the hell is the big deal—isn’t it all the same?”

It’s no wonder when you start talking about an abstract concept like “architecture” that things get all “wibbly-wobbly” in peoples’ heads—especially those outside of security or without a technical background.

The concept of where architecture starts, stops and who owns it has been a struggle to properly identify even within the technology community for years. I mean, have you asked any two enterprise architects to define what they do lately? The ensuing arguments may sound eerily familiar as they ring in your ears—before you get bored and tune out.

At least you’ll have the satisfaction of recognizing it’s not just you faced with this kind of problem.

So why should we think that it’ll be any easier for the security community to sort itself out, just because we’re suddenly thrust into the limelight by weekly – and sometimes daily – news reports of high-profile security incidents and data breaches?

Which brings me to the OTHER “security architect” out there—the one who doesn’t see the world in the way we do. These are the security architects that make a distinction between the “enterprise security architect” and the “cybersecurity architect” or the “infrastructure security architect” and the “IT security architect” because they have a firmly established comfort zone and scope of work they would like to do, and who don’t really have any interest in developing the awareness I described above.

That awareness which I believe you and I share.

The unfortunate reality of the world…our industry…and the perceptions of the people in the organization’s we try to protect is: we’re hopelessly outnumbered. And, as a result of this sad fact, this bias and limited, technology-focused view of security architecture may even extend into the minds of those leading the security programs we support.

The vast majority of the people we will encounter in our professional careers will think security starts and stops at the Internet, networks and viruses. And that same majority doesn’t really have any interest whatsoever in recognizing that risk is inherent in every action they take – every day – in delivering their individual contribution to the organization. And they would likely prefer to be unaware and unconcerned that the electronic computing devices on which they increasingly depend to make that contribution…

…are a vital part of the overall potential risk that the organization will fail to deliver its products and services to the customer…

…or the risk that key strategic initiatives will deliver less than the expected results…

…or the risk that members of the Finance team will watch piles and piles of otherwise untouchable cash pour out of liquid investments to pay the salaries and operating expenses any unexpected shortfalls in revenue and earnings would require.

In fact, the root of so many of the daily issues we face come back to an observation from around 400 BCE made by none other than Siddhartha Gautama—the Buddha himself:

"All human unhappiness comes from not facing reality squarely, exactly as it is."

When we, as “enlightened” security architects attempt to expound on the virtues of a true enterprise security architecture program that can enable, uplift and protect every single business initiative the organization may ever want to do…

…we often fall into a common trap. And that trap is that we’re more concerned about what we want…

…than we are about the reality of our environment and its impact on what matters to the people to whom we’re trying to “sell” our plans for security architecture.

And what often happens when we try to make our case?

Someone says, “Don’t talk to me about architecture. I just want to pass the next audit.”

Or someone says, “We don’t have time to invest in some heavy, formalized architecture process. Can’t you see we have code we need to deploy?”

Or someone says, “It sounds nice, but it also sounds like you’re trying to get out of doing real, practical security work.”

Or someone says, “We already have a team for that—and it’s not part of security.”

I’m sure there are others that you’ve heard more recently in your own work. But whatever the case, the response is often, essentially, a “no thanks.”

After again failing to successfully make our case, we trudge back to our desk, pound our heads in frustration on whatever happens to be available…

…and we feel just that little bit more of our enthusiasm, drive and zeal softly dim into the dull, grey swirl of the next security request to pop up in our inbox.

As depressing and soul-destroying as the above may sound, the secret I have discovered – along with everyone from James T. Kirk to Steve jobs...from the lasagna-loving cat Garfield to Elon Musk– is that:

If you want to truly win, you need to change the rules of the game you're trying to play.

That’s right. We’re going to change the rules for not only the way the game of security architecture is played. We’re going to change the rules for the game of security itself and the way it’s played in the majority of the organizations across the planet.

Remember, if we’re on the same page so far, it means you’re part of the 1%, so by definition, it also means that the odds are stacked heavily against us right out of the gate.

At this point, you might be asking me: “Andrew, what does this have to do with security architecture?”

My answer is that it’s basically everything to do with security architecture. Because the ability to build “the architecture part” of a successful security architecture program is really a straightforward set of skills you can easily learn. It’s a set of techniques, models and relationships that are reasonably easy to apply and create.

What’s DIFFICULT is actually getting the opportunity to build those security architectures in the first place. Because in order to build them…

…you need to be able to collect the information you need. And in order to get the information you need…

…you need to be able to speak with the right people. And in order to be able to speak with the right people…

…you need to be able to understand their world and what’s important to them. And in order to be able to understand their world and what’s important to them…

…you need to develop a whole host of skills and knowledge that the AVERAGE “security architect” has never even heard of—let alone would think had anything to do with building architecture.

When I realized all of this. When I finally understood what the real barriers were to doing the work I knew needed to be done, because I believed that taking a control-based or threat-based approach to security…

…wouldn’t do anything—other than burn out my body and my brain trying to keep up chasing an ever-growing tsunami of control frameworks, libraries, vulnerabilities, automated exploits and the inevitable evolution of the technology becoming more deeply embedded in our daily lives…

I decided I’d had enough. There had to be a better way.

And I found that better way in the SABSA methodology and framework, originally developed and refined by John Sherwood, David Lynas and Andy Clark, into the independent, globally adopted and comprehensive approach maintained by the SABSA Institute today. I met the authors, was personally mentored by them, and eventually used that knowledge and experience to teach over 200 people the official SABSA Foundation training. And I worked tirelessly to integrate it into my own architecture work, on behalf of myself and my customers.

But the answer, while correct…was still too hard. It was still too big. It was still too easily misunderstood. And that meant:

It was still too hard to get the buy-in and support necessary to build business-driven security architectures—even using a proven and globally adopted methodology.

A methodology that the vast majority of people we’ll meet will have never heard of—and which, even if they have, will probably have gotten the wrong message about what it is, where it came from and what it really takes to make it work.

And that’s when I knew I needed to find a way…that "better way” I mentioned before…to deliver all of the value and promise of SABSA…

…with a lot less effort…

…and with a lot less formality…

…and in a lot less time.

After 14 years of development, practice and implementation, the result is something I call The Agile Security System™. This reliable, repeatable and robust system for delivering business-driven and risk-proportional SABSA security architectures has been battle-tested in organizations around the world as part of Archistry’s customer engagements.

The Agile Security System includes basically everything I’ve learned about delivering robust security architectures that stick…that are actually used across the security teams who build them…and which are the glue that keeps security strategy and security operations connected and aligned. And until July of last year, it was only something you could learn, directly from me, as part of Archistry’s long-term consulting and security transformation program engagements requiring a minimum investment of at least $350,000, and often lasting a year or more.

However, since July of last year, I’ve formalized everything I do into an accessible set of 7 principles, 14 practices and 3 Baseline Perspectives™. Together, these are the 3 major components that ensure that real, business-driven security architectures can be developed, maintained and used as the basis of security activities…

…at ANY level…

…and at ANY time…

…security input is required.

That means that you can use the system to establish security architectures across all 6 layers of the SABSA Architecture Framework at the enterprise, program, project, change…and even on the back of a pizza napkin while huddled around an incident-response conference call.

And it also doesn’t matter if your organization is using a traditional, waterfall-esque SDLC, Agile or DevOps project delivery approach—or anything in between. In every case I’ve seen, across dozens of organizations and within a myriad of different verticals – from Banking to Energy to Internet to Manufacturing – the principles and practices will still apply. And because it’s a system…it’s a system for consistently building security architecture to make sure you don’t get lost…

…that you’re not distracted by operational demands on your time…

…that you’re not lost in the world of technology and security controls…

…that you’re not wasting your time building models and writing documentation you know nobody will every actually read…

That means it’s also a system that keeps you safe.

If you follow the system…if you’re guided by the principles…if you apply the practices…if you visualize your organization using the Baseline Perspectives…then it’s almost impossible for you to fail to deliver security architectures that provide the essential foundation for an effective security program…

…that clearly, traceably shows how you, as security, are enabling and protecting your organization—and without any question as to the value you provide for the budget you have.

And if you can do that…

If you can do that, then it means that you’re well on your way to building the credibility and trust required to deeply embed a risk-based mindset, to “shift security left” and to say farewell forever to the perception of security as the Department of NO within the organization you’re trying to keep safe.

If you’re ready to shift the way you think about doing security architecture…to stop being frustrated by the lack of progress or the lack of recognization of the security team by the rest of the organization…

…then maybe this is the right system that can make all the difference and unlock the potential for you to…

Grow Your Experience, Advance Your Career And Become A Better, More-Respected Security Architect

Right now, we’re getting ready to run another cohort of students through our flagship, 7 week Building Effective Security Architectures online training course. If you think it might be the right fit for you, here’s some of what you’ll find once you’ve enrolled:

 

  • The secret, almost automatic way to ensure we can quickly and reliably build an accurate picture of what security needs to be—every time and without using any complex, expensive or automated architecture tooling
  • A dead “giveaway” which virtually guarantees you have a weak, ineffective and “cowboy” security strategy (and the most effective way to triage it so you can wrestle it back into shape)
  • Why your “SMART” goals for security just might not be quite as clever as you may think (and how to take them back to school and make them really work for you)
  • The critical technique developed by the World’s Most Feared Negotiator, Jim Camp (and used by FBI hostage negotiations teams), that will not only help you get the most out of this course, but it will also allow you to instantly connect with non-security stakeholders and boost your credibility through the roof!
  • The #1 WORST mistake you make when you set security goals or when you’re trying to understand the real goals of your security customers (even if you do everything else right, if you make this mistake, you’re never going to be able to build effective security architectures that are aligned with the business).
  • An obvious – but almost always ignored – set of decisions you can make as a security architect that will ultimately have the biggest impact on your ability to keep your organization safe (not to mention also being the most important way you can manage your workplace stress levels, determine your career path and maximize your lifetime earning potential)
  • What it really means to be surprised in security. (Not only is it probably not what you’re thinking, it’s also one of the most potentially devastating dings your credibility can take.)
  • The demystifying truth about the fundamental relationships between strategy, goals, objectives and decisions (and why being clear about them can make a massive difference in the quality of your security architectures and overall security strategy)
  • A much better, and much more actionable, definition and purpose of a “building block” than you find in places like TOGAF—that won’t confuse the piss out of your business stakeholders!

Let’s take a break for a minute and talk about the often misunderstood concept of the humble building block.

Thanks to TOGAF and it’s highly confusing definitions and distinctions between architecture building blocks, solution building blocks and generic, run-of-the-mill-could-be-anything-you-want building blocks, people are often confused by what should be a pretty straight-forward concept. It’s kinda indicative of the nature of TOGAF itself, actually. By providing too many classifications of elements without clear delineations or the rules to determine where and when to use them, it just muddies the water. After the very first week of the course, you’ll have a more useful definition of what a true building block is that you can use both in your security architecture efforts and…

Which Will Make Perfect Sense To Your Business Stakeholders

without first giving them a complicated definition full of highly-technical jargon.

  • The psychology behind why habits are the most reliable way to make sure you consistently make decisions…no matter what the situation or what you’re trying to do. (Think about what you’d do in an emergency situation while driving down the highway with your family. Do you think a process is going to drive your reaction? Nope. Habits.)
  • Pull back the curtain on the mystery of what really happens during SABSA’s Implement phase (and why, while it seems so straightforward in the book and training materials, it tends to really wreck people’s heads when they try to apply SABSA in practice).
  • The most important (and most often unused) contributions of SABSA to the discipline of security architecture. (In fact, it’s the key to why the methodology scales from the enterprise to the electron—without changing anything.)
  • The biggest (and easiest) secret of staying focused on what matters when developing security solutions.
  • Why RACI charts actually end up causing more security governance problems than they ever solve. (Almost nobody talking about governance…not even COBIT or the famous strategy consultants at McKinsey…avoid these same mistakes.)
  • The world’s most powerful secret to defining the governance roles and responsibilities in your organization. (It’s also one of the most essential concepts of the whole SABSA methodology, yet very few people seem to recognize this fact.)

What People Are Saying About Andrew

A True Thought Leader

“Andrew is a highly skilled and experienced architect and consultant. He is innovative in his thinking and a true Thought Leader in his specialist domains of knowledge—in particular the management of risk. Andrew has also been a significant contributor to expanding the SABSA body of knowledge.”

John Sherwood – SABSA® Creator and Chief Architect


Makes Things Work

“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


Clarity, Depth and Breadth

“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.”

Doug Reynolds – Product Manager, MobileAware


Fabulous Consultant

“Andrew is a fabulous consultant and presenter that you simply enjoy listening to as he manages to develop highly sophisticated subjects in a very understandable way. His experience is actually surprising!”

Biljana Cerin, Director, Information Security and Compliance


Interesting, Useful and Full of Ideas

“Found the link to the July issue and read through this afternoon. Think you’ve done a really good job with it and especially around the objective of it being interesting, useful and full of ideas—which the newsletter easily met. Really looking forward to the September issue. If, in the unlikely event an August addition become available, I would happily purchase!”

Andy Smith – Security Architect


A Source of Sanity

“I have been working flat out the last 2-3 weeks on a very detailed program. The one thing that has kept me sane has been your daily emails about the Archistry training. Keep those great emails coming!”

Shane Tully – Enterprise Security Architect

  • The demystifying truth about the real differences between the roles you think you understand in a standard RACI model (including the one simple thing that will eliminate at least 90% of your confusion about who does what).
  • Why a lot of the time we spend every day as security professionals is totally wasted—if we don’t do this one specific thing.
  • The biggest – and most common – mistake people make trying to use SABSA to build their enterprise security architecture—that will kill your own architecture program dead in its tracks!

You see, SABSA is a pretty big beast, and it takes a full week to go through the official SABSA Foundation training course (and I know this because I’ve taught over 200 people across 4 continents to build security architecture this way). But despite there being a lot too it, it’s actually quite simple, as you’ll learn in the course. It’s just 3 core concepts.

More:

In the course – in fact, in the first module – I talk about this serious mistake that makes people treat the primary SABSA matrix as some kind of Security Architecture bingo card where they want to make sure they have something in every box—all at once, and from the top to the bottom. However, the real truth is that you can actually…

Build Actionable, Business-Driven Security Architectures WITHOUT Understanding SABSA to The Nth Degree!

And, ultimately, that's been the primary driver behind the creation of The Agile Security System from the very beginning.

  • A sure way to recognize your security program is going nowhere (and the one simple fix that will completely turn things around).
  • The single most violated principle of The Agile Security System that can reduce our effectiveness in building security architectures by up to 80%! (But remembering to do just one thing will make all the difference in the world.)
  • A perpetually vexing question for even the most experienced security architects (including a detailed description of the implications – both for…and against – the choice you will regularly face).
  • The 8 most fundamental decisions you will need to make about your security program that will have the biggest impact on your ability to protect and enable your organization (not to mention having a huge impact on your overall attitude towards the work you do every day).
  • The “lucky" seven elements that form the foundation of effective security architectures (and the exact questions you’ll ask to reliably and repeatably transform these into the architecture models you’ll later permanently brand in the brains of the delivery teams you support).
  • One-and-only proven-effective way to make sure you ALWAYS get the answers you need to build truly effective security solutions. (It’s no coincidence that it’s also the fastest way to gain the credibility and trust of the business you know you need to have.)
  • A simple “laundry list” of things you must remember to do – every time – when you’re  speaking to ANY security customer (with specific references to the elements that are built into the system to ensure you don’t forget)
  • The vital importance of being able to instantly recognize and classify the very words you read every day in building effective security architectures.
  • Exactly what to do – and how to do it – so that you don’t leave an interview with a stakeholder without learning one damn thing. (It’s a trap even experienced architects and analysts fall into far too often, but once you know what to do, it could literally change your whole life!)
  • A simple, 3-second “trick” which 100% eliminates getting totally lost in architectural requirements gathering (and boring the shite out of the stakeholders we’re trying to impress).
  • Why chasing the rainbow of MECE when interviewing stakeholders can be the fastest way to kill your credibility.

Now, if you’re a consultant (or were a consultant in a previous life), you’ve probably run across the term MECE (actually pronounced as if it rhymes with Reese). And it’s something that was originally defined by McKinsey, and which has been picked up as an an analysis tool in many other contexts. What it means is Mutually Exclusive and Collectively Exhaustive, and it’s a way of organizing information along those terms so that you have buckets that don't overlap, and you’ve fully identified the problem space of whatever it is you’re trying to solve. Unfortunately…the issue is that, at least in the early stages of stakeholder interviewing and requirements analysis…

You Might Have No Idea What The Real Problem Is You're Trying To Solve

And that’s a bad thing, because, just like getting ahead of yourself in other situations, prematurely playing the MECE card is one of the things that could get you tossed out of an office with a sore backside quicker than you can say it.

  • The “rookie” mistake even seasoned architects make that is behind the real reason security is seen as The Department of No (and why nobody wants to talk to you because they think you’re going to stop their projects—even before they ask you for anything).
  • Why “NO” is actually the BEST answer you can get from you security customers (and some simple ways you can make sure you get it).
  • The correct way to prevent the WORST possible answer to a question you ask a business stakeholder (and the techniques you can use if you inadvertently get this answer—despite your best efforts to prevent it).
  • How to avoid the biggest source of confusion when trying to build SABSA’s Contextual Architecture. (It’s not just you…it’s part of the way things work, so what you need to understand is why you’re probably getting confused and exactly what to  do about it if you are.)
  • The things you learned in grammar school (and probably forgot long ago) that will make a critical difference to the quality of the security architectures you will develop.
  • The ugly little secret behind why people say things they don’t always mean (and a killer technique that can make sure you’re not going to be sitting in front of the TV when you thought you’d be “dancin’ the night away” with the girl (or guy) of your dreams).
  • The fastest known way to identify what your real security requirements will be (for example, from just a first-pass read of any project charter).
  • How to build a picture of our organization so rich and vivid, our customers will think they’re wearing 3D, augmented reality glasses!
  • The surprising psychological links between what we need to do to build high-quality, business-aligned security architectures and simple things we do every day (like brushing our teeth and wiping our backside).
  • The simple technique to make sure we never end up on the arse-end of any assumption we’re going to need to make as a security architect.
  • The single, “oh my God” obvious way to make sure your architecture models don’t end up gathering dust in the corner (or being used to potty train your boss’s new puppy!)
  • Two different ways of understanding what’s really important to your security customers (and why it doesn’t matter one bit which one you ultimately choose).
  • How architecture layers – one of our most useful tools – can become deadly, horizontal silos that drown our creativity and effectiveness as security architects.
  • Exploding the myth that you need sophisticated tooling to build sophisticated security architectures. (In fact, you’ll want to actually ELIMINATE some of your architecture development tools as quickly as possible.)
  • Why it’s so important to clearly differentiate an “enemy” from an “adversary” when it comes to building security architectures.
  • A quickie, “idiot’s guide” to how to conduct a stakeholder interview (so they actually WANT to talk to you, and so you’ll also have the best chance of them answering your emails).
  • An “almost magic” way to isolate the architecture of a project, service or solution so that it AUTOMATICALLY aligns and complies with the established enterprise security policies (without tons of extra work, and with complete support for either more relaxed or more restrictive security requirements).
  • The correct way to build a useful architecture model of any organization on the planet that you might ever encounter (that’s based on 30+ years of proven industry practice and analysis)
  • Why the ultimate success and effectiveness of your security program will live and die by these key decisions (including the most common reasons we often make the wrong choices, destroying our credibility in the process)
  • Your 7 most critical security customers (and exactly what you need to know to get them to invite you to meetings).
  • The “big lie” of what it takes to build an enterprise security architecture. (You’ll personally lay this bare as you have the opportunity to create a real, enterprise security architecture in just 2 hours!)

This Is NOT Your Typical Online Training Course

We both know that online training is a hit-and-miss sort of thing. In fact, I’ve personally spent a many thousands of dollars on online training courses myself. And the worst part is, some of them, I haven’t even ever started—or, if I did, I might’ve gone through a few of the modules, gotten sidetracked, or had some kind of crisis, and never made it back to them—despite all the best intentions in the world (and, I’m sure that I will complete them at some stage…but when? Who knows.)

And at the other extreme was one online courses in particular that was supposed to take 8 weeks, but that I managed to finish in just two weeks of dedicated, highly-focused effort.

What was the difference?

Well, while they were both “go at your own pace” courses where I could Netflix binge if I wanted to, the primary difference for me between the ones I devour and the ones that are collecting virtual dust in my bookmark collection is that I had an immediate problem in that area to solve. They were critical, key skills that I needed yesterday, and so, when presented with the means to solve the problem I was facing, I did everything I possibly could to solve it—as fast as I could.

However…

This is only part of the story – and I’m sure, if you’ve ever done online training, you have a similar tale to tell – because the one thing missing was…

Feedback.

While I'd ripped through all the materials, I still wasn’t quite sure I was really “getting it.” I mean, hey, I thought I was…

…but I couldn't validate it.

And, in fact, in the one that I got the most value from, there wasn’t even any way to ask questions about the materials at all—or get any kind of guidance about where I was close, but where I just needed a minor push in a slightly different direction to make all the pieces fall in place.

You might be thinking to yourself:

“Yeah, that’s EXACTLY why I hate online training courses!”

So maybe you’re also the type of person who prefers a more direct, instructor-led experience where you can ask questions in person, and you can practice your new skills as part of workshops and exercises presented in a live training environment.

And, as someone who taught over 200 people the official SABSA Foundation certification course for 5 years, I do know what you mean. That connection you can make with the instructor…the way you can ask relevant questions about problems you’re facing right now, back at the office, that are related to the course materials…the way you can engage and build professional relationships and expand your network with the fellow participants in the course.

Yep. All those are extremely valuable side benefits you get from a live environment—in addition to whatever value you get out of the materials and what skills you manage to practice.

From my experience, however – and this is validated nearly every day in the conversations I've had with people who have done live training on complex topics – there's still a problem.

The problem with live training is that…

…it feels like you’re drinking from the firehose.

There’s often nearly 8 hours of training – over 3 to 5 days – and, by necessity, it’s a self-inflicted “death by powerpoint” kind of affair.

And the slides…yeah. Many times, there’s so much information crammed onto the slides that it seems like you’re basically reading a book instead of getting a training course. Even though you have notes, it’s still hard to keep up.

Then there’s the workshops and exercises. If you’re lucky, you’re with a good group, or at least the instructor can move you around between groups if things go awry. If you’re not, you’re stuck with the same 3-5 people for the week, and either it gels perfectly, or there’s ample representation of the extremes of the people who:

  1. Think they know everything, and
  2. The people who just refuse to participate and engage.

So, some of the potential value you get out of a live training is actually going to get lost in the shuffle. Because if you, personally, don't get to practice the skills and techniques you’re trying to learn, you’re going to struggle to remember exactly how to do it once you’re back at your desk…and you’re not going to get the validation and feedback on your own practice that you’d expect from a live training environment.

Getting The Best of Both Worlds

Maybe I’m the only one who instantly hears some classic Van Halen when I read the above heading, but it’s really what we’re after here. What if…you could combine the two, so that you get the advantages of the live workshop and the good things about online training all in one package?

One of my favorite stories in the book, The Blue Ocean Strategy, is about the genesis of Cirque du Soleil. It's a classic example of innovation in an industry by challenging the assumptions about what makes the industry special.

In case you aren’t familiar with the story, the short version is that the founders of Cirque du Soleil wanted to have a circus, but when you look at the biggest – and most unpredictable – cost of the typical circus, what you find is: it’s the animals. The feeding them…the cleaning up after them…the carting them around the place.

It just all adds up—and pretty quickly too.

So they eventually looked at the numbers and said, what if we could have a circus without the animals? What would that look like?

And eventually, you end up with a worldwide phenomenon that’s a household name (even if a lot of people can’t spell it).

So, that’s exactly what we’ve done with the structure and format of our flagship Building Effective Security Architectures learning experience. We’ve tried to get rid of all the bad stuff, and make sure we were able to bring together the best from online training and the in-person workshop so that you would have the greatest possible opportunity to internalize the skills you want to develop in a way that enabled you to put them into practice as quickly as possible.

Now, I can’t take credit for innovating this delivery model. I first experienced it myself going through a couple of training courses run this way by my friend Danny Iny. This is actually a good thing for a couple of reasons. First, it means that I didn’t just make it up out of the blue. It's been developed by one of the leaders in independent, online education, and someone who was an invited speaker at Google to talk about the future of learning – both online and in the real world – based on his thoroughly-researched book, Leveraged Learning.

The second reason is: it works. It's a model that's been proven to work across a number of different industries, and it’s backed by hard-core behavioral science and psychology research on the way people learn best.

My goal with adopting this format for our course is actually pretty simple. I want you to:

  • Be able to practice the techniques you’ll learn in the course on an individual basis so you can make sure you don’t get pushed out by the loudest voice at the flipchart.
  • Have the freedom to plan the way you will complete the coursework within the overall skeleton of the course schedule so that you’re not overwhelmed by information overload.
  • Get direct feedback on your own understanding and applications of the skills and material you will learn in the course so that you’re not left wondering if you really "get it.”
  • Have an opportunity to get immediate, live answers to questions you care about from both myself and the members of the cohort so you can solve your problems, complete your assignments and deepen your understanding.
  • Engage directly with me on a 1 to 1 basis so that you can get my perspective on either the work you’ve done or how to apply these techniques to what you do every day to maximize the value you get from the course.
  • Develop your professional network by having the opportunity to make individual, personal connections with other security professionals around the world who are experiencing the exact same things at the exact same time as you are so that you expand your safety net and source of ideas about how you do your job.

So, in putting together this course, I’ve not only made every effort to give you the highest quality and most practical material on building security architectures to enable the security programs of your organization, I’ve also worked hard to make sure that you have a learning environment that’s specifically designed to give you the best chance possible to really understand, internalize and be able to apply the material—almost from the moment you first encounter it…

…not days later when your brain is full and you can hardly remember what we talked about at the beginning of the course.

And finally, the format of the course means that your support network continues far beyond the completion of the core content. You will have access to the materials and the members of the cohort FOR LIFE (or, at least as close to it as I can possibly control).

That also means that you get immediate access to any future updates and enhancements to the course or the course materials as we continue to evolve our practice and learn from you, the individual members of the cohort.

So now, let's take a few minutes to talk about the…

Course Content And Delivery Model.

The course consists of 4 modules that are delivered over 7 weeks. The first module is special and is completed in half the time of the other 3, because its purpose is to establish a foundation on which the main course content will build.

During the first week of the course, you will also be given a Level Setting exercise that asks you to complete a security architecture task based on what you know right now and using whatever techniques you prefer. Then, the week after the last module has been completed, you will be asked to complete a second Level Setting exercise so you can compare your efforts and be able to judge for yourself what you were able to get from the course.

Here’s a brief overview of each of the course modules and what will happen each week so you can see how this hybrid approach to the course works in practice, and you can get a feel for what the experience will be like once you choose to enroll.

Foundations (1 week)

In this module, you’ll be introduced to the 7 core principles, the 14 practices and the 3 Baseline Perspectives™ of The Agile Security System. In addition, you’ll also be given a whirlwind tour of the SABSA® methodology, which is the common foundation for everything Archistry does.

Once you've been given the overview, you’ll get your first Level Setting exercise, which must be completed prior to the start of Module 1.

Additionally, before the start of the Foundations module, you will be given access to the learning environment and an invitation to a dedicated Slack workspace where you can interact with the cohort – including me – for the duration of the course—and beyond.

Module 1 – Back to School (2 weeks)

In this module, we will begin to see how the principles and practices of the system start to fit together and guide our thinking and approach to the task of building architectures. We talk about how the 3 Baseline Perspectives are used to give you an understanding of the organizations we’re trying to protect and how they’re used to facilitate the communication of what we need to do – and what we are doing – as security to support and enable our security customers to achieve their objectives.

A key element of this module is a deep dive on SABSA’s domain concept, because the domain is something we will use quite extensively as part of applying the system and structuring the work we need to do. In particular, we cover some extensions to SABSA’s core domain concepts that Archistry has developed through the course of our own architecture work assisting our customers with their SABSA adoption efforts.

The module content is divided into two primary sections. The first part will deliver a set of core content and a set of practice exercises on that core material. These practice exercises will be completed during the week, and they will be sent out for a peer review by other members of the cohort over the weekend. This means that you get direct feedback from your peers, and you can also get different perspectives and alternative approaches to solving the problem that you may not have considered.

Following the peer reviews each week, we will gather everyone together for a live Q&A call conducted via Zoom, complete with video if you wish, that will also be recorded and become part of the unique content of your individual cohort experience with the course.

The second week will give you some additional content that builds on the first week of the module and a more “real world” module assignment that you will need to complete before the weekend. As before, peer reviews will be conducted of the module assignment – generally by different members of the cohort than reviewed your practice exercises – so that you again can get immediate, direct feedback and suggestions from the rest of the cohort members to further cement and solidify your understanding of the module materials.

The last event in each module is a live, wrap-up Q&A call where you have the opportunity to ask me anything about the content or the materials so far. In the past, sometimes this may be a walkthrough of a specific solution, or a live “over the shoulder” session of me working on part of a similar problem of the module. But the purpose of the call is really to make sure that you have a clear handle on the content we’ve already covered so you’re ready to move forward.

Module 2 – A Brief Business Primer (2 weeks)

In this module, we’re going to cover the fundamental concepts of business. Why? Because, based on my own experience working with security architects over the years, the lack of basic business knowledge is one of the biggest reasons security professionals have a hard time not only with engaging with the business in the first place, but it’s also the primary reason behind our struggles to express what we do “in business terms” so that we are better able to get what we want—including budget, staff and shiny new technology controls.

So that’s what we’re going to do. We’ll look at core concepts like profitability, business and operating models and some important thinking from HBR, Bain & Co. and even “real” enterprise architecture to help you better understand how to position and prioritize the capabilities your security architecture provides the business.

Like Module 1, the format and structure are the same. There’s 2 live Q&A calls, and there’s a set of practice exercises, a module assignment and 2 sets of peer reviews over the weekends.

Module 3 – Building Architectures (2 weeks)

In this module, we’re going to apply everything we’ve done so far in the course and focus on understanding the fundamentals of architecture, how it relates to strategy and governance, and walk through an extended case study that demonstrates the step-by-step approach to solving problems with The Agile Security System—and, not surprisingly, building SABSA security architectures at the same time.

This module is the longest, and most intense module of the course, because it's where everything comes together. It shows you how to integrate the system into common Agile and DevOps delivery, and how to deal with the problems of synchronizing security control capabilities with the requirements of supporting hundreds of daily deployments with the right security solutions. Not to mention how to tear apart a security policy, control framework like the NIST CSF or an annual report to extract a useful and functional security architecture hidden inside.

Following the second live Q&A call of the module and the conclusion of the core content, you will be given your second Level Setting exercise, along with all of the key worksheets, templates and supporting documentation of The Agile Security System so you can apply whatever aspects you feel relevant.

Note that while this second Level Setting exercise can be completed in a couple of hours, you will have the entire week following Module 3 to complete the exercise, and, because there’s no right answer, you are free to engage with myself and the rest of the cohort on Slack if you have any questions or problems along the way.

Why You Shouldn’t Take This Course

Right now you might be thinking to yourself, “Hey, this sounds like it might be interesting.” Or you might even be saying, “Wow! This sounds fantastic! Where’s the Enroll Button?” Or you might be stuck in the middle of the road, trying to figure out if this is the right use of 7 weeks of your time and a chunk of your cold, hard cash.

Regardless of what you’re thinking, I want to make sure you have a crystal-clear picture of what you might be considering getting yourself into. There’s a saying that goes, “Africa’s not for sissies,” and the same may well be said about this course. It’s certainly not for everyone, and here’s just a few reasons why…

It’s a lot of work.

It’s 5-10 hours a week, and if you’re trying to moonlight this course in addition to a full-on, hectic work schedule without any support from your management, then I can tell you from the experience of past cohort members, “it will almost break you.”

So if you feel there will be an issue allocating the time required, then I’d urge you, hand-on-heart, to sit this one out. I don’t want you to struggle, and I certainly don’t want you to be overwhelmed by the additional intensity and deadlines of this course on top of all the other commitments you’ve already made. It’s not good for you, and, ultimately, it’s not good for me either, because I won’t be able to deliver what I’ve promised if you’re not able to do the work.

It’s not official SABSA Training. 

We’re only going to cover a specific sub-set of SABSA, and, actually, you might learn things here that you’ll have  to “unlearn” if you want to successfully pass the SABSA Foundation Certification exam. I don’t know, because I haven’t taught it for over 4 years, and I also don’t know  what the  test questions are. But if you're looking for this to course to give you some kind of official SABSA certification, then this course most emphatically is not for you. To get that, you should go to the SABSA Institute website and find an official course near you.

You may balk at the amount of “non-security” content and time spent.

If you’re looking for a solely-technical, jargon-filled security architecture development course, then this isn’t for you either. This is not a technical course, and, for the most part, it's about “the other skills” you need to have as an architect beyond the basics of modeling, memorizing control libraries and remembering security solution blueprints on demand.

Sure, there’s some “technical” theory, both about architecture and SABSA, but there’s also 12 lessons in Module 2 that have absolutely nothing to do with “architecture” per se, and instead give you a crash-course on understanding what’s happening in the minds of our most important security customers.

Weekend work might be an issue for you—especially if you have a family.

This course potentially is a 1x7x49 investment of your time and energy. There are required activities to be done over each weekend for the 7 weeks of the course, and that also includes being able to allocate 5-10 hours out of each working week too. Some people don’t have the flexibility to do this. And that's totally OK. I have a young family too, and weekends are…hard.

However, if you want to improve your security architecture chops, it isn’t going to happen by magic. It takes work. Lots  of work. And, just like our print Security Sanity™ newsletter, this course isn’t for tire-kickers (theres no guarantee, and no refunds). It’s for people who are ready to take their careers to the next level and who are aware of – and committed to doing – the work required to get there.

My name isn’t John Sherwood, David Lynas or Andy Clark.

While they’re dear, personal friends of mine; I learned SABSA from and I did SABSA implementations shoulder-to-shoulder with David; and I’ve been personally mentored by all three of them in different areas of my life and career over the last 14 years, I’m not them. I didn’t write the SABSA Blue Book. I didn’t write the SABSA Training materials (well, except for the first attempt at the official SABSA-TOGAF integration special seminar, but that's a story for another day). And, in fact, the only official certification level I have in SABSA is the SCF Foundation. So if you're impressed by names, titles, certifications and all that jazz – and its a show-stopper for you – then it’s clear that I’m probably not going to be able to teach you much of anything.

My delivery style might drive you bonkers.

Let’s just say that I've been told I'm an “acquired” taste—much like the first time you got into booze. It just takes a bit of getting used to before you can appreciate it.

While this isn't true of everyone, it’s probably a good idea to go have a quick read through random posts on the Archistry blog to get a feel for the kind of viewpoints on everything from dead frogs to security architecture to the latest security buzzwords like “Zero Trust” before you get yourself into this and then balk at what you see, because…

There’s no guarantee or refunds, and full payment must be made before the course starts.

That’s right. I used to do a double-your-money-back guarantee and had a whole set of interventions built in to make sure you had all the hand-holding you required to be successful in this course. However, what’s become clear over the last couple of years is that the people who need this…the people who require a guarantee…they’re really not the kinds of customers I want to help, and in some cases, they’ve turned out to be the types of customers I can’t actually help—because they either weren’t ready or because they weren’t able to commit to doing the work.

Again, if this is a problem for you, or, certainly, if you don’t believe that I’m qualified to teach you the things I’ve talked about so far in this letter, then by all means: don’t bother enrolling in the course. I don’t want either of us to waste our time and energy.

What I can promise you is that I know the system works, and I know that people who have put the time and effort in to doing the work required for the course have been able to dramatically change the way they work, and they’ve become much more effective at delivering architectures that truly support their organizations.

It’s all here for the taking, but the knowledge and skills I teach in the course are not going to magically sprout in your brain like wildflowers after the first spring rain. It takes time, it takes effort, it takes commitment, and – most importantly – it takes an open mind about what the role of a security architect – and security architecture itself – are in the context of your organization's security program.

Well, here it is. Decision time.

Bear in mind: if you click the button below, you acknowledge that you have read and understand the terms of this offer, specifically that there are NO REFUNDS and NO GUARANTEE that you will achieve any results of any kind by participating in this program.

So, if you've read all of the above, you understand the amount of work that's involved in joining the course, you're prepared to make the commitment to 5 to 10 hours per week – including a commitment to support the cohort by doing your assigned peer reviews over the weekends – and you're certain you're ready to join the next cohort of Building Effective Security Architectures, then go ahead, and click on the button below to...

ENROLL NOW!

I look forward to having you in the course,

Andrew S. Townley
Archistry Chief Executive

P.S. There are a maximum number of slots for the program, so there's no guarantee that there will still be enough space left in the cohort should you decide to wait closer to the deadline. Further, I fully reserve the right to change the quoted price of the course AT ANY TIME prior to the start of the cohort, so the only guarantee you will have of getting the current pricing is by submitting the payment form on the next page. Don't be surprised if it changes the next time you come back if you're unsure whether you're able to commit to the terms of the course.