What Are SharePoint Architects?

When we look at the minimum resources needed for a SharePoint environment, we think SharePoint administrator and maybe the “can-do-it-all” SharePoint Developer.

  

Don’t get me wrong, these resources are great and are vital for the stability and growth of the SharePoint environment, but they are essentially the workers, or the term I like using, the brick layers (don’t take it as an offensive term, that’s not my intention), they have a strong focus on the technical component of the SharePoint environment, and although they can achieve greatness on their own, they can achieve so much more if they had guidance from someone with a broad understanding of SharePoint (not necessary focused on the technical side) with the ability to map a business problem to the SharePoint technology, that can engage with the business user and plan an approach that will achieve the greatness that SharePoint can provide.  They are the SharePoint Architect.

The reason why I am focusing on this role right now, is the fact that this role is truly misunderstood (This role is typically given to the SharePoint Developer), and regarded as not important in SharePoint deployments.  It’s also a rare skillset, there isn’t decent SharePoint Architect training out there, well, nothing officially from Microsoft from what I can see.

I also looked around on who is providing this skillset, and noticed a disturbing commonality.  People that play the role of SharePoint Architect are not dedicated to this role, I met a few SharePoint Consultant companies, and noticed that there “SharePoint Architects” are also the “Accounts Manager”.  This means they are from sales with the primary objective to sell SharePoint (i.e. bias towards using SharePoint) but they call themselves Architects.  The problem with this is that Architects needs to match the business problem to the SharePoint technology and if the technology does not match the problem, i.e. too much customisation is required to achieve the desired result, then the Architect needs to say no and recommend an alternate/non-SharePoint approach.  Can the people from Sales do that?  I don’t think so.

So, what makes a good SharePoint Architect?  

The Architect has …

• A broad understanding of SharePoint, the Architect understands the building blocks of SharePoint (IIS, ASP.NET, Virtual Directories, AD)

• A good understanding of what functionality SharePoint can provide, the types of configurations that’s available, the limitations of the functionality, and what can be achieved via OOTB (Out of the Box) or Customisation.

• Sufficient knowledge in capacity planning and performance monitoring

• A good understanding of SharePoint advanced features, like Business Intelligence, FAST and what SharePoint license is required to use these features.

• Knowledge on how to integrate with other systems

• Good communication and documentation skills

• Best Practice approaches in defining a strategy for SharePoint and other common tasks like Migration

The Architect is heavily involved during the planning phase of your SharePoint deployment, the Architect’s skillset is more focused on achieving the business objective,  by using best practice approaches and building proper plans that are achievable by the SharePoint administrator or SharePoint Developer.  

Without them, you essentially have brick-layers and plumbers, eager to build, without anyone drawing up and approving the plan.  This will eventually lead to an unstable environment, with no capacity planning, and solutions that built solutions that do not resolve the business problem.