For years Access has been a bad word in the mouths of IT administrators and developers – although for different reasons.  However, it is popular among end users.

The key problem that has come about with the popularity of Microsoft Access is that Access Databases tend to pop up all around the organization on desktops and on file servers around the business.  In addition they are often set up by an individual (or two) who then use them to store information that needs to be properly managed, backed up and secured – but isn’t.  In addition, an organization often has no idea of the information that is in the business that could be useful for more purposes or which could be beneficial for more people to use. Then there is the whole story around storing the database on a network and doing a full data pull over the network to run a query…

Today, many organizations are looking for a solution to these problems.  How do you managed all these databases that just keep popping up at random without controls? When they are there how do you know what they are used for and what is the cost if they are accidentally deleted, corrupted, etc and nobody knows until it is too late to retrieve it? 

SharePoint 2010 may have the solution to these problems.  With Access 2010 you can store the Access database in SharePoint itself, centralising all the data, putting it into a solution that can be centrally backed up and managed, where security can be set and IT is aware of not only the presence of the Access database, but also who uses the database and how much.  This provides the ability to continue to use Access in the organization without compromising security, resilience or manageability of the database.

But wait, there is more.

I referred to Access Services as game changing in a recent tweet. Here is why – this has massive implications for Line of Business Applications.

Today, if you want to develop an application for data entry and reporting you’d probably hire a developer to write the front end (web or windows forms), dump the data into a database like SQL Server (perhaps even just SQL Express) and use something like reporting services to extract the data for reporting purposes.  While this approach is often justified, there are two places where it becomes a problem.  Firstly it won’t work if there are only a couple of users who will use the application and the payback doesn’t pay for itself in a  big way.  The reason why is the second reason - namely that it is usually expensive to hire a developer to do this and then maintain the code, etc – developers are worth their wages, but there is always a price.

So, with that in mind, what if an end user could build a simple Access application for a line of business requirement, and upload it to a central location where everyone can then access it – and it scales?  And only the data you need is sent over the network.  And what about if you could also take it offline and then sync back up too?  Access Services will also do that no problem.  Want to know how many people are accessing the solution?  Just take a look at the usage reports that come standard in SharePoint 2010.  You need to upgrade the app to support a new business need?  No problem, download it, make changes and just upload it again and it is instantly available for everyone.

This changes the way people think about building simple line of business applications dramatically.  It brings creation of these solutions down to non-developers, freeing developers to focus on things which are less verbose and require more thought.  It also speeds up the time to have a Line of Business Application available – going from weeks or even months to literally days or even hours in some cases.

Sound scary? Don’t forget that this is centrally managed, backed up with your SharePoint server (you do back it up don’t you?) and can be secured centrally and governed in line with company policies and procedures.

Access Services for SharePoint with Access 2010 is game changing.  Not only can you centralise the Access sprawl, but you can rapidly build and deploy specialised data oriented applications and share them through the organization literally overnight.

I’m hoping to have more on this in an upcoming podcast with product team members, so stay tuned.