Microsoft SharePoint 2010 - An Evolutionary Approach to End-User Empowerment
Ishai Sagi is the author of one of the world's most popular SharePoint blogs, www.sharepoint-tips.com.
This article was updated on May 13, 2011.
A few years ago, I helped a company that was migrating its entire system from Microsoft Office 97 to the latest Microsoft Office technology (back then). My client's IT department wanted to find out how many Microsoft Access databases needed to be migrated, so that they could analyses which ones could be replaced by SharePoint lists instead—thereby reducing the number of Microsoft Access licenses the company required.
The IT staff ran a script across every computer and learned that the average was more than three databases per user. Maybe that doesn't sound as amazing as it should, so I'll rephrase it: In an organization of 5,000 people, 17,000 databases were scattered across the personal computers.
Many IT managers would be dismayed by this story. Why do all these data islands exist at all? Why didn't the users come to the IT department when they needed a data storage system? What a disaster!
A lot of single-table databases were floating around with no primary keys. Most of these Access databases were extremely inefficient, as though they were written by someone's cousin who learned Access in high school—and probably most of them looked like The Daily WTF entries—but there was one thing to say about all of them: They worked.
At some point in time, users saw a way to improve their jobs. They might or might not have tried to get help from the IT staff. Maybe they weren't helped because the IT department was too busy on bigger projects, or didn't have the budget; maybe the users didn't know that the IT department could do the work for them.
In any case, users found a way—creating the application by themselves.
Importantly, in a situation like this, the application evolves. The end user maintains it, reinvents it, and improves or scraps it when it's no longer useful. If it's very useful, the user shares it with colleagues, and the application spreads—like a Web 2.0 viral video. Eventually the application may be noticed by the IT department (where the software engineer will have a heart attack after seeing the database schema). Then the software will be rebuilt using scalable infrastructure and tools, and employing decent coding practices. But in the meantime, that user-created application helps the business to maintain its bottom line.
These end-user applications serve a purpose: They help employees to do their jobs more efficiently. This makes those databases good applications, no matter how a software engineer might view them.
The Problem with the Evolutionary Approach
The "evolutionary approach" has a lot of things going against it. Consider the scenario: 17,000 Microsoft Access databases across many desktops. Are they backed up? What happens if they're lost? Are they secured, or can anyone access them? Who supports them if they fail? Does each database conform to the roadmap and architectural guidelines that the organization has established?
Those Access (or similar) applications cost the organization money, even if it doesn't come out of an IT budget. When an upgrade is required, the organization suddenly is faced with having to buy the upgrade for that application, and then deal with very angry users whose self-made databases suddenly don't work.
These are the main reasons that many companies don't install Microsoft Access on users' machines in the first place, thereby limiting the possibility of the evolutionary approach to information management within the organization. Users are reduced to managing their information in Microsoft Excel worksheet or Microsoft Word documents. However good those applications are at other tasks, Excel and Word are not designed for sharing information in that manner—but most IT managers prefer that option versus the alternative of having all those databases and custom applications floating around.
So the evolutionary approach seems doomed. But is it?