Content Copyright © 2006 Bloor. All Rights Reserved.
I have a life outside of the analyst community as an independent technology consultant and business mentor. The beauty of this is that I get to experience the real highs and lows of technology start ups and can relate far better to the numerous companies I meet when working as an analyst.
The downside is a potential conflict of interests when I work as an analyst in the same area in which I have personal involvement. In order to present a clean and “above board” view I need to declare my interests publicly and openly.
I am a director of a company called ChangeBase, which has a set of products that provide pro-active analysis of vendor patches, enabling IT managers to understand what impact a set of patches may have on their IT estate.
To put this in perspective, if you manage 4000 desktops for a bank how do you know that a specific patch release from Microsoft won’t break some vital part of your desktop software without you realising it until it is too late? With the complexity of modern software one bad DLL can bring down an entire trading desk.
The “traditional” approach to this is to have a bunch of testers sitting there testing each patch against a reference desktop build, hoping they test every feature available to ensure it still works. We know this is crazy, and at best a tester will load a patch and startup the applications to see if they will boot and maybe print out a document or two.
The complexity and interrelationship of modern software is really scary, and the only way to truly understand if there is likely to be a problem with a patch is to instigate an automatic test. This needs to be at an excruciatingly granular level as each component and its associated myriad of registry settings is explored, making sure that one small change won’t bring down the house.
Of course you can opt out of installing the patch—but think how that will go down when you are exposed to a vulnerability that was fixed weeks ago (think: SQL Slammer) and your CEO demands to know why your organisation has been left with an open vulnerability.
The ChangeBase proposition uses very smart software to determine what, if any, application may be affected by a patch and will quickly report this back to the systems administrators—often via email before they get to work. Using this information, some of the conflicts can be automatically remediated and, where this is not possible, testing can be focused on, say, the 10% of applications that will be adversely affected by a patch.
I won’t be writing about ChangeBase again, due to the conflict of interest. I will be writing about the issues around patch management and security and other vendors in this space that help deliver an Assured business.