If you learn only one thing about SharePoint…

A few days ago… Frankly, that makes absolutely no sense because the majority of people will read this article at an arbitrary point in time, in which ‘a few days ago’ will likely be weeks, months, or years ago. Let me start again.

I was talking to a non-SharePoint friend who was fascinated with SharePoint and its raving success. Being an IT person, he does understand tech stuff, but seeing SharePoint as it is most commonly presented, he never saw the huge killer-app that many SharePoint professionals know it is.

“So”, he asked me, “in a single statement, can you tell me what SharePoint is?”

I’ve thought a lot about this in the past and have read a lot of suggestions. I’m not saying that everyone is wrong, but all the explanations I’ve seen are still not accounting for the success of SharePoint.

My response this time, as I think I’ve responded every time, is this:

SharePoint is a database.

It is nothing more and it is nothing less.

You can call it a lot of things, a collaborative solution, a development platform, an enterprise content management system… None of these, however, are accurate, any more than you can say that SQL Server is a game, just because someone uses SQL Server to store game data. Nor do these explanations explain why SharePoint is so powerful and has received the adoption it has.

So how does the glorified database explanation account for these thousands of end users, developers and other professionals loving so passionately a series of bits? I think it has to do with simplicity.

I think, and this is just my personal opinion, that when you want to understand something, you need to understand the basics first and then move from that basic to the more advanced. You can’t understand quantum physics unless you know the basics of Newtonian physics. You can’t understand graph mathematics unless you understand basic math.

Building on that analogy, there’s nothing preventing you from using both quantum physics and graph mathematics, or at least reap their benefits, even if you don’t know the first thing about why that damn cat is both dead and alive. To use something, you don’t necessarily need to understand how it works. You flip a switch and light comes on. You dial a number and someone answers. Who cares what electricity really is or why your voice travels thousands of miles in a fraction of a second.

This accounts for SharePoint as a user adoption thing. Users merely see it work. They click a button and some poor bastard gets a new task. They drag an icon and an invoice gets sent to a recipient.

I’m starting to lose myself a bit from the original statement, that SharePoint is a glorified database, so let me get back to what the heck I was talking about.

You see, all of the stuff that SharePoint does is related to information, which is just a marketing term for data. A page is at its core just information. An invoice is just a series of columns defined in a schema we call ‘Invoice’. Tasks, contacts, documents, everything that we see as complex entities with behavior, appearance, and all the other stuff, it’s all just data.

Now, I’ve made this claim to some pretty hard-core SharePoint experts, and they immediately start comparing SharePoint to SQL Server and claim that SharePoint is nothing like that, and although there are technical differences that makes the use of these two types of databases different, at its core, SharePoint is very much the same as SQL Server is at its core. It’s a matter of data, stored in lists in the case of SharePoint or in tables in the case of SQL Server. Items in lists are rows in tables. Columns in items are columns in rows. Views in SharePoint are views in SQL Server.

The similarities do not extend forever, and both SQL Server and SharePoint has distinct differences that makes them each suitable for a specific type of task. For example, SQL Server has nothing that compares to content types, while SharePoint lacks a clear counterpart to stored procedures. These are just features of the platform, however, and doesn’t change the fact that both platforms serve one purpose, which is to store, manipulate, and retrieve data.

Once you understand that SharePoint is a database, you can start to understand why it is so powerful. SharePoint takes data driven application development and solves all the ugly stuff that you’d normally need to consider as a developer. Further, it takes all of this and makes it readily available to users of all skill levels. This is where SharePoint clearly distinguishes itself from anything else; it is equally friendly and powerful to end users and first tier developers as it is to hard-core programmers like myself.

So, despite what many of my colleagues claim, I’ll still stick by my simple explanation that SharePoint is, at its very heart, a database.

Why is this a critical factor in SharePoint’s success? Well, we live in what is lovingly called the Information Age. Much of our society revolves around gathering and processing data. If you have a tool that makes that process easy, stable, and understandable to a lot of people, you have a winner. That’s exactly what SharePoint does, and that is why I argue that SharePoint is the killer app that it is.

Agree or disagree? Let me know… You know where the comment box is.


Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

9 thoughts on “If you learn only one thing about SharePoint…”

  1. I wholeheartedly agree. Sharepoint is a database with an end-user friendly interface. I tried to touch on that concept in my first article for EUSP a few months back (and the very reason for my Twitter name @ListMakerEUSP) http://www.endusersharepoint.com/2010/06/24/list-maker-wanted/ Although not as elegant as yours, I was attempting to break down the concept in an effort to boost site lurker confidence. I think Sharepoint is hard to define because it can do so many things, but ultimately it is storing information. I think that metadata management makes a lot more sense if you look at it from this database point of view, but then that opens up another ‘can of worms’ as I see it. We are putting the power of database creation into the hands of end-users who can’t always see the whole picture..yet again, another reason why governance and end-user education is so vitally important to make Sharepoint successful. Nice article. Thanks.

    1. Kerri,

      You are spot on with the end user ‘problem’. I’ve said this on many occations, that a primary reason why SharePoint becomes chaotic when turned over to users is that users normally have little training in database modelling. That’s why I often find lists in sharePoint with 40 or 50 columns and tons of duplicate information and structure stored as data. With SharePoint so heavily reliant on data, this is a recipe for disaster.

      So the question then becomes, how can one safely turn SharePoin over to users without introducing the risk of chaos? I don’t believe end user education is the solution – for that, the cost is simply too high and the chance that anyone in an organization is capabale of educating tends of thousands of users in database modelling to the opint where they don’t make even rookie mistakes is slim.

      That leaves removing the users chances of attempting data modelling and only train a subset of users or power users. Already, we are moving away from a core strength of SharePoint, that of handing the power over to users. If we limit the power only to those who meet criteria such as knowing about database noramlization, we quickly limit the usefulness of SharePoint as well.

      And where do we stop with our limitations? If we educate users in database modelling, we quickly come to the point where we need to teach them performance optimization as well. Databases has definite performance needs, and SharePoint’s database implementation even more so. For instance, how many number columns can you add before you get row overflow and drastically reduce performance? These are topics that can still make a system unusable, even if users know the basics of modelling.

      The way I see it, if one is to build a stable, performant, and user friendly system in SharePoint, the requirements are so high that no end user will reap its benefits. The alternative is risking performance troubles, data rotting, or user-hostile solutions.

      How does one find a balance between limitations and availability? It takes, at the very least, a dedicated and highly skilled development team including an architect who has a long term interest in the project. This leads to higher costs, which may again make SharePoint a less competitive platform.

      I’m not even sure it can be solved easily. No technical solution can at least with today’s technology be smart enough to catch the issues that users will cause, not to mention addressing those issues with sound advice or correction. Even if we did create a magic database modelling tool, we’d still need to cover the remaining problem areas, such as performance and usability.

      Perhaps I’ll need to write a second blog article on this topic.


  2. Yes, I do agree you can call it a glorified database and it is in all the ways you mention. I do caution using this as the 60 second elevator speech to people describing what SharePoint is, especially someone who works with databases like a DBA or a power business user. They’ll look at it and try to do “database-like” things with it like triggers or referential integrity and see it fall flat on it’s face then blame the technology as a failure.

    1. Bil,

      I am aware of this and also the reason why I mentioned that many of my expert friends quickly jump to that conclusion.

      However, an RDBMS, such as SQL Server is not a database, but a system for maintaining databases. A database is a base of data, not the bits that make the data available. We as technical people should know the distinction even if our minions do not.

      That said, SharePoint does support triggers in the form of event receivers that, when used properly, can far exceed the capabilities of SQL Server triggers. However, this is an RDBMS feature, not a database feature.


  3. I agree completely. I would also say that SharePoint Designer-based workflow actions are the [equivalent?] of SQL Stored procedures.

  4. Nice article, thanks!

    I completely agree with you – SharePoint is a database. From point of view of the end-users – it is rather good and flexible database – it allows the end-users to store their information in the shapes they want. And the shapes can be completely different in different corners of the company.

    I could see similarity between SharePoint and Microsoft Access “on steroids” 🙂

    But if you look at SharePoint from a developer’s point of view, you could see that it is not “normal” database. Technically speaking, it is not relational database – it, at least, is NoSQL database (when completely different schemes stored inside the same persistant storage). And the main problem (from my humble opinion) of the developers is that management of data stored inside users lists is not clearly separated from the management of custom solution’s lists. It makes a lot of uncertainty in C# code working with SP lists.

    Just a small list of disadvantages I could see in SharePoint – http://vtimashkov.wordpress.com/sharepoint-disadvantages/

Leave a Reply

Your email address will not be published.