Occasionally, TDC is called in when the original developers of the database can’t be found (or coerced into returning). It’s a great opportunity to learn how other database architects do things, but since nobody calls an expert when things are going right, we usually get to see some pretty awful implementations. In this case study we look at such a scenario (identifiable circumstances and situations have been changed).

A mid-sized non-profit organization responsible for providing free and low-cost auto repair to qualified clients had a custom database built to track clients, mechanics, dates of service, and appointments. Unfortunately, after a lot of dollars and time, the system just wasn’t working and the staff was getting increasingly frustrated. TDC was called in to fix the system. We reviewed the existing database, then went back to look at the process flows, and that’s where our story begins.

A good database begins with a clear process flow that tracks the data from collection to end product. In this case, this is where a good database went bad: The initial implementation didn’t focus on a process flow, it looked at the data flow (for more information, click on the Process Flow podcast on the training page). The data flow didn’t take into account procedural exceptions, which changes the data flow pretty dramatically. As the staff encountered these exceptions, modifications were made to the database. The trouble was, each ‘fix’ caused a ripple effect with unintended consequences. What was left was an undocumented collection of work-arounds that didn’t do anyone any good.

The Database Company Solution

TDC showed the client how to construct a good process flow and how to account for exceptions. The staff got together and documented their workflows and data flows, and the result was a clear document that would become the heart of a new database. The process also helped the customer find efficiencies overall, and led to a new way of doing things.

Among the assets on this project was an interesting one: Realistic Expectations on behalf of the users. The original roll-out’s failure to live up to expectations provided a level of understanding of the internal systems responsible for making the magic. When this process goes south, there’s an exposure to the level of complexity involved in a complex deployment like this one. The increased awareness provides a more realistic foundation for what a system can and cannot do. A database can’t fix a broken process, and in this case, the broken database helped to highlight several ‘breaks’ in their process.

copyright 2008 Alderete & Williams, Inc. - All Rights Reserved - PO Box 731 Carlisle, MA 01741