Defensive Architecture is your best approach.

Defensive Architecture

I drive my business partners and clients nuts at times. The biggest fights we have, which are respectful and usually produce awesome results, come down to my insistence on Defensive Architecture (I’ll explain that in a bit). I was just bantering with one of my business partners about the frustrations that it drives. The funny thing is that the two of us have stood strong on both sides (me insisting we cut that corner to make a deadline – until I understood why we couldn’t – and the same from him).

When you’re delivering cutting edge projects you’re balancing on multiple knife edges. We’re asked all the time to deliver faster than possible and we generally do well. Sometimes there are corners that we can cut (e.g. polish the UI/UX later, shift some of the logging to later sprints, delay features) – but there are times where I stand like a rock. It drives them insane.

Defensive Architecture is one of these areas.

So… what the heck is DefensiveArchitecture?

In my potentially naive sounding way I define Defensive Architecture as using architecture to protect the system you’re creating from itself. Any large system has many pieces and those pieces change over time. There are many reasons for change but I’ll focus in on the two reasons that create the most catastrophic impacts.

You see, when something fundamental to your system changes it shakes the whole system.

So what do you do? You put it in a box that protects you from the change. That’s Defensive Architecture.

Those two cases that I mentioned – where Defensive Architecture is an absolute requirement with no exceptions – are:

• Bleeding Edge Tech
• Avoiding Vendor Lock-in

Defensive Architecture for Bleeding Edge Tech

When you’re using bleeding edge technology and the APIs and SDKs are either non-existent or radically changing. The general ideas and concepts may even be shifting so these APIs and SDKs are pretty much guaranteed to shift – potentially radically.

Some groups get upset that the underlying components are changing – and to them I say that they may be playing in the wrong space. Innovators understand that the biggest innovations have churn. It’s normal, expected, and natural. The dumb move is pretending that you know everything. Nobody does.

Defensive Architecture to Avoid Vendor Lock-In

Most of the projects that I work on are based on open standards and open approaches. This means we can’t allow a particular vendor to be in too much control of our destiny. Frankly, allowing any vendor, even our best of friends, to control an architecture is not allowable. There are many reasons for this:

• Business focus change – It is quite possible that your vendor may change their business focus – what happens if they shift their focus and aren’t quite the same fit or that their API/SDK drifts enough that it is different enough that it breaks all over our system?
• Allow future options – There may be better options in the future. New players arrive on scene all the time.
• Contract stranglehold – the worst contract negotiation results come when there is one side that know the other requires them. I’d far rather know that my partner wants to work together in good faith. If they know that my system is dead without them bad things are going to happen.

So building a box helps here – meaning if the relationship with a partner changes they can be replaced. Changing out a technology partner will never be painless but if you don’t plan for it your system will likely be fatally wounded when something major shifts.

An Example of Defensive Architecture

I’ll throw out a sample client project that I am proud as heck of. I am only involved lightly as the team here is incredible. The BC Government led Verifiable Organization Network (check that link for some great detail) is making- they’re making huge progress and the lead dude insisted we protect from the natural churn. We’ve seen some radical changes but because we were defensive for BOTH of the reasons in this article, the team is kicking serious butt.

We’re using Sovrin on this project to be our anchor point for the Verifiable Credentials that the VON holds for corporations. Sovrin and the Verifiable Credential approach have really been moving targets. Sovrin for example, has started to find its own but to say it has evolved a bit understates some of the massive changes that have happened. I need to add that this churn is completely natural. Sovrin today is maturing – but that’s like saying that your kid can finally sort of walk. We all know that in a year Sovrin will look quite different. If we don’t plan for that change – some evolutionary and some revolutionary likely – we’re not being smart.

Some changes in Sovrin have resulted in some genuine headaches – but those are the ones where we are well aware of the learning and paradigm shifts that have come. This team is active and knows which parts are relatively solid and which ones are, to use one of my favourite technical terms, “squishy”.

The Downsides of Defensive Architecture

Here’s the cool part – there is no downside to having a Defensive Architecture approach to your system. There is likely a time cost initially to “build that box” around the pieces but I don’t even consider it extra time. When an underlying piece of your system changes – you’ll feel a bit of pain as you adjust – but you’re not tearing down your whole system because one little component changed.

ummm …

OK – there may be one downside. The initial effort can be considered “higher”. But that thought and line of thinking is deeply flawed. As I’ve said before there are many areas that Defensive Architecture applies to and some are required. Even the “optional” use for me, mandates using Defensive Architecture. Frankly I consider it as a filter about the pragmatism and sophistication of the company or client that I am working with. If there is a steadfast refusal to use Defensive Architecture or an insistence that it will take too much time and should be cut I see red flags. Those red flags almost always manifest and I’ve learned to walk away or stand fast. If standing fast isn’t an option, I move on to other projects.

So where am I seeing this approach? Everywhere.

So protect yourself. Use Defensive Architecture.