Access of Evil?
Access of Evil?
Join the DZone community and get the full member experience.Join For Free
Well, Microsoft Access isn’t really evil, but like its other Office brethren (especially Excel) it is insidious how it spreads through the enterprise. However, it has become quite a valuable tool in building true intellectual property that drives business. Born out of need, forged in elegant simplicity and easily spread through file shares, Access databases often become mission critical applications that businesses or business units depend on. This makes the task of containment and management very difficult. Often (and perhaps rightly so) the business units do not see the inherit risk of running on Access because they are focused and goaled on producing revenue. It is tough to fault the business power user who has created a potential competitive advantage for his team without having to go through the usual software evaluation and procurement process. As such, the usage and dependency has grown over time. For example, empowered end users create these databases as a way to fill gaps in larger systems; to allow themselves to be more effective and efficient at their jobs. However, due to the inherit limitations of Access, issues around scalability, stability and security become issues IT teams simply cannot ignore.
And therein lies the rub.
How do you stop the proliferation of such an easy to use tool for building applications? Realistically, you cannot. Other than an outright ban of Access in your organization, you cannot stop the spread of these databases through your organization, especially when security is simply file based. Of course, the same goes true for the propensity of these databases to leave the building, either knowingly or unknowingly. Our company has spent nearly 15 years finding Access databases in enterprises and helping upgrade them to the latest version. You might say we have enabled the proliferation, but we are also protecting these assets by at least keeping them on a current version. However, if elimination is virtually impossible (and you know it is because the business units scream blue murder when IT threatens to take away Access) then how do you go about with containment as an alternative? Well, that will require planning, budgeting and most importantly, convincing the business users it is for their own best interest.
Identifying and targeting specific business critical Access based applications is the key to beginning the process. In order for IT not to get overwhelmed by “boiling the ocean” trying to look at all Access files in the enterprise, the use of tools (such as ConverterTechnology’s DiscoverIT or Microsoft’s Telemetry) will be critical to narrow the scope down to a manageable level. Using these tools to help determine which files are frequently used, for example, will help IT determine a concise list of Access files to then work with the business units to further refine the list to target specific Access databases that really should be migrated to SQL. In this current business climate, security issues alone should warrant the migration to SQL, but there are other factors such as performance and scale that should resonate with the business side. Better to lead with a carrot than a stick, so if you can show the business side their lives will be better after the migration, the more likely you will get the required funding approval to carry out the project. Remember, this is about containment first. You have to show the business units that there is a fairly straightforward and painless way off of Access as a mission critical database (you can still use Access as a user interface, thus making the transition much less painful) and onto the enterprise ready Microsoft SQL database. Once IT has paved the way with a few successful migrations, the resistance by the business units should diminish.
However, breaking the enterprise addiction to Access will most likely be a longer battle.
Published at DZone with permission of Chip Bates , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.