RSS Feed

Mike’s Rule: Know Thy Data

33

September 30, 2009 by Mike Hillwig

At my former employer, I was hired to do database application support. I spent my first two weeks working with Debbie, our trainer and business analyst. I learned all about our project management system and met the key players.  In retrospect, that was one one of the best things I’ve done in my career. It gave me an appreciation for the business.

Technology people have a tendency to focus on the technology that runs business and ignoring the business. That’s a huge mistake. As I said in a previous post, if you don’t understand the business behind the data, the data is meaningless. In that position, it was especially true. Construction financials are incredibly complex. It’s not just debits and credits. It’s left-side and right-side accounting. I was there four years and the concepts are still a bit blurry to me. Imagine writing a trigger, stored procedure or report against the COR table when you don’t even know what a COR is. (For those unfamiliar with construction, it’s a change order request.)

I’ve seen situations where an IT department will get a request from the business user and just farm out that request to a business partner to develop the situation. The business user knew they needed certain data elements but didn’t know where the data lived in the database. And the business user shouldn’t know, but the IT contact should. This led to countless back-and-forth questions. The time and budget overruns were embarrassing. The next request was mine, and I literally laid out every field, formula, constraint, and specification. The vendor was able to turn that around incredibly quickly with minimal review because they knew exactly what was expected. That was the result of rock-solid specifications by someone who knew the system and how it was being used.

Call me crazy, but I think that as a DBA, we should at least have a slight understanding of the data in our databases.


Search

Pages