What Does Support Mean?
Presenting yet another installment in my continuing series on bad database standards. Today’s entry focuses on keeping up with the tools. I’d like to thank Marcel Van Tunen for giving me the idea to blog about this topic.
Have you ever been thwarted by a global fiat from management? Of course you have, we all have. But I’m talking about a particular type of dictum from above: “New software installations, including updated versions and releases, must be supported by current tooling before they can be installed.”
Now, I suppose that the overall intent of this ruling is good. After all, you’ll want to use your tools on the new software when it gets installed. Think about it: if your database change management tool doesn’t support the new features of the new version of DB2 (for example), then you’ll not be able to use new features until it does. This is especially true if your standards enforce the usage of the change management tool to make database changes (which is also a good idea, in general).
But a rule such as this can make it practically impossible to introduce anything new. What if we have an ERP package that relies on a particular DBMS feature that we use a database change management tool on that interacts with our modeling tool and our application program change management tool? And that database change management tool uses utility programs from another vendor to load and unload data. Oh, and our help desk, which uses an Application Server stores trouble tickets in a database managed by the DBMS. Go ahead… poke that stack of cards somewhere by attempting to upgrade one of the components. Can you categorically verify to upper management that all of these things will work together correctly? Not without a lot of reading and testing and worrying you can’t!
Of course, there are nuances to consider. What does “support” mean, after all? Having worked at various ISVs I know that it can mean any number of things. Many ISVs have differentiated between support and exploitation. Support means the tool will run without breaking on the new version and support all old functionality. Exploitation means what non-IT humans would think “support” means’; that is, it works with all of the functionality of the new software, both the old features and the new ones.
OK, here we are at the end of the blog entry and I don’t know whether I’ve actually convinced myself that this is a bad standard. Maybe it is just a “thing to worry about?” What do you think?
Data and Technology Today 
I think we’ve all been on both sides (I have). The development team making an effort to use the latest technologies, but limiting their scope to development only. ‘Forgetting’ tooling to test or to administer the production system. Or maybe you were the developer using a packages latest tricks just because its there and its new.
At the other side the administrator trying to keep his production system save and manageable, but in the meantime trying to stop time.
I think you’ll have to want to go forward. Meanwhile keeping an eye on your surroundings.
New technology coming in: OK warn your management you want no need tooling. Trouble here often is that while explaining why you need this extra cost adding tool, the project has an end-date to make.
New functions? Do you really need to use it? Do your co-workers also understand what your doing? Maybe you don’t need it for now or maybe you can educate the ones around you.
“A rose by any other name…” If you do not want to worry about implementing the “global fiat”, simply tell management that the fiat will be implemented as soon as an industry-wide consensus is reached about the definitions of “new”, “installation”, “version”, “release”, “support”, “current”, “tool”, and “install”. However, if they understand what you are saying, then you may want to update your resume.
Pingback: Bad Database Standards | Data and Technology Today