Even if you’ve struggled to apply SABSA in practice for years, you can still

Start Building Business-Driven Security Architectures with SABSA® Today!

If you’ve ever sat in exasperation and wondered if it was humanly possible to apply SABSA® in an easy and practical way after being overwhelmed by all the official guidance and training out there, I can tell you for a fact:

You are not alone.

My name is Andrew S. Townley, and I’m a security architect. I’m also a security architect who uses SABSA each and every time I even so much as think about security architecture. And, nearly 20 years after I first met John Sherwood and discovered SABSA, I can tell you that at this point, I can create a SABSA security architecture of any organization, situation or problem…

…almost automatically, in my head, and without a whole lot of effort.

Of course, it wasn’t always this way. Like you, I thought I understood the basics of SABSA pretty easily, both after I read the “Blue Book” and going through the official Foundation training program.

But then the first time I actually tried to do it myself…

…I felt a little overwhelmed and lost.

I was left asking myself:

How does it all fit together?

How much of it do I actually need?

And even, does it really need to be this hard?

What I eventually figured out was not only the answers to all those questions. I also figured out what the “inner core” of SABSA was and what it was all about.

In the end, SABSA isn’t the iconic SABSA Matrix at all.

Instead, it boils down to just three things:

Domains to collect the things you care about…

…attributes to give you a way to measure the value those things provide…

…and a governance model of trust relationships that connect everything in your world together.

Everything else is just commentary about the way those three core concepts fit together. And, once you realize this too, it’s nothing short of…

A huge weight off your shoulders!

Almost everyone I’ve ever met who’s tried to apply SABSA at some point or another was overwhelmed. And many have even given up and tossed it in the bin as something that’s too big…

…too bloated…

…too old…

…too complex…

…too detailed…

…and just plain too slow to be useful.

This perceived weight has crushed the life out of more SABSA adoption projects than I can count, and who knows how many certified SABSA security architects. And then there’s the architects that just collect the initials to put after their name, don’t even try to use it, push it to the side, and ride off into the sunset of the next big thing, never again giving it even a second look.

But that’s a shame, because once you understand what SABSA’s really all about and how it fits together, you realize that all those frameworks and details are really there to show what’s possible, and for completeness. And they also just happen to be hooked together thanks to those three basic concepts I mentioned before.

The problem that you, me and most of the other architects out there trying to apply SABSA successfully to build business-driven security architectures face is that we just can’t see this simplicity. In fact, I’d applied SABSA for about a decade before it really clicked—and I’m not talking about just whipping up a few attributes, metrics and measures either. I’m talking about working deep in the trenches with security teams committed to adopting SABSA as part of what they were doing. It took me about a year of sitting down, digging through everything I could find about SABSA…

…and then pulling it apart, looking at all the pieces and trying to figure out what they really all meant…

…so I could come up with a way to put them back together into something integrated, coherent and articulated in a detailed process that also described each and every possible artifact you might ever want to create or associate with your security architecture within a global, multi-cultural organization.

The result was something I call the Cybersecurity Edition™ of the Archistry Execution Framework™ (AEF), or ACS for short. It unifies all of what’s available about SABSA into a coherent, integrated process, regardless if you’re trying to talk about using SABSA for security architecture or as a risk management framework. It doesn’t matter—because, in fact, you have to do the same work either way. That’s part of what’s really powerful about SABSA in the first place.

However, the problem with ACS was that it still hid the core of what was really important about SABSA – and security architecture in general – under all those process and artifact descriptions. Yes, they’re correct. And yes, they’re useful.

But, if you asked me how I did it, I didn’t follow the ACS process. I didn’t do a bunch of detailed steps. I had a more straightforward…more intuitive way of “feeling” my way to the right kind of architecture.

And, after trying to explain to many of my clients that a detailed architecture process was hardly a replacement for a good security architect…

I “rewrote the book” on how to apply SABSA to build security architecture.

The result wasn’t really a book though. It was the 2nd issue of the print Security Sanity™ newsletter, where I was trying to explain what I did to apply SABSA in an iterative and Agile way—without getting bogged down in the process. I did a deep-dive, introspective look at the way I really did security architecture myself, and I looked for what the “secret sauce” was that actually made it work. But I wanted to look deeper than that. I was also looking for what it was that allowed me to do it fast, accurately and in a way that delivered actionable results, regardless of what kind of organization, solution or environment I was dealing with.

The result was what I call The Agile Security System™, and since I first published it back in August of 2019, I’ve been using, teaching and refining it so that it continues to get even better doing what I claimed it could do back then:

Help you reliably, quickly and consistently build business-driven security architectures—even if you’d never been able to do that before.

Most people don’t have that opportunity. Most people I’ve talked to – and I’ve talked to several hundred people about their individual experiences with SABSA at this point – have a similar story to the one a security architect by the name of Terry has to tell about his experience before he found The Agile Security System and participated in the 7-week, intensive – and expensive – Building Effective Security Architectures (BESA) program.

Here’s what he told me about his experience with SABSA prior to using The Agile Security System:

"I took SABSA training, but you made me understand how to really apply SABSA and to do security architecture and security by design after struggling for 8 years after taking SABSA. I have had no regrets paying for what Archistry produces. I wish I had found you earlier in my career.

Andrew, you really made a difference. After working with you, I know I will be able to respond to any security question or discussion I may encounter.

I have become BOLD where security architecture is concerned.”

– Terry, Independent Enterprise Security Architect and Consultant

And those are his words, not mine. I’m just happy that he’s been able to get so much out of it. However, I also know that not everyone who wants to build security architectures – even with or without SABSA – is confident enough to invest $5,000 and 7 weeks of their life to do the deep-dive immersion into security architecture and understanding the basics of business that BESA requires.

I also know that some people might not yet be confident enough to make the commitment to a subscription to the print Security Sanity™ newsletter or becoming a member of the Archistry Architect’s Club (the Club). It can be hard to “dive in” when you’re afraid you’re not ready yet, or you think that you don’t yet know enough to get the full benefit out of that kind of a regular monthly commitment.

So, finally, after far too long, I’ve decided to do something about it, and I’ve put together something you’re going to see popping up in more than a few places over the coming months. Because, at long last, I’ve cherry-picked the essentials from the expensive BESA program…and I’ve mined a few of the gems from the previous 44 issues of the print Security Sanity™ newsletter…and I’ve culled a few questions from the weekly live Club Calls within the Archistry Architect’s Club to give you a “quck-start” guide to…

Getting Started with The Agile Security System™

It’s short. It’s focused. And, if you’re determined enough, you can read the whole thing in about four hours. This was by design, because I wanted to come up with a way to introduce people unfamiliar with SABSA to the latent power within it few people get to experience themselves—let alone discover. I wanted to help people who’ve tried unsuccessfully to make SABSA work for them in the past and give them a new opportunity to focus on the most important parts…

…so they can finally be able to do the right kind of security architectures.

The kind of security architectures every organization needs. The kind of security architectures that aren’t focused on technology, threats and vulnerabilities.

The kind of security architectures that are focused on the essential elements and concepts of the organization you’re trying to enable and protect…

…and the important network of value-creating relationships that actually enable your organization to do whatever it is that it does to make it unique and viable in the marketplace.

The difference is that instead of trying to figure out SABSA all at once…

…you’re guided by the 7 Principles, 14 Practices and 3 Baseline Perspectives™ of The Agile Security System so you stay focused on what matters…

…aren’t overwhelmed by the complexity that often crushes architecture efforts under their own weight…

…and never again have to start from a blank sheet of paper, sitting there wondering not only where to start…

…but what’s actually most important to the organization.

It’s all covered – briefly, yet in enough detail – so that after reading this Getting Started guide, you’ll finally have a repeatable and reliable way to tackle any architecture work you’re asked to do—no matter what kind of work it is. Because not only does the Getting Started guide show you SABSA in a way you’ve likely never seen it before…

…it also gives you detailed descriptions of how to use those three core concepts to build security architecture…

…coverage of the Principles, Practices and Perspectives of The Agile Security System you’ll be using as you build it out, along with guidance on which architecture development approach you should use when it comes to choosing between…

The three ways you can apply SABSA to build security architecture.

If you’ve been through the official SABSA training – even when I was presenting it – you were told that there’s really only one way to build true architecture. What was that way?

From the top down.

And we told you that because it’s really the only way to make sure that you’re building the correct kind of security architecture that passes the “Goldilocks Test”—which is not too many security controls, not too few, but just the right amount, and in the right place.

Unfortunately, this also leads to one of the more common criticisms of SABSA I’ve heard from fellow security architects:

You can’t use SABSA on anything but new, “green field” projects.

Now, clearly, these people weren’t paying attention to the rest of what was covered in either the Blue Book or the Foundation program, because that simply couldn’t be further from the truth. However, this is still such a common misconception, that I not only call it out specifically on Page 69 of the book, but I devote a chapter each to using The Agile Security System to apply SABSA when you’re building architecture the only three ways I’ve ever done it:

  1. Top-down,
  2. Bottom-up and
  3. Middle-out.
Now, if you’ve been reading my daily emails for awhile, you probably heard me talk a bit about these different approaches from time to time. And, even if you didn’t, I’m sure you’re familiar with the first two. Nearly everyone is.

However, the last one, the “middle-out” architecture is something I’ve found so essential to my work as a security architect over the years that I gave it a special name. I call it Architecture Archeology™, and I call it that because it’s all about “discovering” the architectures of the things around us we take for grated most days.

In fact, it’s about discovering the inherent and embedded architectures of everything from our entire organization…

…to the security policies we’re meant to be enforcing…

…and even to the control libraries and standards to which we’re supposed to comply!

All of them have an architecture—if you know how to find it. And, starting on Page 72, based on everything else you’ve read up to then in the book, I tell you all about how to go about doing exactly that so you too can…

Discover the architecture in anything!

I mean it. All it takes are a few SABSA “tricks” I show you in the book, and before you know it, it’s right there, in front of you. And not only that, but you’ll also be able to capture and reflect the architectures you “unearth” using the Architecture Archaeology approach using the pre-defined domain frameworks of the Baseline Perspectives™, the models that give you a consistent “architecture GPS” and lifeline so that no matter what you’re talking about, what you’re taking apart, or the kind of problem you’re trying to solve…

…you’ll never get “lost” as to what it all means in the “bigger picture.”

Because establishing – and using – that “big picture” view, even for a single security control deployment or software solution, is one of the most missed and under-used aspects of security architecture I’ve ever seen. People just don’t generally do it.

And if they don’t do it, then there’s no way that your security architecture can fulfill its ultimate purpose which is to help people make better risk-based decisions about the way they do whatever it is they’re trying to do.

That’s the point, and the sooner you can get there with your own architectures, the better. That’s the reason why I crammed so much into such a short little book. It’s not intended to replace any of the more in-depth materials you’ll find from me or anyone else.

But it does what it’s supposed to do by giving you a small, focused and easy-to-reference reminder of what the essential things are a security architect needs to do when they create or consume a security architecture.

Here’s just a sample of what you’ll find packed into this small, powerhouse of a book:

What do I mean by this? Well, let’s take a break and talk a bit more about attributes. You see, what many people tend to forget is that John, David and Andy never really intended people to use the attributes from the Blue Book “as is.”

I know you probably know this already, but they were really just a big, running example. However, one of the first “tells” of a newbie SABSA architect is that they want to start from the standard taxonomy in the book and just apply the ones they think are relevant…

…rather than doing the work of engineering their own attributes straight from the real business requirements they get from the horse’s mouths. This is often seen as either too hard or even unattainable, so people like to just “cheat” and use the attribute tree.

The problem is that attributes don’t grow on trees—and there are a couple of other examples around the place – including one in the official Foundation materials – that are about as un-treelike as you can get. Unfortunately, the tree seems etched in people’s brains, and if they’d only take a bit of time to do it properly, it’s impossible to ignore the fact that…

It’s a GRAPH, not a tree.

However, to get this far normally requires a far deeper understanding of the role of attributes, the process of requirements engineering, and paying a lot more attention to the attributes they create themselves and how they’re used. Fortunately, that’s not a problem with The Agile Security System, because you’ll never, ever, see a simple attribute taxonomy tree as an example of anything relating to real architecture work in any of what I do.

It’s true, and it’s something pretty easy to forget in the ongoing practice of being a security architect. Most of the time, we’re working in a “time free” zone. In fact, it’s one of the main reasons that the SABSA Architecture Matrix includes the Time column in the first place—because we get so focused on what we’re doing…

We forget about time completely.

Unfortunately, time has a nasty habit of reminding us of its importance—often in the most annoying, humiliating and dramatic ways. And this is even more true when you connect time with the complexity we battle each and every day. However, remembering the time dimension gives us one more fairly sharp knife to wield when we’re attempting to violently encapsulate and tame it so it doesn’t overwhelm us—or our security customers.

This one’s worth taking a bit of a break to talk about in more detail, because of all the SABSA concepts I’ve taught, somehow assurance seems the hardest one for people to really understand—especially when it’s lumped under the “compliance” umbrella as it often is.

Let’s think a minute. What’s the point of assurance at all? Yes, SABSA tells us that it has two faces, that of both Compliance and Audit, depending on the context of where it’s done and who it’s done for. But what’s it all about? The simple answer is the best answer. The point of assurance is…

Making sure you’re doing the right things.

However, a whole lot of time and effort in security is spent on making sure things are done right, a.k.a., optimizing the performance of what it is we’re already doing. Hardly ever do we stop and think about whether what we’re doing is actually the right thing. One of my favorite Russell Ackoff quotes – and there are many – is this one:

“Doing the wrong things right just makes you wronger.”

Because, fundamentally, as he says, it’s better to do the right things wrong than to do the wrong things right. So, if we’re interested in making sure we do the right things…

…we’ve gotta have a way to both validate they’re right and evaluate how well we’re doing them so we can target the improvements we’re trying to make in exactly the right place.

Oh, boy, RACIs, or RASCIs, depending on where you “grew up,” are one of the most used – yet most confused – tools I’ve ever seen that end up doing the exact opposite of what they’re supposed to do the vast majority of the time you try and use them!

That’s actually the real reason I was so excited when I first saw what the SABSA Governance Model can do to make sure you avoid the most classic mistake people make when trying to untangle the complex governance relationships that exist in the modern organization. We’re a long, long way from Taylor’s pice work factory where one person did one job – and only one job – and they were reporting to the guy who was the best at that job because he was the best.

But, give a manager an organizational accountability problem to solve, and the first thing they want to see is a RACI. And the next thing they do is do it wrong, because…

Governance roles are context-specific!

Now, if you think about this for more than two seconds, you understand this implicitly. It’s just that this context gets lost because it’s really hard to represent the required context correctly. Believe me, I know. I’ve gone so far as to flat-out refuse to make a classic RACI for a client because I told them that it wouldn’t help them. They didn’t really like my answer, so they ended up getting someone else who would give them what they wanted.

However, do you think it solved the problem? Nope. Not at all.

Even armed with their shiny new RACI model…

…people were still as confused about who did what, when and why as they ever were.

Eventually, I finally figured out a way to look like I give people the RACI they expect, but it’s not. Because it embeds all the context implied by SABSA’s Governance Model, and it leaves out all the bits that confuse people and cause internal conflict. I even went so far as to go through the entirety of COBIT® 5 and “fix” their RACI models—which was a really fun edition of the Security Sanity newsletter to write, because, as you might remember, the whole point of COBIT is to give you a “governance” framework. It turns out COBIT can't legitimately govern anything once you map it out and apply the SABSA Governance Model to it, showing where it comes up not only short…but sometimes microscopic in terms of delivering what it says on the tin.

I get it. I really do. SABSA is a big, hairy beast once you go through the whole thing in detail, and I still remember my own feeling when I sat down to take the SABSA Foundation exam on Friday afternoon after drinking from the firehose of David’s delivery all week.

And I was lucky, because I was better prepared than a lot of my fellow delegates, because I’d been doing what I call technology architecture of all kinds for many years before I’d ever met David.

However, one of the biggest problems I saw when I was teaching people SABSA was simply related to the sheer amount of material you take in. And, unfortunately, most of the really important stuff is in the first two days…

…but most of what people tend to remember is the last thing they heard or learned—which, in the case of SABSA can unintentionally leave you…

Locked in the lower layers of your security architecture.

A place where, if you truly believe in the value proposition of SABSA, is the exact opposite of where you want to be. That’s why it’s important to step back and really prioritize the frameworks and elements of SABSA so you can stay focused on what’s important, and it’s one of the biggest reasons I focus on what I do as part of what I cover in this Getting Started guide.

Believe it or not, I hadn’t consciously come across the work of Donn B. Parker until sometime a  couple of years ago when I was doing some research for an issue of the Security Sanity print newsletter. I was both amazed and surprised by all he’d done and the contributions he made. Actually, he damn near defined the entirety of what most of us do in security every day—single-handedly through his energy and influence. However, as I read more and more of his work, what really resonated with me was the fact that…

He seemed even more stubborn and contrarian in his approach to security than I am!

Now, those similarities only go so far, however. Because I don’t necessarily agree with some of his fundamental positions on security, “best practice” controls (he basically invented this approach), and the relevance and applicability of risk management to the practice of security—even though I do understand where he was coming from and why he felt this way. But still, it’s impossible to argue with what he accomplished, and it was both refreshing and surprising to discover his control guide principles as a common connection point between his work and the way I approach security architecture with SABSA.

Ok, I’m sure you’re a bit skeptical about this one—especially if you’ve only seen some of the stuff I’ve written about this before, so let me explain this issue a bit more.

Most security architecture documentation falls decidedly into one of two camps. Either it’s delivered in a convoy of 18-wheelers piled high with paper…

…or it’s basically nonexistent—or worse than nonexistent because it looks like a chicken walked through some black ink and then jumped all over a blank sheet of paper.

Nobody has a clue what the hell it’s supposed to mean.

And there’s only one thing worse than documentation that nobody understands, and that’s documentation that’s just flat-out wrong. No documentation is better than worthless documentation, and so, when I was thinking deeply about what I do myself when I build security architectures – and with some fresh “war stories” in mind from some recent client engagements – I decided that it was time to throw out the rulebook most people used when it comes to creating architecture documentation and start over. The results of this exercise are what you’ll find both described and shown via example in the pages of this book.

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 to 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 then 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.

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 Get Your Copy

Now that you know what you’ll find inside and what the book is supposed to do for you as a current or aspiring security architect, you should have enough information to decide whether it’s a good fit for you or not. However, I must caution you that while I know the right audience will get a lot of benefit from this book…

…there’s still a chance that this book might not be right for you.

So, if you’re looking for an up-to-date and in-depth way to learn SABSA or attain your official SABSA Certification, then this book probably isn’t going to be what you want. In fact, because some of the stuff I talk about is not only a whole lot more advanced than you’ll get in other sources of SABSA, but because it also downright deviates and contradicts certain elements of core SABSA canon…

…it just might make it HARDER to learn “proper” SABSA for you than if you’d never laid hands on this book before.

Also, while I’ve been using SABSA “live” and in the field since I first discovered it in 2005, I’m not – in any way – associated with the SABSA Institute, I no longer teach the official SABSA Foundation program…

…and I am not certified as anything higher than a SABSA Chartered Foundation (SCF) architect. If you’re looking for an official SABSA guru or duly ordained SABSA Chartered Master (SCM) as a requirement for being qualified to teach you anything of value…

…you’re looking at the wrong guy.

I know what I know about SABSA from years of practice, mistakes, study, in-depth-analysis, discovery, direct personal mentorship from David Lynas and John Sherwood, working side-by-side with David in the field and from doing what it took to stand in front of over 200 SABSA Foundation delegates for 4 years without coming up short. I’ve taken it apart, and I’ve put it back together—and then I’ve transcended the official stuff to blaze a new trail.

It’s a trail that’s not necessarily incompatible with the well-trodden and official one…

…but it’s bound to raise some questions and challenge some expectations along those lines—which, again, is just another reason why learning from me might make it harder to achieve your SABSA certification goals.

However, if you want to build the most business-driven, effective and relevant security architectures at any scope you could ever encounter…

…and you want to learn how to do it as reliably, repeatably and as fast as humanly possible…

…then it’s time to claim your copy of Getting Started with The Agile Security System right now using the big yellow button below.

I look forward to welcoming you into a brave new world of security architecture.

Stay safe,


Andrew S. Townley
Archistry Chief Executive