One challenge that I face all the time is that, as an Architect and Developer for SharePoint, I am charged with designing systems and solutions to meet business requirements…often without any business requirements. Recently I was asked how I would tell Business Analysts to gather requirements for SharePoint and I realized two things. The first is that I am NOT a BA…I do a decent job of getting what I need from clients when I have to fill the BA role, but my knowledge is self-taught and lacks a common vocabulary. The second thing is that SharePoint requirements are not really all that different from any other requirements…but that vocabulary tends to get in the way again. Thus, this article was born…a chance for me to explain what I look for as a SharePoint architect so that other BAs can learn to gather what I need.
This really is a very large topic, so for this first article I want to tackle the first thing that I am usually called upon to answer. In future articles I plan to talk about other topics like Information Architecture, Navigation Planning, Site Planning, Solutions Design, Governanace and perhaps more. But for now…
Farm Size and Setup
SharePoint being an odd beast, the proposed solution is often just a small portion of the work that the farm is going to be supporting, and often the initial project is just the starting point for rolling out SharePoint to every user in the enterprise and providing them with lots of functionality…none of which is in the scope of THIS project. Still we need to know a few things:
- User Load – How many users will be making use of the system. This includes the initial users for the proposed solution as well as the total number of users that will eventually be using the SharePoint system. Another aspect of user load is the use profile for the roles in the system. This is important because roles that hit the farm constantly all day require more resources than those that just hit it occasionally.
- Availability Requirements – Ask the business how much non-scheduled (or scheduled) downtime they can accept in the system and the answer will usually be five 9s (99.999% uptime, which is 6.05 seconds per week of downtime). I request that you really dig into this requirement because that amount of money required for five 9s of availability will definitely put a crimp into most budgets. If they truly need it, then they will be willing to pay for it…but most clients don’t really need it.
- Disaster Recovery Requirements – Here I usually want to know four things (Is DR required, Is there an existing DR strategy, what is the maximum amount of data/time that can be tolerated when DR fail-over occurs, and what is the tolerance for failing-over). DR really is a crucial part of making a system robust, and some clients don’t think about it. Others figure that SharePoint will just be a part of their existing DR strategy…and that might work…as long as they are willing to accept significant delays in standing up a new farm when all we have to work with are their SQL backups. Setting up a true DR strategy with low Recovery Point and Recovery Time Objectives is, in many ways, more expensive than creating a Highly Available system, but for an organization that truly understands the value of that lost time, it is critical to the success of the system.
- Performance Requirements – The biggest question here is what is acceptable performance to the end users. Sometimes this is an average page load time, but I would point out that transaction time is a much better measure of performance (being the time that it takes to complete a multi screen transaction, including data entry). You can read some more about this in my series on how to Performance Test for SharePoint Part I, Part II, Part III, and Part IV.
- User Location – Another critical function is where the users who will be using the system will be located. Are they all internal to the corporate network? Are external users going to need access to the system, and if so, to what parts? Are those users part of the company (employees for example), or are they consumers or partners? What is the current security technology that is used by the client? Do they have a software gateway (like Microsoft’s Unified Application Gateway), or a firewall? Find out as much as you can both about the initial state, and any future plans for growth now to make my job easier.
Those are a few of the requirements that I have to have to even think about sizing a SharePoint farm. After all, there are only a few options available to us, but if we make the wrong choice now, then there will have to be a big project to fix it later.
From these requirements I can likely create farm diagrams and design that layout of the farm(s). Next up we will tackle Site and Navigation Planning and what the Architects and Developers will need from the BAs to actually build out that part of the project.