One of the more common questions I encounter in conversations about Microsoft SharePoint is, "How do I go about designing the right architecture for my SharePoint environment?" Most people seem to understand that this is an important question to ask (and answer) when initially deploying the product, or when planning to expand and enhance an existing implementation. Failing to consider architecture design won't necessarily doom a SharePoint project to failure, but it certainly will have a significant negative impact on its chances of long-term success.

My usual response to the question is, "When you say 'architecture', what do you mean?" In the context of SharePoint, there are several kinds of 'architecture' to consider:

Physical Architecture

This refers to the hardware and software platform that runs SharePoint and related services. It can include web, application and database servers (physical or virtual), operating systems, applications software (SharePoint, SQL Server, etc.), networks, load balancers, firewalls, security appliances, and more. It also can refer to components or environments that are hosted “in the cloud,” by Microsoft or other hosting providers.

Logical Architecture

SharePoint provides a hierarchy of structured containers, each of which offers different capabilities, configurations and intended uses. The hierarchy includes Farms, Servers, Services, Web Applications, Site Collections, Sites, Lists/Libraries, Folders and Items. The SharePoint environment is ultimately crafted from these building blocks.

Functional Architecture

Of the architecture types, this is the only one that is user-facing. It includes definitions of all of the business scenarios and user experiences to be provided by the SharePoint solution, for all participating audiences. “Publishing Company Information,” “Department Document Management,” and “Executive Dashboards” are all good starting points, but a good functional architecture design will get deep enough into the details of the why, what, how and who to ensure that all business goals are met.

It would seem that each of the above areas might be straightforward in simple scenarios, but could also be quite complex in larger implementations. How do you go about determining where your deployment will fall on the “architecture complexity scale?” How can you address the initial question and actually define the “right architecture” for your SharePoint environment? The answer lies in approaching the various aspects of architecture in the right order.

At the beginning, it is important to define the “Solution Vision” for the organization’s usage of the technology. Ideally, this process will include key decision makers – the higher up, the better. The initial objective should include answering the following types of questions:

• Why is the organization deploying SharePoint – and how is it intended to benefit the business? Be specific!
• Who are the target audiences for the solution?
• Which individuals should participate in defining solution requirements, approving designs and ultimately owning responsibility for managing the solution? Hint: It's not IT!

A clear, shared understanding of the business goals will make most of the subsequent decisions easier. From there, you can begin to define the functional requirements for each audience of business users, including such things as:

• Information publishing and consumption scenarios
• Group/team document sharing, collaboration and workflow needs
• The types of content to be managed, along with their lifecycle considerations and retrieval scenarios
• Accountability and access control requirements (aka security permissions structure)

An experienced SharePoint Solution Architect will be able to analyze the answers to these questions and develop a logical structure that will best support the defined functional needs. One of the main challenges is to maximize the intuitiveness and ease-of-use for business users, while minimizing the effort required to manage and maintain the environment. Skipping these steps or tackling them out of order is how many SharePoint deployments begin their descent into either apathy or chaos.

Once the functional and logical architectures have been determined, you will have the data required to design the physical architecture for your implementation. There are a number additional things to consider, including where to host the environment, which edition of SharePoint is best for your needs, how many users you have, and what your budget will accommodate.

Of course, once you have figured all that out, you've only completed the first couple of steps on a long path to the SharePoint promised land….