Of Cadiwagons and Volksillacs

Truth Be Told

I hear a lot of people complaining about Information Technology folks trying to build a " Cadillac" when a " Volkswagen" would clearly be enough or, conversely, settling on a " Volkswagen" when you should not be satisfied with anything less than a " Cadillac" . Just to set the record straight, I am talking about information technology solutions here, not real cars. If you want to read something about real cars, I suggest you look for " MotorTrend.com" or some such site.

Personally, I have seldom seen a true " Cadillac" or a true " Volkswagen" system (and this even before the automobile industry got into so much trouble). When I look out over the software landscape, I see a lot of " Cadiwagens" or " Volksillacs" , and a thundering herd of unidentifiable solutions held together with duct tape and barbed wire, from soap box systems that you can buy for $19.95 and download (no extra charges for viruses) to applications that rival the " Duckmobile" thing in Seattle (in which you can waste your time on land or at sea).

The Tops Down Anomaly

Just to clarify, a " Cadiwagen" is what you get when you start a project based on a sweeping, all-encompassing vision (often seeded in the mind of senior management by the vendor of a particular product as a panacea for all that ails your company) and then reality sets in. As budgets get cut and deadlines moved up, more and more of the features that make the solution truly worthwhile are dropped from the plans and relegated to the nebulous realm called " Future Releases" . The resulting solution, when it is finally delivered, seldom does anything as well as the solution it is replacing, but at least the new solution has the promise of those dropped features, soon to be delivered (we’ll get back to you with that budget thing) which will make the whole effort worthwhile. Meanwhile, back at their desk, " real people" struggle to learn yet another technology that seems bound and determined to thwart their every attempt at getting their job done.

The system development approach to creating a " Cadiwagen" is most commonly the iterative approach. That way, you do not have to showcase all of your failures at one time, but piecemeal. The original Cadillac vision is still out there, enticing stakeholders and silencing the doubters, and it is typically only after release 3.0 that it becomes clear just how much work is involved in delivering the entire package. It is also about at this time in the cycle that the decision to settle for the " Cadiwagen" is most commonly made.  " Cadiwagens" are often found in large organizations or in the shrink-ware industry (applications that you buy, install, test, and then spend the rest of your natural life in futile attempts to uninstall because of the insidious manner in which they infiltrate your register and other holy sites on your computer).

The Bottoms Up Result

A " Volksillac" , on the other hand, is what you get when you initiate a small project with a limited, albeit " reasonable" budget and schedule — and then the technocrats take over. One feature after another is added on because, " It just makes sense if you are going to change this, that you should also change that because you will get a much bigger bang for the buck. Besides, just look at how much better the solution would be with that added feature."   The result is a solution that grows in clumps and bunches and has phenomenal features that " real people" cannot figure out how to use but which consume their time trying and thereby distract them from doing what they set out to do, namely getting their job done.

" Volksillacs" are most often developed via a method that we refer to as " Chaotic" development, which roughly translates into, " What, me plan?" They generally begin their lives as small, personal applications that some disgruntled individual developed to cope with an immediate problem. As others hear of the application, they want it, too, but only if a particular feature were added; ergo, what started out as a simple, single function application grows into a mega-feature, multi-function abomination that goes " whirr" when it goes, " pop" when it stops, and " hmmm" when it stands still (or something like that according to some silly song from the ’60s that just popped into my mind — see http://www.youtube.com/watch?v=vvmyxTm6hkg&feature=related).

Exemplaris Gratis

There is a perfect example of a " Volksillac" right here at RSG. It is an MS Access database app that is used to generate this Noiseletter in its impeccable beauty.  The basic idea originated over 25 years ago as a simple method to automate the restructuring of CODASYL databases (whatever they are or were). Meanwhile, this simple little application also:

• updates corporate as well as the bookstore website (and four or five others — I’ve lost count) and ensures the links between the two remain intact in spite of changes to both sites;
•  maintains the integrity of an online system development life cycle;
• creates course descriptions ready-for-print;
• cleans up and structures PowerPoint courses to ensure a consistent look and feel;
• spits out email responses for public (open enrollment), scheduled courses; and
• probably a couple of other features I can’t even recall.

 The bloody thing has become something of a cross between a Website Content Maintenance Solution (CMS) and a Learning Management System (LMS). Of course, it only runs when properly coaxed (the automotive equivalent of having to get under the hood and cross three wires to get the car started), it is extremely inefficient (about 4 miles per gallon on a good day), and the human interfaces absolutely suck (as in, this car really sucks; only a mechanic can drive it) — but it works. It gets the job done and that is the primary test of any automated solution.

The “So what” of It All

The key question, of course, is, " So what?" So what if you have a " Cadiwagen" ? So what if you have a " Volksillac" ? Who cares and why does it matter to you? Excellent questions, all. That is the proper response for any intrepid business analyst who makes a living by virtue of her ability to ask intelligent questions and get everyone else thinking. As with all things, having one of these beasties is only a problem if you (or someone in charge) perceive it as a problem. Until then, let them be. Leave them alone and they will continue to serve their respective customer communities (unhappy though these may be).

Once the problem threshold has been breached, however, you must react. Your reaction, as the business analyst, should be the same regardless of which vehicle (pardon me, I mean IT solution) you are trying to repair. The correct response to both is to go forth and speak with the " real people" (i.e., the suffering masses who are attempting to do their jobs but are hampered by the idiosyncrasies of their particular problem child). Elicit their requirements for what they need NOW (and what they might need SOON).  Do your thing, as in analyze the requirements, categorize the requirements, prioritize the requirements, and help the poor, suffering masses figure out what would have to change to make the solution better, faster, cheaper (and more stable). When you are done with your work, you should have defined a good vehicle, one that does what it should do properly but without any unnecessary bells and whistles. If you do a good job, what you defined should be renamed to reflect the new reality. Maybe you should call it a " Toyonda" or " Hoyota" or something like that. That sounds a whole lot better nowadays than either Volkswagen or Cadillac, doesn’t it?

Tom Hathaway
Managing Partner
Requirements Solutions Group, LLC

Editor’s Note: Restructured Courses

Did I mention in the last edition that we restructured our training offers? OK, you caught me, that was a rhetorical question. I know I mentioned it in conjunction with the IIBA rollout of BABOK v2. In addition, however, we have also significantly restructured our virtual offerings (which we are now calling On-Line, Instructor-Led training). Our new model offers each course that we offer asmodules, each consisting of one or two 3 ½ hour long sessions. Although each module covers a complete set of topics, a series of modules spread out over 4-6 weeks covers the entire content of one of our On-Site, Instructor-Led training courses. Each session is scheduled to target either the East coast (8:30 am — 12 pm) or West Coast (1:30 — 5 pm) each day. This basically means that you can complete virtually (very punny!) any of our standard courses either as an on-site with a live instructor in a couple of days or on-line with a live instructor over a couple of weeks. The choice is yours. Check our website for additional details.

Requirements Solutions Group, LLC.