In general, an Enterprise Architect is one who build the architecture which is mostly about expensive and hard-to-change decisions. In context of SharePoint,what can be all those decisions?

I think that designing an Enterprise Solution in SharePoint requires expertise in Development, Infrastructure and Functional analysis. Is there any other area which I am missing?

Also,Does the role of SharePoint architect depends on the methodology in use — whether it is agile or traditional?


4 Answers 4


Although the answer to your question does have a variety of different perspectives that can blend together to come up with a "one shot" coverage scope for a SharePoint Architect but I think it is better if we look into a SharePoint Architect as a mix of different architectural backgrounds working under a single umbrella in a more agile manner.

Primarily , SharePoint Architect is divided between the technical and functional aspect of the platform.However expectations might differ between organizations who enable SharePoint Center of Excellence and may have diverage understanding of what capabilities a SharePoint Architect may have.

So to make it simple enough, it is like a SharePoint Architect in the most basic flavor will come up with the following :-
1) SharePoint Platform + Application Architecture (90-95%)
2) Support Planning and Infrastructure (40%)
3) Governance & Compliance (40%)
4) Understanding various Project Management Processes (50-60%)
5) Enterprise Architecture (20%)

However as the ball keeps rolling ahead , things keep getting fatter in SharePoint Architect's career lifecycle. An experienced and fairly senior SharePoint Architect is expected to have the following coverage areas.

1) SharePoint Platform + Application Architecture (99%)
2) Support Planning and Infrastructure (70-80%)
3) Governance & Compliance (70-80%)
4) Understanding various Project Management Processes (80-90%)
5) Enterprise Architecture (70%)
6) Business Intelligence (90%)
7) Information Security (both application and process models) (70-80%)
8) Service Oriented Architecture & Web 2.0/3.0 Models (70-80%)
9) Information Architecure and Usability Understanding (60-70%)
10) Other Microsoft Technologies
- Active Directory , Exchange (50 -70%)
- Team Foundation Server (100%)
- Hyper V, Clustering , Rights Management Services (50%)
11)Lastly , a vast amount of experience in handling different management systems like CRM , CMS , HRMS , DMS , etc.

As said earlier, one can shuflle between what should be there and what shouldnt be there in the SharePoint Architect's knowledge belt. The above can be still fairly expanded with a wide spectrum of knowledge areas but all of the above should be the founding corner stones of a SharePoint Architect.


A Sharepoint Architecht will design a solution from a high level so he will not get into the nity grity of configuration and development.

He should have experties in all fields of sharepoint. if he does not he might architect a solution that is not feasable.

i dont belive the role of a architect will change depending on the methodology in use


I got some areas from SharePoint 2010 Enterprise Architect's Guidebook:

  • Infrastructure technologies

    — The various infrastructure technologies common to most SharePoint 2010 deployments. This includes topics such as the Windows operating system, identity and access, software and hardware load balancing, farm communications and protocols, database, storage, and monitoring technologies, Internet Information Services (IIS), caching, compression and performance, and, fi nally, virtualization and backup technologies.

  • Development technologies

    — The common development technologies used in most SharePoint 2010 deployments. This includes an overview of the .NET Framework, common development tools, application life cycle management tools, and various code libraries used in SharePoint 2010 development projects.

  • Microsoft Office technologies

    — The key Office technologies used in large enterprises. This includes the browser, the Microsoft Office 2010 suite, imaging and capture solutions, communications and virtual meeting services, and, finally, offline solutions.

  • Complementary third-party technologies

    — Application extensions, as well as operational and administrative extensions.


Seek to know more about the business organization you are developing/architecting the solutions for - know their organizational structure and the processes that they utilize to conduct their business operations. Such knowledge is not of a technical nature but has more to do with economics - align your solutions to their business strategy & logistics.

A few links that can be helpful to the SharePoint Architect -

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.