What is SharePoint Architecture?

I want to share a discussion that I started on Linkedin about a month ago.  It really helped me and I hope it will help others as well.  Next time someone asks you what SharePoint Architecture is or if you are a SharePoint Architect - think long and hard before you quickly answer "Yes!" and begin to explain.

View the original feed here.
Resources provided in the posts;

1. Two Key Roles and Requirements for SharePoint Farm Administration provided by: Yvette Caluya
2. SharePoint Job Descriptions - provided by: Veronica Palmer

My initial question: Just curious what "sharepoint architecture" means to you? People keep throwing this term around and I hear lots of fluff.

Responses:

• For me, SharePoint architecture means basically two things: 1. The infrastructure architecture consists of the physical and logical components (server, network, Active Directory, etc) that run SharePoint. 2. The informaiton architecture that organizes information (sites, pages, documents, lists, pictures, etc.) stored on SharePoint. People sometimes also mentioned application related architecture, like Workflow, when talking about SharePoint but when you consider SharePoint as a "platform", all applicaiton related architectures are actually on top of the SharePoint architecture...

• Well clearly that's someone who designs whole cities - or even whole states, made just out of SharePoint, no? :-)! Or could it be someone who designs custom SharePoint deployments?? I tend to think of someone working more on the "information architecture" side of things.

• When I think of SharePoint Architecture I think of almost everything I work with right now. How to build up the farms, what versions they run, how we upgrade and innovate them, how we deploy site collections and the processes around it, the integration with other applications, databases and data sources, the way people have to work with SharePoint and how we will support them in it, the helpdesks, the training, the future developments, etc etc etc. In other words, to me SharePoint Architecture is both technical and people-driven, based in the present and what we'll work to in the future over the coming years.

• Jennifer, Excellent question. In the very complex world in which we live, too many people use the same word for so many things. I am going to agree with Rob above, as I view an architect as someone who DESIGNS but does not necessarily implement a solution. While they need to understand the technical aspects of their recommendations and the implications of their design, I have found too many companies who want an "architect" to design something, then build. implement, and operate what they have designed, possibly never designing anything else in their lives. I think that's analogous to having an engineer design you a car, then drive Miss Daisy around and change the oil in it. So as a wrap up, Rob's answer hits it 100%

• Me too, I see it as vision and strategy dependent. The more complex the outcome the more complex it will be.

• I see architecture as relating to information architecture, taxonomy. Questions posed during architecture discussions i feel would be related to the type of portal implemetion whether it be an organizational based portal, task based portal, hybrid. Very seldom when asked about sharepoint architecture by clients do i find them asking me about the architecture of the farm itself, whether it be a medium farm with five server, two WFE's, etc..

• Functionally speaking Rob is quite right and technically speaking, Microsoft defines the scope of SharePoint information worker into two separate domains; however they are interrelated at some level. SharePoint Configuration and SharePoint Development. As certified person, SharePoint Architecture is surly wear of configuration also he is the person responsible of any integration\governs activities. By Integration is like: Windows SharePoint services, are base platform for other application as well (E.g. Project Server), architectures real word scenario is to take benefits of the available WSS and plan integration required SharePoint solution, rather than implementing distinct environment. By Configuration is like: optimizing for geographical implementation when bandwidth is the bottle nick. By Governs -this is big section but an example- is like: business process translation.  Architectures domain starts a level out of SharePoint environment space, while developers are in.

• The question is not on who does what but what is SharePoint Architecture, am I correct? For me, SharePoint Architecture is the entirety of the Application Design. From Planning a farm to DR plans - Design of an end-to-end SharePoint Solution. Whether the requirement is DMS, Intranet/Extranet, Workflow, Portals, etc. In these days where management goes for a staff who knows it all - working within specialites is obsolete. I found this link and would like to share Key SharePoint Roles. For someone who has much interest in SharePoint you could be lucky if you can perform both:

• Hi Jennifer, I also compiled a series of SharePoint job descriptions that may help you in your quest, one being a SharePoint Architect.

• The "what is an X architect?" questions are very common; I have seen dozens of them in various groups and all produce a plethora of interpretations and opinions. There's no single definition of an architect, nothing that will apply for every company, and SharePoint architects are no different regardless of the guidelines from Microsoft. Some architects focus on infrastructure, while others focus on applications, integration and governance. Some are strictly IT focused while others blend into the enterprise architecture role, which usually has a business domain element involved. It depends on the needs of the organization. But that's a good thing, because an architect role, regardless of the specific platform focus, should be less of a task-doer and more of a designer, planner and big-picture thinker...someone who can envision the solution as a whole and how it relates to the enterprise, both in terms of IT strategy as well as relevance to the business needs. So both Rob and Alexander collectively nailed it.

• I expect the meaning depends very much on the context. Often people will have a comparison with something else in mind. In that case they will be referring to 'Sharepoint Architecture' as opposed to X architecture. And the level they are talking about (OS, application architecture, applications themselves, metadata etc) will depend on their role (eg system administrator, developer, knowledge manager).

• I've seen many different job descriptions all describing an "Architect". I would have to agree with Cole on the fact that an architect is more of a designer, planner and big picture person.

• Metadata is the application, SharePoint Architecture means that if you have consistent metadata, you can integrate all of your applications (Why do you think they came out with the term store?). Metadata is the key to everything because it drives consistency. SharePoint architecture is the combining of the unstructured (Formerly known as file shares) with the structured (DB apps) to drive business value.

• How did a question about SharePoint architecture turn into a question about what a SharePoint Architect is? Here's my 2¢. On it's most basic level, SharePoint architecture is the functionality and capabilities provided by the core Windows SharePoint Services (WSS) application framework. It enables collaboration, document management, content management and basic search, among other things. MS SharePoint Foundation has replaced WSS as the core SharePoint architecture in 2010. MOSS and now SharePoint Standard/Enterprise are ASP.NET applications built on the core architecture provided. Since SharePoint is meant to be extensible, you could rightfully say that the architecture consists of a set of core functionalities built on an IIS web application, utilizing an SQL server backend, and a middle tier management server. Since all of these functionalities can exist on one machine, it demonstrates that the SharePoint architecture is more than the hardware that defines a particular implementation. Someone mentioned Workflow. While the core SharePoint application provides simple workflow, it only takes advantage of the Windows Workflow Foundation (WF) and Windows Communications Foundation (WCF) frameworks already available on the Windows Server.

• David you said it all. That has to be the most complete technical explanation of what is SharePoint 2010 I have seen. May I use it on my clients?

• Greetings All, From my perspective, having experienced all aspects deteailed by her description, Ms Yvette Caluya has the most accurate interpretation: "......The question is not on who does what but what is SharePoint Architecture, am I correct? For me, SharePoint Architecture is the entirety of the Application Design. From Planning a farm to DR plans - Design of an end-to-end SharePoint Solution. Whether the requirement is DMS, Intranet/Extranet, Workflow, Portals, etc. In these days where management goes for a staff who knows it all - working within specialites is obsolete. I found this link and would like to share Key SharePoint Roles. For someone who has much interest in SharePoint you could be lucky if you can perform both: " A SharePoint deployment of any organization in excess of 200 users must certainly be well thought out or it is destined to perform poorly; its architecture must be planned carefully considering all the elements as mentioned by Mr. Bermawi

• True a good point; There was a great deal of technical explanations here of what SharePoint Architecture is. Which looks like solid Tech Stuff. A final requirement of the SharePoint Architecture has to aligned to the business need that resulted in the deployment of the product.