Custom requirements: Making vendors do things our way. Is it doing is harm?

Here is one of the great truisms of data security. It is like the weather joke “you know what they say about the weather here in (insert city name here) if you don’t like it wait 5 min and it will change!” They say it in every city I have ever been to. There is the equal social narcissism of “Here at (insert company name) we can break anything! We have the most complex software environment I have ever seen”

This perspective is kicking our tails

Back in the old days we often needed to push vendors and their products to meet our Business needs. In 1994 I worked at a company called Dr. Solomon’s Software. We had a heck of a time finding a CRM software. It needed to work well with our systems, could capture the data we needed, and we had to be able to get the data out again in a form we could use. After selecting one (no I won’t say which one) we had a DBA on staff for months after tuning and tweaking it. There were times when inputting data (I was tier II support in those days) it would freeze or fields would be un-selectable.

I think any of us who came through the 90s had moments like that with one technology or another. We had to use (and sometimes even pay for) software that felt terribly beta. I admit to working for a Company President at a slightly later company that said often: Ship it as is! F#$% it! We can fix it in a service pack. We need to get this out there.

As is the theme here, times have changed. Products and developers have been given the pest part of two decades to get it right. The metaphorical service pack has long sense shipped.

 I was with a friend at a major airline where she worked in the IT department. They were looking at a number of upgrades, migrations and a few places that they wanted to change vendors. It was real day-in-the-life of the IT department stuff. We came then to the part about custom requirements. There was an ocean of tiny custom needs that the airline had. Each software vendor had to meet them all make final consideration.  Those site specific things proved to be the bulk of the evaluation time and would be a major amount of the implementation costs

 We had a long look at that list of custom requirements. When we took a deep breath and considered most of them against the truly refined nature of the modern software offering they just did not matter. Small changes in process ( they are sometimes politically difficult I grant) could be made that would actually make the software run better, cost us less, and make our jobs easier

This led to a long conversation on the evolution of custom requirements. What methods did we decide on in the early 2000s that have become superseded by better software or methodology like VM and cloud computing?  What methods to we need to adjust our culture to using better?

To take this argument to data security from more general IT I have seen many clients that had an incident between 5 and 10 years ago they are still over reacting to. I have had to talk down 2^nd and 3^rd generation security directors from their institutionalized avoidance strategy of threats that haven’t been viable for years.  To make things worse the Captain Ahab like obsession with the “last war” often leaves us vulnerable to threats that escape our notice due to over-focus.

The Vendor and solution provider community have gotten pretty darn good. I am not saying to blindly trust that vendors have a better way. That would be equally insane to ignoring them.  Vendors are as self-serving as the rest of us. Often they have barely seen the client’s environment and don’t want to work harder than they need to. I am saying any time we as users of IT technology, especially security technology, see the majority of solution providers disagreeing with our doctrine we need to reconsider our doctrine.