Saturday, July 17, 2004

 

Methodologies Part 3

To paraphrase Groucho, consulting is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly, and applying the wrong remedies.
 
On this most recent project, we were using a piece of tomfoolery which I'll call "Systematize" (M. Roget is probably spinning in his grave at my inspired use of his creation). Said methodology was supposed to be used as a data collection device prior to executing a transformation, however, the methods there merely collected some basic factoids, which could easily be gathered by running a simple SNMP manager and taking a cursory look at what's installed on the system. The type of information we really needed were the dependencies, and what was done to actually make applications work, things like drive mappings, data flows, hard code information, run books, and that sort of thing, which unfortunately for the most part just didn't exist. The people who had implemented these various systems were either long since departed from the company, or were too busy fighting fires or implementing the vanity feature/report du jour to even answer queries about how these things work, or in the very best instance, give an "I dunno" when asked how we were going to resolve the situation.
 
You see, security gap remediation was a very important part of things going on at Colditz, and it was almost impossible to find out how people did things like implement appropriate controls for applications. Things like audit trails were either difficult to find or non-existent, most applications had home-grown AAA (authentication, authorization and accounting) systems, and the one bit of documentation we had about data flows was lacking data about just how the data got from point A to point B.  Simple questions like does the data  get here by NDM or FTP couldn't be answered, but worse, "Systematize" had no place to capture it.  Of course it's a fairly trivial matter to extend something kept in a spreadsheet format, but if this was going to plug into a database (as it was eventually intended to), there would be all kinds of squawking from the methodology Nazis about how this information was to be recorded in an organized third normal form way.
 
Part of the problem was that we were hugely dependent on a wonderful piece of work that was implemented in a well known piece of groupware. Said database was split into two parts with a lot of redundant information in them, but one couldn't simply join the unique key between the two parts in a query to get the relevant information we needed to at least do elementary discovery, because the original data gathering effort had been started and stopped at least 3 times, and there were things where one part of the database had far more information recorded than the other side, basically leaving us to poke around in the dark. But "Systematize" was dependent upon this database having everything aligned, and so instead of merely joining the unique keys on both sides, we had to do a left outer join, and leave a bunch of "I Dunnos" in the "Systematize" records, and pray that someone would capture it into some form that would ultimately enable us to do the work. Unfortunately, "Systematize" was always a point-in-time exercise. Had someone merely said, wait until we can get all of our docs and data collection together, "Systematize" would've been easy to complete, and with some minor thought leadership, been able to get the additional info captured and presented to the point where we could actually do something with it. Unfortunately little things like mad boards and Sarbanes Oxley interfere with doing things in a logical progressive manner.
 
The other flaw we had here was trying to produce design and remediation recommendations for something very critical based on incomplete information. This is Not A Good Thing. Ferinstance, suppose you're running a bunch of critical systems on NT boxes, and you are scared that since Uncle Bill and his merry band have said no more service packs, you'd better move it to a newer Wintel platform. No problem, except for the fact that knowing developers like I do, undoubtedly there will be something specific to NT, usually taking advantage of a supremely obscure undocumented feature that won't be found out until doing an integration test, which of course is well past the design stage. I well remember a CLEC whose IT infrastructure was a mess to put it politely, who was completely dependent on Windows 95 (in 1998) because their developers didn't want to bother coding to NT 4 standards. Even a preliminary test caused a blue screen of death on NT. Feeling around in the dark for an IT solution isn't a terribly good idea, and sunlight is the best disinfectant. Unfortunately, sunlight can make the business owners go "oh shit" and say leave well enough alone, put a wrapper on it, keep it quiet, and don't bother me. And yes, LOB, it's going to take a lot of money to remediate.




|

<< Home

This page is powered by Blogger. Isn't yours?

Technorati search