RSS Feed

The Business Critical Access Database

25

February 25, 2015 by Mike Hillwig

Access database. There. I sad it. And I cringe every time I say it. My friends in the SQL Server community will probably shun me for putting those two words together.

For the first time in my career, I’m not responsible for supporting anything that is related to Microsoft Access. It was one of the selling points in taking this job.

For nearly twenty years, every company I’ve worked for had some system that was business critical that ran on Microsoft Access, and as the database guy, it somehow became my responsibility to support these beasts.

At the steel company it was our change management system. At the utility company, it was our daily processing calendar. At the construction company, it was our project master schedule. And at the telecom equipment company, it was the manufacturing database. These were all monstrosities, and they all had one thing in common–none of them were built by professional application developers. That’s the brilliance behind Access. It lets accountants, business analysts, and engineers hack together build their own applications without using IT developers. These little databases become handy tools, and then a small group of people start using them. Before long, the thing blossoms and the whole company is using it. The next thing you know, Doug in Accounting is spending his day supporting a database that IT knows nothing about. It becomes a business critical application.

One day, an executive has a problem with this little tool that Doug build, so the executive calls the IT director for help. The IT a director has no clue what this thing is. An hour later, the whole IT a department is scrambling to find this thing. They become aware of a business critical application that is sitting on a desktop computer under Doug’s desk. Imagine the horror when people realize the thing has never been backed up.

That scenario is absolutely true. I’ve seen it happen more than once. And the outcome is never pretty. The application usually gets moved to a proper file server that’s backed up regularly, and the tables are upsized to SQL Server. And then the IT department gets the responsibility of maintaining something they knew nothing about a few hours earlier. The IT staff now has to figure out how to make this thing scale. And now that IT owns this beast, they’re responsibility or every little bug, glitch, problem, and performance issue.┬áThere is often talk of replacing it with some professionally developed or even off the shelf product. However, because IT never knew about it, there is rarely a budget to replace it.

Oh, and Doug? He’s not even close to happy. IT has taken away his pride and joy. He won’t be afraid to tell anybody that will listen that the system ran much better when he managed it. On a machine under his desk. That had never been backed up.

Unfortunately, the only way to prevent these situations is strong leadership with executive support. IT needs a policy that states prohibits people from building their own applications. We did that at a previous company, and we would scan the network for Access databases regularly. That allowed us to prevent future systems from cropping up like this.


Search

Pages