I was reading Requirements–we don’t need them! by Andrew Woodward of 21apps recently, which talks about the importance of having a visionary product owner on your SharePoint project to ensure that it delivers the right thing. That all makes sense and it's inspired me to write this blog entry ... SharePoint projects also need a healthy dose of software architecture.
If you're currently thinking "well, yes, duh!", that's awesome. Unfortunately, I've seen a number of SharePoint implementations where the basic tenets of software architecture have been forgotten or neglected. Here's a summary of why software architecture is important for SharePoint projects.
Many of the SharePoint solutions I've seen are not just simple implementations of the SharePoint product where end-users can create lists, share documents and collaborate. As with most software systems, they're a mix of new and legacy technologies, usually with complex integration points into other parts of the enterprise via web services and other integration techniques. Often, bespoke .NET code is also a part of the overall solution, either running inside or outside of SharePoint. If you don't take the "big picture" into account by understanding the environment and its constraints, there's a chance that you'll end up building the wrong thing or building something that doesn't work.
Even if you're *not* writing any bespoke code as a part of your SharePoint solution, that doesn't mean you can ignore non-functional requirements. Performance, scalability, security, availability, disaster recovery, audit, monitoring, etc are all potentially applicable. I've seen SharePoint projects where the team has neglected to think about key non-functional requirements, even on public Internet-facing websites. As expected, the result was solutions that exhibited poor response times and/or severe security flaws (e.g. cross-site scripting). Often these issues were identified at a late stage in the (usually waterfall) project lifecycle.
Like any programming language, SharePoint is a complex platform and there are usually a number of different ways to solve a single problem. In order to get some consistency of approach and avoid chaos, SharePoint projects need strong technical leadership and the software architecture role is as applicable here as it is if you're writing a software system from scratch. If you've ever seen SharePoint projects where a seemingly chaotic team has eventually delivered something of a poor quality, you'll appreciate why this is important.
With all of this complexity in place, I'm continually amazed to see SharePoint solutions that have no documentation. I'm not talking about hefty 200+ page documents here, but there should be at least *some* lightweight documentation that provides an overview of the solution. Some diagrams to show how the SharePoint solution works at a high-level are also useful, and something along these lines works well. Some *lightweight* documentation can be a great starting point for future support, maintenance and enhancement work; particularly if the project team changes or if the project is delivered under an outsourcing agreement.
If you're delivering software solutions then you need to make sure that you have at least one person undertaking the technical leadership role, looking after the things that I've highlighted above. If not, you're doing it wrong. As an aside, all of this applies to Microsoft Dynamics CRM projects too, especially if you're "just tacking on an Internet-facing ASP.NET website to expose CRM data via the Internet".
I mentioned all of this to somebody a while back and they replied "but SharePoint isn't software development". Regardless of whether it is or isn't software development, successful SharePoint projects need strong technical leadership and discipline. SharePoint projects need software architecture.
Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.