What knowledge should a software architect have about SharePoint?

Question

At our company we are currenty trying to define the basic things our software architects have to know about SharePoint for them to architect and/or lead a SharePoint implementation project. Many architects in our company have a .NET developer background and know a lot about .NET development and the various framework components and tooling. However, they currently lack SharePoint knowledge. In fact they don't even want to know the nitty gritty details. They want to know just enough about it to make the right architectural decisions and apply proven patterns. If more specific knowledge is required they'll ask a SharePoint expert.

So What would is the basic set of SharePoint knowledge / skills that an architect would need to have?

Answer 1

Sharepoint can be a nasty beast to work with if you don't know the ins and outs of it (they should be experts with it to architect it). At a minimum, they should know how lists, sites, and permissions work. Ideally they should also know how all the web parts fit together on pages and how they are supposed to interact. Really if the architects don't want to learn about sharepoint, they are going to create a .net web application and force it to run on sharepoint. It won't really follow the paradigm of how a sharepoint app is supposed to work.

I would look at a company called Mind Sharp for guidence as to what they should learn.

Answer 2

An architect should have quite a good understanding of our a product works, from a functional and technical viewpoint.

So in my opinion, an architect should:

• Have been involved in at least 2 Sharepoint deployments, from design to roll-out.
• Have knowledge of our the major sharepoint components can be used using the API. i.e. Sites, Lists, Documents & Workflow components.

As none of your architects have this knowledge, I would pair them with a Sharepoint expert in an existing Sharepoint project, so they get the knowledge they need.

Answer 3

Skills such as list, documents, workflow, permissions... are a bit too basic and are requirement for a SharePoint DEVELOPER.

I'd argue that perhaps site (and site structure) is an area that would fall under the architect's plate.

There are more areas that a SharePoint architect can help with:

• Capacity planning - running multiple servers in a farm. Scalability and other magic words.

• Knowing the capabilities and business scenarios of using SharePoint - this is a very common one.
  The manager asks: what can SharePoint do for me? The developer asks: well, what do you want it to do. The manager then asks: well, I don't know what it can do for me so how do I know what do I want it to do?

• Closely related to SharePoint capabilities are the various licensing costs related to each component.

• As well as familiarity with development and customization costs. Take the same project time that would have taken in ASP.NET, then multiply it by a large coefficient, and then add an additional constant.

• And closely related to what-can-it-do, and how-much-does-it-cost, is the all important question of Return-Of-Investment. All hail supreme ROI!

• SharePoint deployment can be a massive issue and a lot of pain.

• SharePoint upgrade from v2 (MOSS 2003) to v3 (MOSS 2007). We should be seeing a new version of SharePoint in 2010(?). Well soon after the next version of Office goes out the door. So past upgrade experiences may be useful.

• Knowledge of 3rd party webparts. I believe a SharePoint architect should be able to give you at least 5 webparts that they've tried from CodePlex and tell you what they think about them. These are free and easy to grab and play at your own leisure.

• Some knowledge of commercial webparts. Because they are still cheaper than writing your own.

• Have at least 5 SharePoint blogs that they follow religiously (know the community). If not having their own SharePoint blog (give back to the community).

• If they are on StackOverflow they must try to answer SharePoint questions (such as this one).

• Attend local SharePoint usergroups. I think communities are a huge deal. Especially what you'd learn from talking with people directly and learning what they are doing with their SharePoint installation. You may just surprise yourself.

• Experiences with SharePoint Integration - this comes in two equally important flavours - both from SharePoint accessing existing systems (business catalogs, webparts, etc), as well as other systems accessing SharePoint content via webservice or API.

• In addition, SharePoint works with (or works well) with Office, OCS, reporting services, performance point, project server.

• SharePoint hosting arrangements - Microsoft SharePoint online services can be a popular and cheaper option to start using SharePoint. It can be hosted inhouse, or with a 3rd party company. Knowing the options is always useful.

• Must have read SharePoint code using reflector (and preferably still having hair).

I think it takes at least a couple of years to be a SharePoint architect (your mileage may differ). Your .NET architects need to want-to-be a SharePoint architect, otherwise I agree with other's summaries before me - find someone who already is a SharePoint architect.

Answer 4

My advice is look for a doer that doesn't just reads PowerPoint to much in the Sharepoint world is just based on what other people have said.

We have been having issues with crawling 500000 items in a Sharepoint farm and everyone gives another story how to get better speed... Normally people refer to not more than 2000 items in a folder, but that does not change the crawl speed....

So a good architecture is someone who is able to do POC proof of concepts himself of his design and not just refers to some vague stories.....

I have seen to many Sharepoint Architects that hasn't had experience from real life....