My friend Andrew Connell recently posted that SharePoint shouldn’t be thought of as a development platform. Instead he encouraged developers to see it as a service. In short he’s suggesting that you consume it like a service from the outside. In this way you minimize the number of dependencies on the platform and create better options for long term supportability. I won’t dive into his points for a developer here. Instead, I’ll say that he’s saying that we need to be inside or outside of an application. Reading a bit into the conversation I saw the idea that we don’t need integration and I realized that this has been one of the key benefits of SharePoint for some time – and it’s something the platform is losing.
It Starts With Access
I first started in publishing by editing and writing chapters for books on Paradox and Access. I’ve still got the plaques that they gave me when I completed the work. Back then Paradox and Access were competing for the end-user database market. Microsoft’s breadth eventually caused Access to move forward as the database for end users. It was – and is – a great data manipulation platform. Recently I sent a mailing to the people who I’ve connected with on LinkedIn. Only one problem, I sent it to an outdated list. The solution was to get a new list from LinkedIn and use Access to build a list of changed email addresses. I did that and sent messages to the people that I missed. It took just a few minutes and solved a problem that would have been difficult any other way.
Over the years Access has fallen out of favor as a way to create solutions. Some of that is the market growing up. Some of that is the influence of the web. Some of that are well deserved criticisms of Access for corruption – which they resolved too late for too many customers. However, what Access allowed you to do – and what it continues to allow you to do to create end-user solutions is powerful. As a result I still run into organizations which have Access databases which play important and sometimes critical roles in the operation of the organization – no matter what size the organization is. Many of my IT brethren bemoan being surprised that mission critical solutions are built on access. I join them in my initial frustration – then quickly move to gratitude that someone else was creating solutions that were helpful to the business.
The power of Access lies in two key respects. First, Access connects to lots of data sources from CSVs to Excel documents and from SQL databases to SharePoint. It’s an engine for data processing. Second, Access allows users with relatively little skill to create user interfaces that other users can use.
The Meaning of Adoption
I’ve often spoken about how I really hate talks about adoption. I think that this is an awful way to think about things. Adoption feels like you’re trying to force people to use a technology that they don’t want to use. I tend to think more about engagement – how to get people fully engaged in the platform. Engagement means getting people to create solutions on my platform – like the users did with Access. If you can get just a few people engaged in building solutions then the problem of adoption goes away. A few key solutions means that a large portion of the organization will use the platform so they can use the solutions those few engaged users created.
Engagement isn’t about pushing people to a platform. Engagement is about pulling people into the fold and making them effective. It’s supporting the users that are building solutions that aren’t sanctioned as IT projects. It’s about providing guidance instead of doing things for the users and their departments. Fundamentally an engagement approach is aligned with how innovations are adopted.
Everett Rogers wrote Diffusion of Innovations to discuss his research on how people become engaged with innovations. He found there are five factors that lead to adoption: trialability, lack of complexity, observability, relative advantage, and compatibility with the current way of doing things. If these factors are present then whatever it is – whether it’s a farming technique or steel axe heads – will be diffused and thereby accepted by a culture.
The rub here is that one of these pillars is relative advantage. In short does the solution provide advantages to the user they didn’t have with their existing approach. This is where SharePoint offered advantages at a platform level – and at a compositing level – which other solutions didn’t have.
The Web and Recycle Bins
When SharePoint first started the web was in adolescence. We had been building web sites for a few years but very few of them had much interactivity. Organizations were getting started with ASP and realizing that having interactive web sites were powerful. At the same time we were struggling to cope with the flood of files coming in from our users. Network file shares were weighted down with content that no one really knew how to organize. SharePoint promised version control. SharePoint promised web access to our content and those were things that had a great relative advantage to what we were doing.
Shortly after SharePoint 2001 we got SharePoint 2003 and we moved from ASP to ASP.NET. When we did we started to be able to take advantages of the platform including the ability to composite things together better. By SharePoint 2007 we had a platform with a recycle bin, master pages, delegate controls, web part connections, and much of the core infrastructure that we have today – and this is when SharePoint hit its stride.
Suddenly there were enough things in the platform that users could build their own solutions. They could composite – that is they could build from the pieces that were provided – to create customized solutions that solved real business problems. We could use RSS and alerts to monitor changes in the system. We could connect a data source from one vendor to a visualization from another vendor. We could make screens that would show detail by allowing the selection of a record in one web part to impact what was displayed in another web part.
Kaleidoscope of User Solution
First there were the Thrilling Thirty pre-made solutions from Microsoft. Next came the Fab 40. Microsoft was building templates for the most common things that their users were doing with the platform. While these templates had their own rather serious issues, they helped users see what was possible with SharePoint by building templates based on the out of the box functionality. Users for their part started to create templates for their organization.
Every imaginable kind of solution was dreamed up. Some of them were created as templates to be easily replicateable. Some were just recipes that users would do over and over again as they moved from one problem to the next. Whether it was a project management site, a defect tracking site, or a customer management site, users were creating solutions and building the recipes to spread their solutions across the organization and across organizations.
The Slow Decline
I started a list of the technologies that have slowly been falling out of favor with the SharePoint team. I found that everything from built in site definitions, to forms solutions, to RSS, and beyond were all being crushed under the weight of progress. Some of my favorite features, like Web Part Connections are nearly impossible to work with these days due to bugs in the behavior of the user interface.
As we continue to see important but poorly understood features disappear, we’ll have to struggle to maintain SharePoint as a user enablement platform.