Someone asked what is a SharePoint architect:

http://stackoverflow.com/questions/654318/what-knowledge-should-a-software-architect-have-about-sharepoint/

Here’re my thoughts collected and reposted (and most likely incomplete):

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.