How To ELIMINATE Costly And Frustrating Security Bottlenecks By Building An Effective, Business-Driven, Enterprise Security Architecture Without Spending Months Creating Models And Spreadsheets Of The Entire Infrastructure Before You Can Actually Use It!

Dear Frustrated Security Architect,

I don’t know about you, but I started my career as an architect without really knowing what it took to be effective. At the time, nobody really taught you how to be an architect. You were just supposed to somehow “figure it out” along the way as you progressed and evolved from being an engineer.

By the time I was “doing architecture” in the mid-90s, the whole discipline of “software architecture” as a separate entity was only just emerging.

There weren’t a lot of books on the subject.

Google didn’t exist yet.

Netscape Navigator was far and away the browser of choice.

And there weren’t the endless stream of online blog posts, videos and education programs out there that we have today.

Today, there’s a lot of advice floating around telling you what you should be doing as an architect…

…but even still, almost 30 years after I started my professional career…

…there’s not that much out there telling you what you should be doing as a security architect to really make a difference to the organization you’re trying to protect right now.

Sure, there’s lots of tactical advice, reference architectures and “best practice.”

But the problem with the vast majority of this advice is that it doesn’t really talk much about being an architect.

Instead, it talks a whole lot about how to use, configure and integrate specific architectures using specific security mechanisms and controls.

Unfortunately, what it really means…

…is that most “security architecture” information you can easily find today…

…teaches you how to be a security engineer.

It doesn’t teach you how to be a true security architect.

Because if you’re focused on the technical aspects, APIs, configurations and controls of a particular system, platform or environment…

…all you’re really learning to do is use a tool.

What you’re not learning is:

1. whether that’s the best tool for the job; and
2. how important that tool really is in the bigger picture.

The only way you can answer those questions is to do something different than what most “security architects” today are asked to do.

To answer those questions…

…you need to learn how to build risk-based, conceptual models of your organization and the way it delivers value to its customers.

And you can’t do that…

…if you’re stuck down in the engine room, focusing on technology risks, vulnerabilities and whether or not a set of recommended controls has really been implemented or not.

My name is Andrew S. Townley, and I’m a security architect. However, I’m also a generalist architect. I’ve designed applications, systems, complex solutions and whole-scale enterprise architectures for organizations around the world—both big and small.

Over the last 30 years or so, I’ve learned a lot about what it means to be an architect. And I’ve also spent a lot of time – nearly the last 20 years – building security architectures.

In this time, I’ve used a lot of different methodologies. I’ve used TOGAF®. I’ve used SABSA®. And I’ve even “rolled my own” architecture frameworks—more than once.

What this experience mostly taught me was…

…how to use fancy – or not so fancy – modeling tools…

…how to build complicated, interlinked spreadsheets…

…how to build architecture models…

…how to explain those architecture models…

…and how to build big, fat sets of architecture documentation…

…that very few people ever actually read.

Not only that…

…by the time I was finally “done” crafting my “masterpiece” of architecture documentation…

…it was already out of date.

So, even if anyone bothered to read it in the first place…

…they would’ve probably learned the wrong things…

…and there’s a good chance they would’ve made the wrong decisions because of it.

At the end of the day, that’s all architecture really does.

It helps people make decisions.

And, in the case of security architecture, those decisions are about choosing the best path possible…

…to getting what you want.

Because, part of what I’ve learned on my journey as a security architect is this:

“Security” isn’t about a lack of vulnerabilities or exploits in a technology system.

“Security” is a feeling.

What “security” really means is that you have a certain level of confidence doing what you’re doing…

…that the way you’re doing it…

…is going to give you what you want.

Said another way, “security” is the degree of confidence someone has that they’re going to achieve their objectives.

This is true because it takes a lot more than technology to get things done. So, if you don’t have an approach to security architecture that doesn’t allow you to account for, model and understand all the important interactions within a given system…

…then you’re just setting yourself up to fail.

When I discovered SABSA back in 2005 while speaking on a panel with John Sherwood at a sleepy little security conference in Croatia, I didn’t initially realize how powerful it could be.

I talked with John at the conference.

I bought the book.

I started using attributes in my “regular” architecture work.

But I was still really missing out on the most innovative and powerful aspect of SABSA.

I just couldn’t see it.

And then, once I went through the official Foundation program with David Lynas sometime later…

…and especially when I started both implementing and teaching SABSA working directly with David as both a friend and mentor…

…it started to sink in.

The real power of SABSA is in the way it defines and uses the domain concept.

Once I understood that – really understood it – which, by the way, took quite a bit of time and deep thinking to dig into the core, underlying theory that most people simply never manage to discover…

…I realized how truly powerful and capable SABSA could be when used as the basis of building the conceptual architectures of any kind of system—not just technology systems or as part of developing security architecture the way it’s explained in the book and Foundation.

It’s at that point I was able to finally define my own approach to building security architectures with SABSA that I call The Agile Security System™. And, in the process of building The Agile Security System, I also discovered…

How to use only 7 Principles, 14 Practices and 4 Perspectives to build a complete Enterprise Security Architecture.

When I tell people this story, most of them simply don’t believe me. And I didn’t initially think it was possible either. In fact, the birth of The Agile Security System came directly after…

…I’d aligned and normalized all 3 official versions of SABSA presented in the book and various training programs…

…and then mapped out each of the 6 core SABSA lifecycle activities into at least 4 levels of process decomposition when building out the Cybersecurity Edition™ of the Archistry Execution Framework™ (ACS). The original, the Archistry Execution Framework (AEF) itself, was my initial attempt to apply SABSA outside the realm of security and technology to create a generic approach for measured business execution.

People loved the process. It was all of SABSA, laid out in pure black and white. There was no ambiguity, interpretation or uncertainty about what applying, using and adopting SABSA entailed.

But it was also big.

And, even though it was reasonably detailed…

…the process of building architecture…

…is more art than science.

No amount of detailed process documentation is ever going to be able to replace the judgement of an experienced architect about which things to highlight and pay attention to when designing a system…

…and which parts to basically ignore.

So, after I wrote it all down, I started to explain it and teach it to people.

But, when I did this…

…I realized that there were a lot of things missing from the detailed process documentation.

Things that were missing because they weren’t part of the process.

They were things that were part of the way you thought about and structured the “process” of building architecture.

Once I realized this, I sat back and I started thinking long and hard about how exactly I work as an architect—whether I’m building security architectures or not.

And it was about this time when I was first exposed to the man known as “The World’s Fiercest Negotiator” – the guy who taught the FBI Hostage Negotiation Unit how to not compromise when lives were on the line – Jim Camp.

Now, negotiation is also both an art and a discipline. It’s also something that can’t easily be documented as a step-by-step process.

So, as I studied his approach to negotiation – his “system” – it occurred to me that there were many similarities and requirements for being able to teach people about security architecture as there were for teaching them how to negotiate.

Inspired by his approach, I defined 7 Principles for building business-driven security architecture. Principles that are fundamental laws or the essential “rules of engagement” which are always true, and which, if you follow…

…can’t help but keep you focused on enabling and protecting what your organization really cares about.

However, the 7 Principles tell you what to do. They don’t really tell you how to do it. That’s why The Agile Security System also defines a set of 14 Practices. These Practices, often used together and to realize, implement or deliver a given Principle, are the fundamental ways of being that all true security architects must master.

They must be practiced, honed and performed to the point that they become so internalized…

…you don’t even realize you’re doing them.

They become habits.

And when they do…

…it makes you a better and more effective security architect.

Looking back with the benefit of hindsight, these 14 Practices are what’s required to execute the various steps of the detailed process definition of the ACS. But since they’re used over and over again as part of building out various parts of your security architecture…

…it simplifies the whole thing considerably to focus on them directly.

However, while the Principles and the Practices tell you where to focus and what to do when building security architectures, there was still a problem.

You were still starting from a blank piece of paper.

That’s when I discovered my third critical insight:

Every time I built a security architecture myself using SABSA…

…I ended up drawing basically the same model of the organization.

Of course, doing the same thing over and over again when you don’t have to isn’t very smart. So, when I formalized all of these things into The Agile Security System, I also created a set of fundamental models of the organization that I call the Baseline Perspectives™.

Each of the Baseline Perspectives shows a view of the way value is created by the organization—both inside and outside.

No matter what you’re dealing with, the elements of the subject of your architecture map to one of the boxes in one or more of the Baseline Perspectives. And since these are general models of “how business gets done” – no matter what the “business” happens to be – it gives you a powerful starting point that ensures you both establish a common framework for communicating about security in your organization…

…and you “never get lost” in terms of understanding how any element in your architecture contributes to the creation or delivery of some kind of business value.

The Baseline Perspectives give you effectively a “business blueprint” for your organization that allows you to understand and communicate the potential business risk impacts resulting from any issues in what’s traditionally the scope of information and cyber security—gaps in availability and access control.

Together with the 7 Principles and 14 Practices, the Baseline Perspectives give you a pre-built structure in which to populate the specific details of your organization’s business objectives, risk exposures, mitigation objectives and the detailed technical and process controls required to implement them—all without worrying about a heavy framework, complicated processes or overwhelming documentation.

By repeatedly applying the Principles and Practices within the pre-built models of the Baseline Perspectives, you have all the structure you need to create, communicate and evolve your organization’s enterprise security architecture. It’s fast. It’s not complicated. It’s reliable. And it’s easy to understand, for both architects and our security customers.

Once I had all these pieces pulled together, I realized that I finally had a reliable, repeatable and easy way to build security architectures that would show people…

How to finally “get” SABSA® by focusing on just 3 core concepts.

Many people misunderstand SABSA. They think because it’s expressed in a 6x6 matrix of 36 cells populated by “deliverables” and 30 “fold-over” cells of “activities” that it’s a watered down, domain-specific expression of The Zachman Framework™ for Enterprise Architecture.

But it isn’t.

The Zachman Framework is a schema that links the fundamental interrogative questions with formalized levels of transformation of the abstract into the concrete—a process called reification. It has a very specific set of rules about the way the rows relate to each other with its roots in ancient Greek philosophy.

SABSA is actually quite different—once you look both beneath and beyond the structure of SABSA’s Architecture Framework also known as the SABSA Matrix. However, most people don’t do this.

Most people don’t have time to do this.

Most people see the 36 cells of the SABSA Matrix as a catalog of deliverables and a “bingo card” that must be completely filled in if you want to “do SABSA.”

Fortunately, most people are also wrong.

Because if you dig deep and look at the way all of the elements listed in the SABSA Matrix really relate to each other…

…an exercise that I spent months working through when I was mapping out the Cybersecurity Edition of The Archistry Execution Framework…

…what you discover is that there’s really only 3 things that matter in SABSA:

1. Attributes that represent measurable objectives or capabilities;
2. Domains that represent collections of elements subject to the same set of risks; and
3. The governance relationships between domains that express a value delivery network.

All the rest of it – all the stuff in the book…the official training materials…and even within the SABSA Matrix itself – are either…

…ways to define domains, attributes and the governance relationships required to deliver value…

…or ways to use those definitions to guide the creation and implementation of the physical manifestation of those value delivery networks and the concrete security controls required to protect them.

That’s really all there is to it.

And, once you discover this…

…what you also discover is that, at the end of the day…

…SABSA’s really not nearly as big, bulky, complicated or hard as people make it out to be.

It means that it doesn’t require some big, heavy and formalized structure or mechanism like the detailed processes of the ACS…or TOGAF…in order to apply it successfully.

This fundamental realization about SABSA means that it’s actually the only formalized framework I’ve ever encountered that allows you to focus on what’s truly essential to building and communicating the conceptual models of your organization…

…so you can leave the rest of the details to the specialists.

However, this doesn’t mean you end up being an “ivory tower” architect. Far from it.

What it means is that you can use these core concepts as formally – or informally – as you need…

…so you can build clear, easy to understand security architectures…

…suitable for everything from a 20-year strategic plan…

…to a 20-minute emergency, incident response phone call.

Something which most people would never believe you could do using a formalized methodology of any kind—let alone using the SABSA most people seem to understand.

By simplifying SABSA to it’s true essence, you don’t leave anything behind. It’s all still there for you to use—as it was intended.

But it means that rather than being a “toolkit” where you can pick and choose the parts you want…

…what you truly have is an integrated, essential toolkit for building conceptual architectures…

…along with a list of potential ways to structure and communicate them to your security customers you can pick and chose as required for the best possible impact.

Most importantly, it means that if you’ve tried to learn or apply SABSA yourself in the past and couldn’t make it work…

…it’s not really your fault.

You just weren’t able to see it the right way. You weren’t able to focus on the parts that mattered…

…because you were likely overwhelmed and thinking that it was an “all-or-nothing” exercise that…

…if it were even possible to do…

…would take you months – or even years – to complete by the time you’d mapped out, cataloged and linked everything referenced in the SABSA Matrix.

The good news is that it’s not nearly that hard. And you can “do SABSA” much quicker, much easier, and much more consistently than most everyone thinks.

And the way you do that is simply by focusing on the 3 core concepts. The rest will work itself out—even if you don’t yet know…

How you can start building business-driven security architecture TODAY even if you don’t think your organization is “mature enough” to let you do it.

One of the biggest consequences of SABSA being misunderstood is an assumption by most people that the only way to get started building business-driven security architectures…

…is with direct, overt and explicit “buy-in” from executive leadership—or at least the CISO.

While this is certainly the ideal situation, the reality is that very few people really understand what “business-driven” means—especially when it comes to security architecture.

And, if you suddenly show up with yet-another-framework with a whole bunch of processes, assumptions and requirements for using it…

…there’s a good chance that it’ll be rejected without even a second look.

Most leadership teams – and especially security leadership teams – are overwhelmed. Unfortunately, they’re often overwhelmed precisely because they’re trying to do what “best practice” tells them they’re supposed to be doing.

They primarily understand “security architecture” as a technology artifact. It’s the models of the way the physical controls are deployed and connected within the operational IT infrastructure.

“Security” is focused on keeping that infrastructure from getting exploited by a never-ending, ever-changing set of attacks, and it’s such a sprawling, complicated collection of vendors and components, that everyone stays in a constant state of “high alert.”

If you’ve experienced this yourself, you know the truth.

It’s not sustainable.

And adding more people…more tools…and more resources…

…just makes more noise.

It doesn’t really solve the problem.

Which leaves you with a bit of an impasse. Management is too busy fighting fires to evaluate alternatives…

…so until the fires go out…

…very little is likely to change for the better…

…because only things that seem aligned with what “best practice” say should solve the problem are actually going to get done or implemented.

Unfortunately for most organizations, the only way to rise above the noise and focus on the business…

…is to build the right, business-driven model of the way value is delivered in the organization.

Because only once you have this kind of model – this kind of architecture – are you able to really see what’s happening…

…what’s important…

…and make informed decisions about where to truly focus the resources you have right now for the maximum impact.

This means that the reality for most security architects today is that they can’t spend time doing architecture…

…because they’re spending all their time doing other things.

But here’s the thing:

You have the power to change it—just a little bit.

And quite often, it only takes just a small change in the right place…

…to have a pretty-big impact.

So, where am I suggesting you should make this change?

I’m suggesting you make this change in the way you work – every day – as a security architect.

Because, going back to put on the shoes of the executive leadership team, what they really want to do is make things better.

But the problem is, they’re either not sure what options they have…

…or they’re not confident any one of those options will really make a difference.

And so, human behavior kicks in, and the thinking shifts to:

“Well, if I’m not sure how to make it better, at least I’m not going to make it any worse.”

That’s the definition of getting stuck in the status quo. That’s why we seem like we’re never making any headway as security. We always feel like we’re 6-steps behind the bad guys…

…because we are.

However, the good news is that now you know that you can build security architecture in a fast and easy way…

…and that you have the ability to leverage pre-built models of how value is delivered in your organization so you don’t have to figure this stuff out all by yourself…

…it means that if you change the way you work to apply The Agile Security System…

…you start to build leverage that gives you two things.

First, it gives you more time to think and “do architecture” than you have right now, because you’re spending your time building business-driven architectures as you do anything you’re asked to do.

You’re asked to do a “security assessment” to validate control compliance?

Great. You build an architecture using The Agile Security System to do it.

You’re asked to investigate an operational security incident?

No problem. You build an architecture that helps you identify with precision the true “root cause” and, at the same time, enables you to evaluate whether the “hot fix” solution is fundamentally fit-for-purpose for the long term.

You’re asked for “security input” into a new project?

Fantastic! You quickly flesh out the architecture of the project by leveraging the appropriate elements from the architectures you’ve built solving the other two problems to identify areas where controls should be applied or where alternative, “non-standard” solutions can be shown to not change the overall risk exposure of the organization.

In each case, you’re incrementally building the architecture you don’t have “permission” to build…

…but it’s still getting built anyway.

And, as it gets built, it gives you the second thing I mentioned:

Proof.

Because as you systematically and consistently apply The Agile Security System to do the work you do, people will notice.

People will see your results.

People will ask you about how you’re doing what you’re doing.

And, based on feedback from previous customers and clients…

…people will want to “borrow” some of your tools and techniques to fill in gaps in their own work too.

Each and every time this happens will give more and more evidence that there is not only a better way…

…but that the better way…

…also happens to actually work.

And, once you’ve changed the way you work – even just the smallest bit – you might well discover that you’ve lain the foundation for fundamental changes to the effectiveness of your entire security program.

However, even if you think everything I’ve said up to now is possible, you might also be wondering…

How you can learn to apply The Agile Security System™ to build business-driven security architectures yourself, in your own organization.

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

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 flagship program is actually pretty simple. I want you to:

• Be able to practice the techniques you’ll learn in the program 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 program 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 program 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 program, 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.

And finally, the format of the program 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 program or the 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…

Program Content And Delivery Model.

The program 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 program content will build.

During the first week, 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 program.

Here’s a brief overview of each of the program modules and what will happen each week so you can see how this hybrid approach 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 program—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 program 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, a 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 Program

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 program. 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 program 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 program 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 since 2016, and I also don’t know what the test questions are. But if you're looking for a way to give you some kind of official SABSA certification, then this program 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 program, 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 program 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 program, 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 program isn’t for tire-kickers (there's 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 since 2005, 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 program 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.

You don’t even have to wait. You can start building business-driven security architectures RIGHT NOW!

Now I know that if you’re all excited to get started learning about The Agile Security System, and you’re chomping at the bit to get started changing the way you do architecture TODAY…

…it can be somewhat of a let-down to realize that there’s still a pretty long time between today and when the next BESA cohort kicks off—even if that’s tomorrow, because it's still a 7-week program, and you’ve still got a lot of work to do before you can get started.

That’s why, as an extra special “getting started” bonus to allow those eager-beavers who’ve had some exposure to SABSA already to dive right in and start shifting their thinking about security architecture and how to do it…

I’ve added in your very own copy of the Getting Started with The Agile Security System eBook to the core materials you get with the BESA program!

You might be wondering why I’d do this if the whole point of the BESA program is to learn how to build more effective security architectures with The Agile Security System. You might be thinking that this undermines the value of the program…

...and that it might “give away” a good portion of what you’re going to learn.

However, while it’s true that there’s some obvious overlap in parts of the program, I can tell you from previous experience that people who’ve already been applying The Agile Security System for months on their own thanks to both working with me individually and being a subscriber of the Security Sanity™ print newsletter…

…still LOVED the program.

And the still learned a lot.

Because, let’s face it. This Getting Started eBook is short, focused and to the point. There’s no fluff, and it assumes you have the ability to fill in the blanks and start from what you already know. If anything, it will help you get MORE value out of the BESA program than everyone else who went through it before without access to this eBook simply because you’re already primed to think differently in some specific ways…

…and you’ve had a chance to think about how you’d use and apply The Agile Security System in your own work before.

Everything else will already have a skeleton ready and waiting for you to enhance and train based on everything else that you’ll be exposed to and practice during the 7-weeks of the program.

Ultimately, it just gives you one more resource to help you get the most value you can out of the BESA program, because here’s a very small glimpse of what you’ll find inside this eBook that will be delivered to you immediately on your registration via the Archistry Learning mobile app:

• Why The Agile Security System is different than any other approach to building security architecture. See Page See Page 27.
• The one simple “tweak” I had to make when I taught SABSA Foundation to make the power of SABSA’s standardized RACI really “click” for delegates (which worked so well, other instructors ended up stealing it too). See Page 45.
• Why we’re often forced – kicking and screaming – into doing “bottom-up” architectures (including what we’re really supposed to be doing when we do it). See Page 69.
• A “hidden” truth about the nature of the “deliverables” defined by SABSA (something that both gets unsuspecting architects in hot water and nearly assures the ultimate destruction of many SABSA adoption efforts). See Page 22.
• Why we need attributes as a security architect. See Page 36.
• The only tool you’ll ever need to clearly, easily and quickly define the scope of the security architecture you’re working on. See Page 54.
• Want a more effective security program? Just do this. See Page 18.
• The only legitimate way to achieve – and maintain – true “business alignment” with a security program of any kind. See Page 17.
• Why there’s really no such thing as either “top-down” or “bottom-up” when it comes to doing security architecture. See Page 72.
• Unlock the critical relationships between domains and the systems of “systems thinking” or synthetic thinking. See Page 31.
• How you can realistically apply SABSA successfully while ignoring the rest of the 20+ frameworks it defines (illustrating that it’s no wonder you were a bit lost after the 5-day firehose of SABSA Foundation). See Page 25.
• Why it’s a really bad idea to conflate the concepts of value, price and cost when you’re talking about security architecture—or anything, for that matter. See Page 49.
• A detailed guide to building out a physical Architecture Wall™ that will beg to be updated, foster engagement across your team and help you stay focused on what’s really important about your organization’s security architecture. See Pages 83-84.
• What’s CRUD got to do with it? It’s probably not what you think, and it has nothing at all to do with databases. See Page 33.
• How The Agile Security System extends the core SABSA domain concept to make it even more powerful than it already was. See Pages 30-35.
• The drop-dead-obvious relationship between the discovery of the domains in your architecture – new or already there – that allows you to begin to start “seeing” architecture in your head. See Page 35.
• How to discover the network of attribute relationships in any architecture (just use this one simple tip, and you’ll have more connections between attributes than you’d imagined were possible). See Page 98.
• How a “handful of paper” just may well be the only kind of security architecture documentation you really need. See Page 82.
• …and much, much more, including who our 7 basic types of security customers are and how to figure out what they’re expecting from us (see Page 79)…why “standard templates” for security architecture are the Devil you actually never want hanging around your neck (see Page 81)…the single biggest mistake people make that ultimately leaves SABSA sitting on the scrap heap of your security program (see Page 22)…the 8 most important attributes you’ll ever meet as a security architect AND which you won’t find mentioned in the BESA program at all (see Page 41)…the 3 things to look for to measure your progress as a security architect, regardless if you’re using SABSA and The Agile Security System (see Page 86)…and the surprising “secret” as to why being curious is one of the most important habits a security architect can have right there on Page 19!

What’s Inside the Book

Even though I said it’s a small book, it packs 15 chapters and 7 different appendices into just 105 pages. So, in case you want to get a structured breakdown of what you’ll find in the book instead of just a glimpse of the highlights I’ve covered above, here’s what you’ll find inside.

Chapter 1 gives you an overall introduction to the purpose and structure of the book. It tells you what it is, and what it isn’t. And one of the things it isn’t is a replacement for a deeper introduction and education on SABSA and The Agile Security System like you’ll find in the flagship Building Effective Security Architectures (BESA) program or the official SABSA training.

Chapter 2 introduces you to The Agile Security System itself. It talks about where it came from, why it’s necessary, and some immortal caveats about what it takes to build effective architectures fast. You also get a bit of an overview of my own personal journey from where I started as a fresh graduate with a degree in Computer Science to where I am now—including some of the major milestones and influences that got me from there to here.

Chapter 3 provides the quickest, most condensed and up-to-date introduction I’ve ever given to SABSA—including where it came from, what it is (and isn’t), and what it does to add to the discipline of security architecture. I provide my current definition of what security architecture is, and then I talk about the three core concepts of SABSA and why they’re so important.

Chapter 4 talks about my own journey and evolution in the way I understand and apply SABSA. It talks about my first generalization and integration of the core SABSA materials into a unified framework, and describes what I was trying to accomplish by doing it. I then talk about swinging back, full circle, to SABSA’s security roots and how everything that’s in SABSA is inherently a part of The Agile Security System too—all in one handy, easy to remember diagram.

Chapter 5 walks you through the most important part of SABSA—both to me and The Agile Security System and to the discipline and practice of security architecture as a whole. I talk about how SABSA embraced and clarified the the current state-of-the-art, and then I describe how I’ve both relaxed and extended the domain concept in my own work and evolution as an architect.

Chapter 6 brings us to attributes, probably the second most commonly recognized aspect of SABSA behind the iconic Architecture Matrix. In this chapter, I talk about how attributes work, how they relate to prior art, and, most importantly, how you can learn to create attributes almost effortlessly, no matter what you happen to be working with. Also, since you can’t talk about attributes without talking about how you measure how much of them you have, I summarize the essentials of SABSA’s Performance Management Framework (PMF) and talk about the way attributes are used to express your organizational risk appetite.

Chapter 7 ties everything together by introducing you to the SABSA Governance Model. Now, if you’ve been through the Blue Book or the SABSA Foundation training, you’ll see some things that are familiar. However, you’ll also probably see some things that you might not expect too—because there’s a whole lot more to the SABSA Governance Model than just defining the relationships between the core phases of the SABSA Lifecycle. I don’t even mention that at all in the book, actually.

Chapter 8 introduces what I believe is the most fundamental domain relationship, that between a customer and a supplier. However, these aren’t fixed entities. In fact, and fully in accordance with the SABSA Governance Model and the Entity and Trust Framework, each of these are roles that get assigned to the right actors at the right time so you can truly unpack and uncover what is really happening to deliver value in your organization.

Chapter 9 presents the core domain framework I defined with The Agile Security System based on literally decades of architecture work in the field. I got tired of always drawing almost the same domain models every time, so I defined the Baseline Perspectives™ as a way to short-circuit that work and help me stay focused on what’s really important “inside” the lines. And, if it works for me, it’ll work for you too—especially based on the comments and feedback I’ve gotten from the many people using them every day as part of their own architecture work.

Chapter 10 cuts to the chase about what’s important to capture as part of developing and documenting a security architecture at any scope or scale. It connects the dots between what we’re trying to do as we're capturing and defining security architectures with general systems theory, so that we can have an over-arching formalization to help us do what we’re trying to do without getting stuck in the weeds and overwhelmed with detail. Most importantly, this chapter talks about the two essential modes of thinking every architect must use—and which one is actually the most important and relevant for creating successful architectures.

Chapter 11 provides a high-level overview of what’s required to do architecture the “right” way—starting from the top, as close to the business as possible and working our way down through SABSA’s architecture layers. In the process, it gives some fundamental questions every architecture must answer and then talks through how the Principles, Practices and Perspectives are used to make sure you don’t miss anything important.

Chapter 12 starts at the bottom and talks about what’s involved in doing “bottom-up” architecture. Whether we like it or not, there’s still a time and a place to do it—whether it’s “proper” architecture or not. It’s still useful, and there’s still valid reasons for doing it. This chapter talks about what it’s for, why you’d do it and what to do to make sure the tedium and overwhelming boredom often involved in doing this kind of exercise doesn’t suck the life out of you as a high-value security architect.

Chapter 13 presents what I call the “middle out” or Architecture Archaeology approach to discovering the architecture inherent in anything you’ll ever encounter. It’s fair to say that it’s potentially a superset of the other two, but the purpose of doing it this way vs. the others is very clear, and something I talk about extensively in this chapter. I also tell you why once you start, it might be the only kind of architecture you’ll do from now on too.

Chapter 14 dives into the heart of what many people think is where the whole “security architecture” thing starts and stops. It tells you how to effectively communicate the architectures you build, because going to all that trouble to do it isn’t going to make much sense if nobody but you is able to use it. This chapter talks about the importance of matching your message to your audience, and I present the most important groups of security customers  we normally need to address, along with some tips and guidance on exactly what to say to them when we do it.

Chapter 15 closes the book with some ways to measure your own progress as a security architect and gives you several options and potential “next steps” to continue your skill development and evolution as a security architect.

Appendix A presents the Enterprise Baseline Perspective™ model, including the domains and core relationships that describe the value delivery network of your entire organization, whether it’s large, small and whether it’s for-profit, non-profit or public sector. I’ve successfully used these models in all of those environments.

Appendix B presents the Service Baseline Perspective™ model. This perspective is one of two ways you can take a “slice” through your organization at any scope to match your architecture iteration and ensure that you’re not overwhelmed with excessive or irrelevant details. At the same time, everything you reference in this model automatically has a “home” in the Enterprise Perspective, so it’s impossible for you – or your security customers – to ever get “lost” when talking about something you’re working on.

Appendix C presents the Value Stream Baseline Perspective™ model. Like the Service Perspective, the point of this model is to allow you to “slice and dice” your organization to focus on what’s relevant and important. In particular, this model covers all aspects of your organization, where the Service Perspective may not always be the perfect fit, depending on the nature of the project or problem you’re working on. This way, you have everything you need to deal with the normal architecture iterations that are most commonly done by security architects in one or the other of the two Perspectives.

Appendix D presents the External Baseline Perspective™ model. The purpose of this perspective is to allow you to model the way your organization interacts with the outside world. Not all aspects of your organization do this directly, so this Perspective helps you “zoom in” on the parts that do so you can delve in to the nature of those interactions and identify their implications from a security perspective.

Appendix E defines a set of 55 attributes that repeatedly come up in my own security architecture work. These attributes intersect with the attributes defined by the Blue Book and the official SABSA materials in their names, but the definitions are different to reflect the way I use the three core concepts of SABSA in my own architecture work. These attributes are part of the Reference Architecture I built for the Archistry Execution Framework, but they’re so common that I find it almost impossible not to need them in almost every engagement.

Appendix F provides a set of default Attribute Patterns – recurring relationships between attributes that are inherent in the attributes themselves – that I’ve defined over the course of my architecture work. Sometimes these patterns are the perfect fit for helping you prioritize and place the relevant attributes in your own architecture models, and sometimes they’re close, but they’re definitely not the droids you’re looking for every time. That’s ok, because this appendix also talks about how to use, extend and transform these patterns to make them fit your own architecture projects too.

Appendix G defines each of the core domains included in any of the Baseline Perspective models. While simply drawing a box can potentially define a new domain, they aren’t much good to you if you can’t describe what’s inside them—so you can know what isn’t. These definitions also provide a starting point for you to use as the basis of your own domain definitions so there’s no confusion as to what you’re talking about in your security architecture and why it’s important to the organization.

How To Make Sure Your Investment In BESA Is Actually Applied To The Work You Do

One thing that often happens after a program like BESA is that, despite your best intentions…

…you just can’t figure out how to apply it to your work every day.

I’ve lost track of the number of people I’ve spoken to who’ve been through some kind of certification training program – including SABSA – and yet still seem stuck putting it into practice. Once this happens for very long…

…there’s nothing of value left from the program.

While you might still have the certification…

…that certification is effectively useless since you’ve never actually applied what you learned. Because if you don’t apply something you learn immediately so you develop the practical skills to act on that knowledge, everything you’ve learned simply disappears within a few weeks of the program.

I don’t want this to happen to you with BESA.

The structure of everything over the 7-week program was built so that you can get practical experience applying The Agile Security System in your own work…

…but sometimes, people still get stuck.

People still have questions.

And people still need support.

So, to address this problem head-on, I’ve included – at no extra cost – some bonuses and benefits I’ve never offered before.

If you take advantage of these extra special perks…

…then I’m sure you’ll get immediate and practical value out of your BESA experience…

…and you have every opportunity possible to ensure that you translate what you’ve learned in the program…

…directly to the work you do every day.

Because here’s a summary of everything you’ll get in addition to what I’ve mentioned above:

• A downloadable, printable, 270-page program transcript for easy, searchable reference
• The Architecture Ignition Kit™ Starter Pack of essential templates and worksheets to build out your Architecture Wall™
• 3 months of the prestigious, print Security Sanity™ newsletter
• 3 months of Live Archistry Club Calls as a full and active Club Member
• 3 months of access to the Archistry Club private Slack community
• Full access to the Archistry Club Masterclass Vault
• One FREE pass to a live, in-person Club Conversation™
• Access to the FULL ARCHIVE of over 50 previous Club Calls going back to July 2022

It’s truly everything you need to get the most out of the BESA program—both during and after you’ve completed it. But, in case you’re not familiar with each one of these in detail, I’ll quickly go through them now.

A 270-Page Program Transcript

(Worth $499)

While you do have LIFETIME access to the program content, sometimes you just want to read the words or reference the slides. Sometimes, you just want to look something up.

And with the content spread over the various modules and videos, this would otherwise be hard to do.

That’s why as a special bonus of the program, I’ve put together a full, edited and formatted transcript of the entire program.

Every Module.

Every Lesson.

Every Slide.

It has a table of contents so you can quickly and easily find what you want, and, of course, since it’s a PDF…

…it’s easily searchable too, so you can “zoom in” to exactly what you want to know.

Further, each of the slides is inserted in the appropriate place in the transcript so you can track exactly what was on screen as I was talking in the videos.

And, if you really want…you can even print the whole thing out so you have it sitting beside you on your desk. I don’t recommend it necessarily, but it’s yours if you want to do it.

Architecture Ignition Kit™ Starter Pack

(Worth $299)

In 2023, I created several additional templates and worksheets useful in building architectures called the Architecture Ignition Kit™. The full kit has over 40 worksheets to help you flesh out certain sets of relationships in the Baseline Perspectives.

However, the essential templates and worksheets required to get started with The Agile Security System have been pulled out and packaged together as the Architecture Ignition Kit Starter Pack.

In the Starter Pack, you’ll find downloadable, printable versions of the following:

• The Enterprise Baseline Perspective, External Baseline Perspective, Service Baseline Perspective and the Value Stream Baseline Perspective
• The Domain Impact Worksheet
• The Context Analysis Worksheet
• The Physical Domain Template Worksheet
• The Logical Domain Template Worksheet
• The Security Value Streams™ Reference Model
• The Security Governance Model™

3-Month Trial Subscription to Security Sanity™

(Worth $291)

How would you like to get extended, in-depth and actionable information you can use immediately in your work as a security architect in your mailbox every month—absolutely FREE??

Well, as a BESA cohort member, that’s exactly what you’ll get.

In fact, these issues have been the source of multiple talks at the legendary COSAC security conference, and one of them was once even called the best presentation of the conference by several attendees—and they didn’t get the fully story.

But you will, because you’re going to get the complete issue every month, and you’ll be able to refer to it as often as you like as you put what’s inside to use each month. Some of the most popular issues have covered such topics as:

• How the SABSA® governance model – when properly applied – demonstrates just how little COBIT® knows about “governance”
• A practical framework for describing customer value developed by Bain&Co. mapped against what some of our highest priority security customers care about most
• Why most people completely miss the fundamental issues around what’s involved in successful Cloud Security (and how to describe it better using SABSA’s attributes, domains and governance model)
• The only 4 types of risk assessments you’ll ever need to worry about making sure you do
• How to properly understand the discipline of Enterprise Architecture—well beyond the train wreck that is TOGAF®
• Why you can always start your security architecture with the same set of “Essential 8” attributes, regardless of what you’re trying to “secure”
• A back-to-back set of issues covering a case study using SABSA to analyze the SolarWinds attack and demonstrate why the MITRE® ATT&CK® framework will keep us chasing our tails in security
• The reason security is still only ever about access control (and the amount of leverage this unlocks when you “do it right” and only “do it once!”
• Revealing the embedded architecture of the NIST CSF using the Architecture Archaeology™ approach of The Agile Security System™
• What you need to know if you really want to achieve “zero trust” (and how properly understanding SABSA means you’re more than 80% there already)

3-Month Trial Membership in the Archistry Club™

(Worth $14,434)

Included in your BESA program registration is 3 months of FULL MEMBERSHIP in the Archistry Club™ (the Club). The Club is really the next step in ensuring you have the ongoing support, education and community you need to apply what you’ve learned in the BESA program immediately and as you grow your skills and expertise with The Agile Security System.

Your Club Membership is not restricted in any way, and includes the full benefits and privileges of being a member of the Club. Here’s a summary of what you get.

Live Monthly Club Calls

Sometimes you just need to talk to someone to figure out what to do about something that has you stuck. Fortunately, as a Club member, I’ve got you covered.

Each month you can join me LIVE on the Club Call™! Club Calls are where we gather each month to make sure we keep moving forward and that any issues or dangling threads you have in your understanding of how to make progress are addressed.

Not only that, but here’s a few other aspects of the Club Calls designed to make them as valuable as possible to you every month:

All of the calls are recorded—except where something sensitive is being discussed, and you’d rather the recording be paused as we address your issue

You have FULL ACCESS to the COMPLETE ARCHIVE of Club Calls going back to the very first one on July 28th, 2022

Even if you can’t join us live, it doesn’t mean you miss out. If you submit your question to me ahead of time, I’ll make sure to either answer it on the Club Call for everyone else’s benefit and participation, or, if we run out of time, I’ll record you a special, personalized reply that will also become part of the Club Call archive

The call schedule is fixed in advance, so you always know when we’re going to have them

And if we run out of things to talk about, we’ll just have an open conversation instead about whatever’s on people’s minds that have joined us live

Access to the Private Club Slack Community

One of the biggest challenges we face in our struggle to be true architects is that we often do it alone. Nobody really gets what we’re trying to do. People don’t understand that a true architect is more than just a technical expert in an architecture.

And we often feel isolated and lost when things get tough.

Well, the whole purpose of the Club is to bring like-minded security professionals who are truly interested in bringing a business-driven and risk-based approach to security to their organizations together so there’s no more feeling like you’re the “Lone Ranger” out there.

You aren’t.

And when you’re stuck, you can always pop in to the Private Slack Workspace exclusively for Club members and reconnect.

Because it’s exclusive to Club members, it means everyone knows the rules. And, more importantly…

…everyone knows the consequences if those rules are violated.

But sometimes it’s not about feeling alone and stuck.

Sometimes, it’s about wanting to share in your successes with people who truly “get it” on a more fundamental level than most of the people you engage with every day.

That too is what the Private Slack Workspace is for. In fact, some of the best, most engaging posts are about the wins people have, the progress they make…

…and the unexpected enthusiasm and adoption of their ideas by people outside security!

And, whether you’re stuck or you celebrating…

…the Club Workspace is there for you 24x7x365!

Access to the Club Masterclass Vault

As a security professional, we face a number of different challenges each and every day—and a good many of them ostensibly have nothing to do with “security” at all.

There’s also the fact that, no matter how good something may be written or presented…

…there’s no substitute for actually watching someone do it from “over their shoulder” so you can catch all those things that are either implicit, “understood” or just flat-out “too obvious” to mention in the Security Sanity™ newsletter, a book, or the content of other programs.

That’s where the MONTHLY MASTERCLASSES come in, because this is where I go deeper than I can on a single call or issue of the newsletter to talk about all the things you really need to know – and show you exactly how I do it – each and every month.

Now, I won’t say they’re all going to be “over the shoulder” sessions or case studies of how to tackle a particular task—because there’s a whole lot of other stuff we need to cover too to ensure you’re successful as a security architect and your organization’s security program is as effective as it can be. However, my goal is to have at least 30% of the masterclasses being more “hands on” affairs, with the rest being coverage of the topics, concepts, practices, tactics and related theories or skills I think are essential you know.

Not only that, but you have IMMEDIATE ACCESS to the complete archive of the masterclasses from the moment you join.

One FREE pass to a Live, in-person Club Conversation™

While it’s great to connect virtually at any time of the day or night…

…there’s nothing that replaces direct, in-person human connection. And that’s EXACTLY why as a Club member, you get ONE FREE PASS to the quarterly Club Conversations™—all you have to do is get there.

And remember, the Club Conversations combine learning and community in a unique way so that we learn together…

…about whatever YOU WANT to talk about…

…and we’re not “done” until you say we are!

What’s more, it takes place somewhere that’s gonna be cool…will have great food…and will give you an opportunity to visit places you might not normally go!

It’s like getting access to a BUSINESS-DRIVEN SECURITY MASTERMIND that meets 4 times a year—and you get to come to one of them just by paying the travel costs. This means that the continuing educational value as well as the in-person community, networking and support alone is worth the Club membership dues—and it’s deliberately set up…

…so you can make the case for using your annual training budget, because there’s nowhere else you’re going to get the same kind of career and skill development.

In addition to what it does for you, you also get discounted admission to the other 3 Club Conversations every year—AND you get to give your friends discounted access too! That means you can bring along your friends, colleagues or anyone else you think would benefit…

…and they’ll still pay much less than anyone else…

…all because of you being a Club member!

Are You Ready To Register For The Program?

If you've been following along this far, you know that this is probably the most value I've packed into any offer I've ever put together. I know it's a lot, so I want to give you a single summary of absolutely everything you'll get if you join the next cohort of the BESA program.

Your registration in the Building Effective Security Architectures (BESA) program includes:

• Building Effective Security Architectures (BESA) core program content (normally $4999)
• Getting Started with The Agile Security System™ eBook (normally $65)
• Printable, 270-page full program transcript—including all the slides (worth $499)
• Architecture Ignition Kit™ Starter Pack (worth $299)
• 3 months of the print Security Sanity™ newsletter (worth $291)
• 3 months of Live Archistry Club Calls™ (worth $7399)
• 3 months of access to the Archistry Club private Slack Community (worth $1047)
• Access to the Archistry Club Masterclass Vault (worth $5489)
• One FREE pass to a LIVE, in-person Club Conversation™ (worth $499)
• Access to the FULL ARCHIVE of over 50 previous Club Calls™ starting in July 2022 (Priceless)
• LIFETIME access to the full program content (Priceless)
• LIFETIME access to all 7 of the Live BESA Q&A calls (Priceless)

TOTAL VALUE: $20,587

TODAY'S PRICE: Only $4999

NOTE: Should you wish to cancel your trial Club Membership, it MUST be cancelled before October 1st, 2024 in order to not be billed. If you cancel your trial membership BEFORE the trial has completed, then you will immediately lose all benefits and privileges of the Club, including any pending issues of the Security Sanity print newsletter.

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 program, 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 program,

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 until closer to the deadline. Further, I fully reserve the right to change the quoted price of the program 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 program.

Complete Your Registration For The Program Below