The Right Tool

I've been working as a systems integration and technology consultant for 15 years now. Prior to that, I worked in the construction industry for 10 years. Surprisingly, I think there are many skills and approaches to problem solving that my previous vocation has given me that are very effective in my current occupation.

One thing I learned early on was the value of having the right tool for the job at hand. If you have ever tried to use a hammer on a screw you know what I mean. Of course, another thing I learned was how to make do with the tools you have at hand, even if it’s not the perfect tool for the job. In a perfect world, every time I needed a new tool, I’d just buy it. But that wasn’t practical back then, and it isn't now either. The real world dictates that I buy the tools I use the most, and make do with the ones I have for the odd jobs that require rare or expensive tools.

How does this translate to my current job? I’m currently working on a Drug Safety Reporting system, designing standardized and validated reports that the users will run on demand. We’re using the right tools (Cognos/Oracle in this case), gathering requirements, designing the look and feel, engaging the users and business experts to make sure we get the reports right. We’re also engaging the QA and validation teams to make sure our approach to design, development and testing is blessed by them. We’re slowly but surely getting the reports into the hands of the users that need them. This process is the right approach for the reports that will be used by groups of users time and time again. Monthly listings and summaries, annual and semi annual regulatory reports, and operational metric reports all fit into this category.

But what about the one offs? The reports that need run once? Sure, we can try to cover some of these with careful design of some broad requirements and push these through the process, but it still doesn’t fit 100% of the business needs. Nor does it make practical sense to dedicate the cost of the resources required to answer a simple question that a user may have about the data.

We could go out and implement a validated, fully-powered, 20 horsepower Ad Hoc query tool for a significant chunk of $$ (like Cognos!) Cognos would perfectly fit the requirement, but the cost of the effort of configuring the software, training users in using the Ad Hoc functionality, as well as the risk of them from shooting themselves in the foot due to lack of expertise in the data model is enough for my client to nix this. Hey! Wait! Didn't you just read above that we are already using Cognos? Yes, but we are using a "COTS" prepackaged set of frameworks and packages, something we can't change (invalidates the COTS support contract) and that has been deemed too "complicated and dangerous" for the average users. It's fine for the report developers (who are experts in this COTS), but not for the everyday user.

Instead, we could look into our toolbox and figure out how to use what we already have.
Like TOAD. We are already meeting these requests by having a small, core group of database experts write SQL in TOAD and export the data into either a spreadsheet or PDF. The challenge is to figure out how to use this tool in a way that can be validated and deliver quality reports, while keeping down the costs. Not impossible, and the validation effort is actually similar to implementing a new, off the shelf tool, but at much lower costs.

The key is to come up with an approach to developing the SQL, running and testing it, and delivering it to the users in a way that is approved by the QA group. The plan is to fully document all the fields commonly used, the tables and joins between the tables, and any special filters or business rules (such as determining relatedness via causality.) Basically, it's a documented brain dump of the aforementioned data experts. Then the approach is to take this coding standard and data dictionary and implement it with processes for requesting and delivering the reports, as well as templates that document requirements, SQL queries, and results for transparency. The result is that reports are delivered in hours rather than weeks it would take to code a standard report. And if any of these ad hoc reports is required on a recurring basis, the requirements are already fully documented and easily passed along to the standard report development team.

The bottom line is this: It's important to use the right tool for the job, but it's not always practical. As a consultant, I've learned to balance quality with pragmatism.