On Monday, my small development team will take on our first SharePoint project. Whaaaaaaat? I know, I have been writing this blog for over a year and a half, and I have been talking about SharePoint since 2006, but most of our work to-date has been the result individual efforts. More accurately, our success has been the result of a combination of loosely aligned individual efforts. Maybe a group of people decided what we needed, but one person usually ended up with the “you’ll set this up in SharePoint?” task. Fortunately, SharePoint has matured, and our efforts to get it accepted as a platform for business solutions are starting to pay off. Our understanding of SharePoint has also matured and, not surprisingly our first team effort is going to be to redesign and rebuild of an existing solution.
What We Did Right – Every time you rebuild a “system” you need to consider what worked and what didn’t work. I like to start with what worked. The main thing that we did right was to move this system into SharePoint. We are collecting attorney time entries so we can better allocate expenses to individual projects. Seems simple enough for SharePoint, and since almost every other technical thing our attorneys do involves SharePoint, it was certainly a good place to put the application. Apparently, the only other thing we did right was to decide up front that we would collect time entries for one year and then start a new list. Initially, that was to accommodate SharePoint 2007’s limits, but it works now that we realize we really do have to start over.
What We Did Wrong – In fairness to me, we only made a few mistakes, but since this is such a small process, they are obvious. The first mistake was getting a little bit ahead of the curve. Our little process made use of several Lookup Columns before Microsoft added the ability to prevent people from deleting values that are in use. If you delete the item from the supplying list, the column in the consuming list goes blank. Our second mistake was not understanding why they would want to delete these items in the first place. Our third mistake was forgetting the myriad ways SharePoint solutions can fail. I want to talk about this third mistake, because it highlights the major difference between building a fat-client or web-based system and building a system across SharePoint – decentralized control.
In a fat-client solution, the stuff I’ve been building for thirty years, you collect transaction data through a well controlled user interface. The supporting data, lookup tables, references and validation rules, are tucked neatly behind the scenes, out of harm’s way. In SharePoint, all of that data is visible to someone. No matter how well you set things up, if you are building a solution on a user’s site, they have access to it – more access than you would give them to SQL Server. Of course, that’s the whole point, it is their data; they want to be able to use it and they want you to use it. We built this solution partially to eliminate the need for our attorneys to maintain duplicate lists. The challenge with SharePoint is that I can break a Lookup Column by deleting an item, by deleting a list, by changing the permissions on a list or by moving a list to a new location. All of these actions are valid things for a user to do in SharePoint, so they all have to be dealt with. I could build a separate solution in SharePoint, where all of this was locked-down, but that would defeat the purpose; that would be simply putting a fat-client inside SharePoint.
We need a better solution, and that’s why I am bringing two more people onto this team. I built this solution from the point of view of the attorneys, so one of the people I am adding to the team is going to represent the accountants. It’s not that I ignored the accountants the first time through, but it’s safe to say I could have done a better job implementing their requirements. The second person I am adding to the team is the guy who is going to document this process. Part of the reason things went wrong in the first version is that people didn’t understand how changing something in one part of SharePoint could affect something located somewhere else. In building this revision, we will document everything everyone needs to know, and we will put that documentation in front of them. We have a pretty good working solution today; next week, we are going to make this a great solution!