On Gardens and Governance (3rd post)
This is the third in a series of posts that plays around with the idea that looking after SharePoint in your organization is a little like looking after a garden. We've been looking at the need for on-going governance of a SharePoint environment by way of an analogy: garden maintenance. Without some form of control over it, it will quickly deteriorate and end up as something that is neither a pleasure to use nor something from which you derive benefit.
Without being expert gardeners or professional horticulturalists, we've simply stated that maintaining a garden consists of three core elements:
- Maintaining what's already there
- Planning for the introduction of new elements
- Removing that which is no longer needed or wanted
The first post that provides the introduction can be found here: On Gardens and Governance (Post 1)
The second post that discusses the need to maintain the existing state can be found here: On Gardens and Governance (Post 2)
The third post that discusses the need to cover the mechanisms for introducing new elements: On Gardens and Governance (Post 3)
The last post that discusses the removal of content, sites, and people from the SharePoint farm(s): On Gardens and Governance (Post 4)
This post is going to cover the mechanisms for introducing new elements.
But first, let's start with a picture. Imagine, for some reason, that you have some form of a condition in which you find it difficult to measure or comprehend size. The brain is a strange mechanism, so this might be a possibility. For example, I have one colleague who has strong associations with colour for days. I can't remember them all, but Friday is a dull, muted brown, and each day has its own colour.
So, the condition that you suffer from is that you cannot perceive size. And off we go to a gardening centre on one sunny afternoon. As you walk through the various sections that display bedding plants and shrubs and trees, you come upon a gorgeous specimen: its leaves are multi-coloured, it has an interesting flowering, and its overall shape is pleasing to the eye. It goes onto the trolley (possibly with some effort), you take it to the checkout, to the car, and to your garden.
Except, you have no idea of its size. Remember, your condition gives you a blind spot here. Luckily, it turns out that your garden has just enough room for this prize specimen and you're able to plant it and then look at it all with deep satisfaction. Your partner observes that the garden is looking great and that, if anything, there is room for the tiniest climbing shrub to grow up against the back fence.
And off we go to the gardening centre. As you walk through the aisles, you come upon a gorgeous specimen. But your condition means that your blind to the size of it, and you put this small tree onto the trolley, through the checkout and into the car (perhaps you drive a pickup ...).
Now, you know as well as I do that the problems are going to start when you get it into the back of your garden. What had been a perfectly good garden is now undermined and the huge tree throws everything out of balance. If only there was some way of you being able to understand the impact of your decisions before your brain gave assent to the (now intrusive and problematic) tree.
The Governance Team and the Key Decision
The scenario is quite simple. We assume that we have an existing SharePoint environment that is being used within the business or organisation. There is a request for a new workload or an additional workload. For example, the platform might be providing for team sites and the company intranet and someone wants to now use it for a new workload (business intelligence, say). Or it might be that someone wants an additional template for a new type of team. You may already provide for long lived teams and now someone wants to cater for short-lived ad-hoc teams.
The point of the picture around not understanding size is to labour the point that any modification to your existing environment cannot simply be authorised without some form of impact statement. If your partner (acting as your governance team) had been able to pull out a plan of the garden and demonstrate the impact of the second tree, it wouldn't have been bought (it wouldn't have been authorised for deployment) and the problems would have been averted.
So, it turns out to be a very simple and straightforward decision when considering new/additional workloads:
- Understand your system's capacity
- Understand the performance characteristics of the proposed workload
- If item (1) can bear item (2), grant approval
- If item (1) cannot bear item (2), create more capacity
Whilst item (4) could be the subject of its own series, in essence it comes down to whether you need to create a new farm or augment the existing resources.
If the Governance team are the body that should make the decision, they need two key pieces of information: the capacity of the current system and the performance metrics of the proposed workload.
Well, luckily for us, there's no reason why we need to be blind to either our SharePoint environments or the size of new elements that we want to introduce to it. The two mechanisms that come to our aid are SharePoint 2010 Capacity Management and SharePoint 2010 Performance Testing.
Although this set of articles is aimed at the "why" rather than the "how", it's probably worth discussing both Capacity Management and Performance testing in a little detail.
The five steps that save you from disaster
You can find detailed information about these five steps at the Capacity Management link. This outlines five steps:
- Model
- Design
- Test and Optimize
- Deploy
- Monitor and Maintain
Model
Models are approximations of the real thing and they can vary in how realistic they are. For example, consider the following models of an aeroplane:
- Plastic toy
- Home console flying game
- Remote controlled plane
- Pilot training simulation
Each of these is a model of the real thing. However, each becomes more complex and more realistic – more like the real thing.
Making a model, then, is about identifying and replicating some core characteristics of the entity under consideration. The degree of fidelity with which these entities are replicated equates to the degree of realism of the model.
Your model, then, of your SharePoint environment should provide you with a simplified description and understanding of the system. Be wary of getting into too much detail. Be wary of making it too realistic. It needs to have just enough information for you to be able to understand the impact of decisions around new workloads. As such, you need to address the number of concurrent users that it supports, the requests per second that it can support, and the load distribution over time, etc.
And when building your SharePoint model: start small, build slowly, refine constantly.
Design
This is simply the record of your logical and physical design.
The design provides the specifications and number of computers that are used in your system and it is tightly related to the number and type of workloads that you can support.
You'll not be surprised to note that part of Capacity Management results in decisions to upgrade the hardware and also to possibly introduce new hardware. And as long as the Governance Team have Capacity Management as a regular item on their monthly agenda, I'm not too worried by folks who need to source their hardware before they really understand what the system is being used for ("We might start with Team Sites first and then introduce Business Intelligence. Or it might be the other way round. We haven't decided yet"). This approach is fine as long as you are reviewing the system's performance and are prepared to expand it as necessary. And in any case, the initial system is usually sized for the whole workload, in any case.
Test and Optimize
This is the most critical stage. I also think it's the one that is most likely to be skipped. But skipping this is dangerous. This is the stage where you are able to determine the impact of the new workload.
This is the underlying assertion: before anything is introduced into the production environment, it should be first tested in a separate environment.
It's the "separate environment" that proves to be the most difficult piece of this whole process. In effect, you need to have a Test environment that replicates, simulates, or models the Production environment. As this comes down to cost, some organisations refuse to bear this or provide minimal resources to it.
Well, bear in mind that the Test environment only needs to "simulate or model" the Production environment. So, it doesn't have to exactly match. You might have fewer physical machines (e.g., less web front ends and a single node database server) or the system might be implemented in a virtual manner.
This makes it possible to have a reduced cost system that can be used to determine the impact of the new workload. But I would maintain that you need to trial the new workload in order to determine how it will impact existing ones.
You should conduct acceptance testing in conjunction with monitoring the performance characteristics to make sure they remain within the constraints of your model. This allows you to identify and optimize potential bottlenecks before they impact users in the Production environment.
And don't forget that as well as the performance impact, you are also testing the operations procedures to ensure that the new workload can be introduced, operated and then maintained by your Operations Team.
Deploy
As a result of the Performance Testing and the deployment trial runs by the Operations Team, it may be that a number of modifications to the Production system need to be effected. For example, it might be that a farm-wide feature needs to be activated, some computers might need additional memory, or perhaps a new farm needs to be instantiated.
If you've done all the above, the actual deployment into the Production environment should be something of a boring and tedious affair and you will have introduced the new tree into the garden in a controlled and measured way.
Monitor and Maintain
And this takes us back to Post (2): Maintaining what's already there.