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

In my not so humble opinion I think the entire "Sharepoint Architect"/"Expert" thing is over-played. Sharepoint is a tool to centralize an organizations digital resources for centralized collaboration or working together in a centralized way.

The best explanation of What Microsoft Sharepoint is and does from the WROX book "Beginning Sharepoint 2010 - Building Business Solutions"

"Because computers play such an integral part in any business, not surprisingly, more and more of the information that is created, consumed, and shared in an organization is digital. The more business that you conduct and the more successful your business becomes, the more information you have to manage. Usually, you have some form of document for just about every process and transaction that plays out during the day-to-day operations of your company. From proposals to legal documents, from sales receipts to human resources policies, the amount of information required for a company to function is staggering.

To manage your information overload, SharePoint offers tools with which you can build business applications to better store, share, and manage digital information. With it, you can create lists, libraries, and websites for your various company teams to help run your business processes more efficiently. By locating your organization’s important business data in a single location, it becomes much easier and intuitive for users to find the right information when they need it rather than searching through disparate locations such as email, computer hard drives, or file shares.

WHAT IS SHAREPOINT 2010? SharePoint 2010 is an extensible and scalable web-based platform consisting of tools and technologies that support the collaboration and sharing of information within teams, throughout the enterprise and on the web. The total package is a platform on which you can build business applications to help you better store, share, and manage digital information within your organization. Because you can build with or without code, the package empowers the average business user to create, deploy, and manage team websites, without depending on skilled resources, such as systems administrators or developers. Using lists, libraries, and web parts, you can transform team websites into business applications built specifically around making your organization’s business processes more efficient."

Creating a schema for an organizations Sharepoint deployment is not rocket science. 1. Determine the structure of the organization 2. Determine what Sharepoint can do as far as centralizing the organizations digital resources. 3. Create a Sharepoint construction plan. 4. Build it, test it, refine it. 5. Maintain it, test it, refine it, add onto it. There! Not so tough.

Answer 2

Ideally SharePoint Architect Skills fall into the below mentioned categories

1. Infrastructure Level/Operational
   1. Capacity Planning
   2. Physical Architecture (Farm Setup, Network, OS, Licensing)
2. Application level (Functional and Non-Functional)\
   1. Requirement and Feasibility Analysis (Custom Vs OOTB Development/Implementation)
   2. Techno-functional Mapping of requirements
   3. Information Architecture
   4. Logical Architecture
   5. Conceptual Architecture
   6. Detailed Design
   7. Database design (not in terms of traditional Database design), this is with respect to Number of content Databases for Site collections/web apps.
3. Deployment
   1. Best way to go for deployment, first time and incremental

Some other activities that an architect will collaboratively work is the Project Manager in Planning, Estimation, Execution/Implementation, Risk Management (assessment, mitigation).

Apart from his daily tasks of working with technical teams, testers, User Interface professionals, Vendors, Clients (Business and IT teams).

Interacting with Enterprise Architect groups if any.

Answer 3

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....

Answer 4

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 5

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 6

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.