Are SharePoint Developers Better Architects than Architects?

I was at dinner last night with a SharePoint-y friend of mine and the dialogue arose about distinctions in what is coined as a SharePoint developer and as a SharePoint architect. In a majority of SharePoint projects these are advised as key, mutually exclusive roles that are obligatory for project success. And while I to some extent agree with this notion (such positions being requisite that is), if you look at a arbitrary, indiscriminate company on like or something that is spinning up a freshy practice, staffing a client project, or doing a clean IT slate at a corporation, you are going to most likely see these positions listed. As a result, I just consider it the industry, while it might be exactly my personal, standard.

Defining the difference between an architect and a developer is prickly, and to be honest I think such arguments revolving around position semantics are at best lackluster. However there are a few things I think that deserve noting before I get a wee bit rantish with the remainder of this post.

SharePoint architects commonly are not considered to have mastered development tools and frameworks; generally you find them working closer with the operations group for the inclusive IT environment. Inferring then, it can be assumed that responsibility lies more with the physical / application network, SharePoint servers, SQL storage, management / operations / governance, server and SharePoint security, and miscellaneous other systemic qualities of SharePoint. Conversely, this implies that the other portions of the team pick up weight understanding and implementing the functional aspects of the product, or in relation to what was stated before development tools and frameworks. It is tough to place a multifarious job description in a succinct, single sentence however that is the best I can do for the time being and serves this particular argument pretty well.

Leveraging this as a definition, we then raised the question of not the differences that exist between the two positions (although this conjecture is important in the following argument), but whether SharePoint developers are better SharePoint architects than those that solely define themselves as architects.
The questioning is simplistic; the reasoning is slightly more convoluted. Consider two candidates for a project, one of them a SharePoint architect and the other a SharePoint developer. Furthermore, in order to maintain a equitable baseline, let’s assume comparable (obviously can’t be identical) backgrounds, projects, experiences, etc. Would you insist that the SharePoint developer will be more successful if given a series of requirements and turned feral on a SharePoint project? While this isn’t the structure of a particular staffing strategy for a SharePoint project, it’s the most extreme argument.

For me, the answer is a resounding yes!

Below are three principal reasons why this is the case in my opinion, which is obviously very, very subjective so take it with a grain of salt.

Inherent API Use Leads To Innate Architectural Understanding

Developing against a commercial OOB product such as SharePoint necessitates a majority of the knowledge that architects generally tout as requisite because of object, method, etc. use. As such, the thread that weaves the overall linen is already known, and while IMMEDIATLY the strands being put together properly might not be holistically identified, the knowledge does exist so the barrier to entry is lessened to an immeasurable extent. So while this might not immediately translate to the breadth of architectural knowledge having immediate applicability, I consider this more to be a lack of situational experience (which is even more subjective) easily garnished during a project therefore making a developer a more appealing candidate in the long term.

While there are a lot of examples, I am going to assume a more common one that I see to support such a claim. Consider the use of a UserProfile object and its tricky permissions requirements that require setting in the SSP. I can’t count how many architects I have caught with this on an interview question, but I have never really caught a reasonable developer off with it since when enumerating UserProfile objects in a UserProfileManager that they always get the pesky System.UnAuthorizedException due to personalization services permissions being malformed. As a result, they are already privy to such knowledge.

Developers Are Unquestionably More Learned in Orthodox .NET Concepts

SharePoint is often misconstrued as a mythical unicorn type thing from a platform standpoint that is built on a hugely disparate stack then the rest of Microsoft platforms. And while there were a lot of awkward things in V2 that would imply it really was a one off (for this, I am thinking more a lot of the ISAPI request handoff’s etc.), in V3 it is really just a ASP.NET 2.0 application (outside of fickle things like virtual path providers and what not which are never going away anyways), using the same underlying technologies as thousands of separate web applications across the world. Applications that .NET developers have written, and most convert SharePoint developers already have a fairly thick background in orthodox .NET development.

While interviewing architects for companies, something that I see is that architects stop learning technology once it crosses a certain cusp, in the terms of this post essentially pigeon-holing themselves into the SharePoint slot. While this has both pros and cons, the lack of understanding makes it more difficult when problems arise in a SharePoint environment that can be traced back to a deeper part of the MSFT technology stack, things not well handled by native SharePoint mechanisms.
Again, lots of examples of it. Pragmatic example wise, I always see it with claims aware SharePoint environments. Since developers are more accustomed to different identity contexts, when building claims based environments they are much more effective at putting together how a federated identity processes should flow.

Tend To Have a More Refined Pattern for Business Problem to Technology Translation

I think this one is going to be the toughest point to sell, however I really do believe because developers understand a much deeper portion of the how the overall platform functions (since they are accustomed to extending it) they can provide a more seamless transition of taking requirements and providing the end result. What I see more on projects, way more when I am doing architectural / planning reviews than anything is the use of technology by architects for the simple reason of using it because it was described on a MSFT product page as being a possible solution, so it MUST be the BEST solution. There is awfully little thought given to inclusive environment impacts, and most importantly demonstrated the solution flow so a customer is aware of the steps that are involved in application function.

The BDC is a terrific example of this. When doing please-unfuck-our-SharePoint-environment projects I see architects all the time spouting all these terrific things about the BDC. When implemented not ONLY will you be able to display disparate data, but everyone in the organization will lose thirty pounds, get their hair back, and their significant others will gain an untamable sexual appetite. But 9/10, the BDC is an awful, unmaintainable solution (Obvious FYI: I don’t like the BDC very much in its current form. If I can do it in 10 lines of managed code as opposed to 40,000 lines of XML, I’ll take the managed code option), and the persons ultimately responsible don’t even understand how the XML translation provides DAC, further abstracting the customer from the actual solution. While the BDC is touted as a non-code solution, I can at least walk through my managed code and DEMONSTRATE how the data, in real time, is called, massaged, and presented.

Boy, I could go on with this for a while, but I’m gonna call it quits here :)