Please save the kittens!!!

I had a conversation at work today that seems to come up every few weeks or months. It goes something like this:

"<Big System X> is a complete waste of money. I don't know why we keep it around. <COTS package Y>/<R&D project Z> can do everything we need at a fraction of the cost." 

Statements like this make me want to hurt kittens. It's not that I have anything against kittens (what kind of monster do you think I am??), but it's better than getting violent with a co-worker. This particular colleague is a bit of a "visionary", so I've learned to be tolerant of his frequent outbursts. And I've worked with him for several years at this point, so he knows that everything I say to him is meant with love and respect for his many talents.

The problem I have is with the period at the end of his sentence. You see, it's not really a period. It's a comma. It's a comma that begins "assuming...." and starts a long list of assumptions that go from A to ZZ. And you know what? The folks that built <Big System X> would have loved to have those assumptions in hand when they started writing code. They weren't given that luxury.

I've heard the Pareto principle applied to software complexity - meaning that 20% of your requirements drive 80% of your complexity. This certainly seems true in the systems I've worked with...if anything it may be overly conservative. 

For the systems I deal with, security is one of the biggest drivers in difference between <Big System X> and <COTS package Y>/<R&D Project Z>. My customers have to balance the competing "obligation to share" with an "obligation to protect". Failure to do either correctly can mean serious damage to national security. (And yes, it can put lives at risk, but let's not be overly dramatic here.....)

To be just a slight bit more specific, I'm talking specifically about what's known in the business as "ABAC" - Attribute Based Access Control. This is different than RBAC - Role Based Access Control - in that access decisions are much more involved than simply "does the user have the right role". It's more along the lines of "given that this person has <clearance>, <compartments>, <citizenship>, <etc>, what can they have access to??" It requires serious consideration of how data is stored, labeled, and accessed. 

When I describe these challenges to COTS vendors, I often receive "hmmmm....that's not something we've really thought about". Similarly, my customer's internal R&D projects often choose to ignore key aspects of this, because they're trying to prove out a concept...they'll figure the security piece out once they've demonstrated that the concept has potential viability. And quite honestly, I completely agree when we're talking about "basic" research. But all too often I encounter R&D projects that are "ready to transition" but haven't addressed many of the basic security items.

I'm getting a bit long-winded here, so I'll try to wrap up. Please don't take this as my saying <Big System X> is perfect and the way we need to operate going forward. It may, in fact, be a pig. But most of the integrators I work with these days understand topics like modularity and service design. They're trying to build systems that are robust, scalable, flexible, etc. They're working to implement agile methods and DevOps practices (which are probably topics for other posts). But at the end of the day they're expected to deliver solutions that address 100% of their requirements. Not the 80% that <COTS package Y>/<R&D project Z> address. If we want to change policies/operating practices to eliminate some of the requirements and the corresponding complexity, by all means let's do that. Believe me when I say that integrators take no joy in creating "Frankensystems".

Lastly, please, please, please don't start babbling to me about "minimum viable product" (although I myself have been guilty of using this term in certain contexts). You'll be putting those kittens in danger again. In my opinion, security is a necessary pre-condition for "minimum viable". How it performs security functions is certainly open for discussion. But we must, in the words of Stephen Covey, "Begin with the end in mind."