SharePoint and Access cater for an essential part of every organisation: the Power User. Whether it’s a full-time SharePoint Architect, or Jeff who’s “Good With Spreadsheets”; both can make use of these tools to help bridge the gap between custom developed systems and bought-in solutions.
The Family
From my (reasonably short) time using SharePoint, it seems there is a family tree of products that favour the Power User. Right at the top we have the grandfather (or Godfather) Excel, who provides good honest data-entry and hand-tailored analysis.
The middle generation is Access, who took the family-business spreadsheet and took it several steps further. Firstly the data was backed with a database engine, then Forms were added to allow the custom validation and entry of the data, and finally Reports were used to polish the resulting information for analysis and display.
The beauty of this was that an entire useful and end-user-friendly system could be built without needing an in-house development team nor having to buy-in a pre-made solution.
The last generation is Access’s two daughters: the serious older sister SQL Server, and the smart but friendly SharePoint. SQL Server took on the grim and complex business of dealing with data (and later married into the dour .Net family), whereas SharePoint set about taking system creation to the masses.
Of course SQL Server takes care of SharePoint’s data as a big sister would, and more than a few favours are called-in from the .Net family too. This allows SharePoint to concentrate on user interfaces and providing systems to everyday folk put off by SQL Server and .Net’s serious and frowny expressions.
What are you talking about?
To summarise before this analogy runs away with itself: SharePoint is Access with the inner workings of data processing hidden, and the idea of a customisable Power User created interface polished even further.
Why is this a good thing?
For Power Users this is good because they can concentrate on making the systems match what the users need without having to worry about things that they’d much rather a developer would worry about, like “How do I make a page to show an order?”.
Normal users get systems made by people that know the business, and avoid the ominous pause when asking a developer how long (or worse: how much) a small change will be. Having been an in-house developer for a small business I can vouch that anything that lets users do the work they need to do without effecting mine gets a giant smiley sticker (and I mean giant).
Finally, SharePoint is much more flexible and customisable than the earlier generations; all manner of additions can be made that can make it into a tool specialised for an individual organisation.
Why is this not such a good thing?
It’s entirely possible to misuse these tools (for example, using SharePoint as a tea-brewing timer); but it would take some strong arguments from a seasoned professional to dissuade an enthusiastic director deafened by the sound of a new market.
I once worked with an MD who would create a mock-up of the system he wanted in Access, and then hand it over to our team to make it into a reality. In truth the system he wanted looked and worked very little like the database (“if you click that it should actually do this”). While it is possible to create things this way, it was much more efficient (and less nightmare inducing) to talk out the requirements and design from there.
As with many complex tools, it needs someone (developer or otherwise) with a good working knowledge to use them to their full potential. It is important to know the limits of both can be done and what should be done.
In short
These tools give users the ability to easily construct systems and applications that wouldn’t otherwise be possible without a few years of getting to know Mr & Mrs .Net.
However, the more powerful a tool is the more easily misused it is (think chainsaw): It’s best to consult someone with some experience before endangering your limbs.
Tags: SharePoint
