As a SharePoint Architect, it is crucially important that to create a robust SharePoint environment for your clients requires planning and considerations of opportunities and threats concerning SharePoint topologies.

All too often SharePoint is implemented without a true understanding of its premise, structure and components, potentially leading to SharePoint becoming a white elephant from a support and user perspective. However, if planning is carried out, and considered by you, your peers and the client and following a repeatable process then it ensures platform growth and future-proofing.

This article of two discusses my opinions in creating a detailed design for a SharePoint 2010 environment focusing on designing its topology, and covers these areas:

• The Customer Base
• Functionality and Availability
• Capacity
• Performance
• Design Constraints.

In addition, we must not forget areas that relate to planning SharePoint 2010 topologies, namely: Organisational Requirements; SLA requirements; Functional requirements and Licensing (but I’ll get around to that in Article 3 J ).

So, where do we start?

First, learn more about the areas that you will need to document as part of the topology planning exercise. Of course, you don’t have to throw your hands up yelling ‘how do I find that?’, since there is a wealth of information out there already – either hosted by Microsoft on TechNet or through other excellent sources (including my book J)

First – my book is the source for describing how to best implement SharePoint 2010 (everything and much, much more is in that book) – since there are significant pieces of work leading to designing your SharePoint environment:

Managing and Implementation of Microsoft SharePoint 2010 Projects – check out system specification, topology design and user requirements gathering.

Other good reads:

Also, it is important to be aware of the components that make up a SharePoint environment. And, the best way to appreciate and gather these properly is to start from the lowest level component; working your way up through increasingly complex and costly areas so a clear idea is known. For those used to SharePoint, these should come as no surprise – in order then:

Lists and Libraries > Sites > Site Collections > Content Databases > Web Applications > Servers > Farms > Datacentres.

Each of these areas will constrain your topology design for SharePoint and must be investigated.

So how do you proceed?

First, document the customer base. Identify the number of users, the level of information held in their user profiles, how those profiles are stored, the physical location of the users and who manages the user profiles.

Second, gather the functional and availability requirements. What is the premise of the SharePoint environment – is it document management? Publishing? Application Workflow? Social Networking? A combination? Will it include Search and to what extent? Will users have personal spaces (Mysites) and if so what basic functionality will they require? Availability – if the SharePoint environment was subject to a disaster event, how long could the business afford to be without SharePoint? If a site became corrupted and had to be restored, how quickly do users need to be up and running with the restored environment? When SharePoint requires maintenance, when are these ‘windows of opportunity’ available and for how long?

Thirdly, plan capacity. Starting from the base, analyse document storage. This means sizing up the document type and sizing. Do this for all the document requirements for all the relevant sites gathered in the previous step, then, total. Factor in search requirements since this will give you a rough size of the search index, and include all service applications needed on day one (since that will also have a bearing on the content data sizes as well). Include storage requirements for the operating system. Other areas include size backups staging requirements (e.g. direct site backups and farm backups), logs and storage requirements for tools (e.g. third party applications).

Don’t forget that the storage type being used has a bearing since there is an associated cost – ensure that you discuss options with your storage teams as to the best requirements. Typically, you want fast access to content and maybe slower access to archival material so make sure you have choices set for those.

Again, going back to the components that make up the SharePoint environment, confirm each of them against the above and be prepared to go to the n’th degree to ensure you are clear on whether the planning meets the provision and limitations of those components. A very good place to understand these is here: http://technet.microsoft.com/en-us/library/cc262787.aspx

I hope this has been useful to you. The second article of this one will further discuss other key parts of this process, Performance and Design constraints.