Sunday, February 19, 2012

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.

8 comments:

Anonymous said...

Interesting view Nadir! I agree with you here, but I have a question? Besides the points you've mentioned (I think these are how an individual can build their own skills to become an SharePoint Architect), how do you as the driver ( for lack of a batter word) of these skills turn your resources into architects? They must be brick layers first?

Do you think that all resources can become architects?

Nadir Kamdar said...

I have not seen great success in turning a "Techie" (SharePoint Administrator / SharePoint Developer) into a "non-Techie" (SharePoint Architect).

There are 2 main reasons for this.

The first is the current shortage of SharePoint Techie Skills, meaning that I may pull a SharePoint Developer away from that role and give him/her responsibilities that are more focused on the Architecture, but I eventually push them back to that development role when I am seeking resources to fill that much needed Techie role

The second reason is the fact that Techies show little interest in non-Techie roles. They have passion in the Techie part - and it is difficult to move them to a role that requires a different of skills (presentation skills, communication skills, documentation skills).

So while there are obvious advantages when a techie expect who has worked on the technology directly, plays the role of the Architect - that's not going to be your main way to get SharePoint Architects.

You will get better results in finding Architects from resources who are non-techies but passionate about SharePoint, maybe a skilled SharePoint BA. I seem to get better results from them.

But no matter who you select for the Architect role, they need to go for good non-technical SharePoint training, and the only course that I found that does this very well that the SharePoint certificate program provided my AIIM ( http://www.aiim.org/Training/SharePoint-Course)

Anonymous said...

Nadir, you have made some very ignorant statements and I question your perspective. You appear to be another judgemental blowhard.

Nadir Kamdar said...

Is there a particular point you disagree with? maybe I can justify my thinking.

Dalton Morrow said...

In this blog writer mainlywant to talk about What Are SharePoint Architects? And also try to explain what good SharePoint Architects is and how any SharePoint developer can get benefit from this.

Big RAJ said...

I have to agree with you here. As a self titled "Architect", I have been trying to get the buy from my techy - colleagues. This role is important, as SP is usually used as a means to communicate with the business.

gokul fita said...

Thanks for sharing such a great information..Its really nice and informative.
SharePoint Coaching in Chennai

Anonymous said...

Well explained Nadir. People who are Sharepoint architects will sure agree with this. Architects must have business face and technical face otherwise they will be building fragile application.