SharePoint has been around for about 10 years now, with all ups and downs, with bad days and glory days. For the better or worse, SharePoint has became de facto a standard – it is now the most preferred tool for company intranets, and companies tend to put everything in their SharePoint – enterprise content management, collaboration, business process management, and, as we are witnessing at the moment – SharePoint is also rapidly becoming the most popular platform for the social computing (or better: knowledge computing) in businesses. SharePoint might be the last area where Microsoft still has the full domination on the market – one could even say a monopoly. Yes, there is some concurrence to SharePoint, but its market share, and its feature set, allow Microsoft just to lean back, and to enjoy the moment: they made a great application, and they know it.
And then the inevitable has happened: everyone wanted to be friends with SharePoint. In just a few years, thousands of business solutions have been built upon SharePoint, almost every LOB software wanted to exchange data with SharePoint, and I was more than once witnessing CEOs who wanted to buy (or to sponsor the development of) a solution, but only if it is based on SharePoint, doesn’t matter if it, in that particular case, makes sense or not.
And since SharePoint architects and developers have been rarer then the polar bears, two things have happened:
1. Existing people were soon overworked and stressed, working on too many projects, often at the same time, and the quality of their solutions began to decrease
2. A hyper-production of SharePoint developers took place – a lot of people from the SharePoint Administration edge, and even business analysts, were forced to learn how to develop for SharePoint, even if they have never developed before. Even the people who had nothing to do with development before, were suddenly being considered SharePoint developers (You were a cook? Yes? A good cook? Yes? Great! You are a SharePoint developer now!)
Once this has happened, everything was possible – we have again had pieces of the front-end code talking directly to the data layer, we have got the solutions with virtually no architecture, we have again seen the full merger of user interface and business logic, we have again had the empty catch blocks… Pandora’s box has been opened, and everything was possible again.
SharePoint solutions are generally considered to be different. All the experience which we have gained in the past decades, that tells us how to develop good software, was ignored. And all of the recognized architecture patterns ceased to exist. It’s SharePoint. It’s different.
This is no joke – the argumentation you can hear most of the times is – “Yes, but it’s SharePoint”. Architecture is crap? Yes, but it’s SharePoint. There is no error handling here? Yes, but it’s SharePoint. I have seen this same piece of code for the third time in a single solution? Yes, but it’s SharePoint. It’s different.
Well, it’s not. I don’t know why some people think, that, if they develop for SharePoint, it provides them an excuse to develop like a jerk.
At my current position as a SharePoint Solution Architect, I often have to review SharePoint solutions, and it is sometimes really scary what I get to see there. That is the main reason why I have decided to start a series of blog posts, and an open source project (which will soon be available on the CodePlex), with a single goal to show that SharePoint solutions do not necessary need to be different – we can follow the rules, we can use the knowledge and experience from the past, and remain SharePoint developers. No, really.
A missing link, and a biggest issue in most of the SharePoint solutions is architecture. Architecture has a direct impact on all of the following steps in the ALM cycle – most directly on testing, deployment and change management. I will try here to present the ways how to create SharePoint architecture, on such a way that SharePoint solutions do not become different. I will show how the standard architecture patterns can be applied, and how to deal with the common issues like exception handling and logging, configuration, dependency injection, multilingualism and similar topics. As I have already mentioned, these topics will be accompanied by an example solution, stored on the CodePlex, which will grow with each new blog post. The demo solution will be published under MIT license, with practically no usage restrictions.
The next expected question would be – why would anyone write such a series of articles, when there is a great SharePoint Guidance document (SPG) from Microsoft’s Patterns & Practices team. To make one thing straight: this series of articles is not meant to be an alternative to SPG. SPG is still the ultimate resource for all SharePoint Architects and senior developers, which should, by my opinion, be read in the regular intervals (just that we do not forget the things). I will, from time to time, publish here some different approaches to the same topics covered by SPG (like configuration and service location), and, whenever I do, I will always state my reasons why did I take that specific approach. Basically, SPG is in some aspects way too much SharePoint, and it tends in these topics to keep considering SharePoint solutions as being different. That way, problem can occur when we create mixed solutions – SharePoint and general .NET or other technologies – SPG approach is in these cases usually not appropriate. But in most of the cases: SPG is a way to go.
If you have some special wishes about this series of articles or if you would do the things differently – I am open for all suggestions and discussion. There will be a discussion board opened on the CodePlex project page, or you can leave your comments directly under the blog posts – it’s your decision.
Because it’s SharePoint.