Pros and cons of rogue databases
Local managers need them, but they must eventually be brought into the enterprise
Michael Daconta is chief technology officer at Accelerated Information Management and former metadata program manager at the Homeland Security Department. His latest book is titled “Information as Product: How to Deliver the Right Information to the Right Person at the Right Time.”
In last month’s column, I discussed an executive dashboard I am developing using Microsoft Access. I am appreciating its power to quickly achieve nontrivial functionality, loving the huge developer community and simultaneously hating Visual Basic for its kludged-together syntax.
The experience has given me new insight into a problem that confronts every CIO in the government and every other large organization: the ubiquity and utility of Access-based applications — also known as rogue databases in CIO-speak. Those applications empower every subordinate unit to handle their IT needs locally while also imperiling a single, universal management view into an organization’s information.
That is not a simple or one-sided issue. The prevalence of rogue databases bespeaks a deep truth not easily swept away by enterprise dictates or platitudes. A simplistic, blanket policy against local Access databases could thwart business units from accomplishing their missions and stifle individual leadership and initiative. Let’s explore this problem and how some government organizations are solving it.
The good, the bad and the ugly of agile programming
6 databases and how to pick one
As you probably know, Microsoft Access accompanies Microsoft Office and is therefore usually on almost every Microsoft desktop, barring for the moment the office application war with Google Apps and/or OpenOffice. Microsoft Access comes with a built-in, Visual Basic development environment called Visual Basic for Applications (VBA). The Access meta-model follows a basic input, processing and output pattern with forms, queries and reports. There are multiple ways to share an Access database; however, unless your needs are simple, your Access-based application will typically whet a user’s appetite for requirements that outgrow Access.
Thus, the solution to your users’ needs and the CIO’s enterprise view is to create a full-blown Web-based application. However, your business units need a service to do this easily without getting tied up in the morass that is the government contracting process.
Now, before we let the pendulum swing too far back to the enterprise side of the equation, the value in beginning with an Access-based prototype must not be forgotten. With my project-tracking dashboard, Access has enabled us to perform Agile prototyping and deliver working screens in front of users on a weekly and sometimes daily basis. So Access provides a good starter environment that can help refine requirements while the IT department can provide the long-term, enterprise-ready, Web-based or possibly cloud-based solution.
When I worked at the Homeland Security Department, I first encountered the idea of rapidly “webifying” databases via an Oracle product called HTML DB, which is now called Application Express. After leaving government, I supported the Transportation Security Administration and met Kevin Lawson, branch chief of applications development in the Office of Information Technology, who had faced this problem at the Secret Service and wrote an application called EDB, or the Everything Database, to easily convert Access databases to a corresponding website.
TSA has recently improved and expanded EDB into a full-blown enterprise service. Kudos to Lawson for identifying and implementing a robust solution to this problem years before it went mainstream. Most recently, my colleagues and I at AIM have also had good experiences with a product called Enterprise Elements, which also tackles this problem.
Rogue databases have been pilloried by enterprise architects and information management professionals for years. However, they filled an important and immediate need. Given that nature abhors a vacuum, it is absolutely proper and necessary that local managers do what needs to be done. And local Access databases can serve an important prototyping and requirements refinement role in preparation for a more robust, long-term enterprise solution.
Thus, it is up to the CIO to deliver an enterprise service for webifying local databases. In fact, that could be a killer application for cloud computing.