In summary an example creative problem solving approach may consist of stages, such as:

1. Exploring the problem by opening up consideration of the problem space.
2. Narrowing down the problem again by defining it based on the new understanding.
3. Opening up to a set of ideas for possible solutions.
4. Narrowing back down by selecting a subset of the possible solutions.
5. Opening up to the potential approaches to solution implementation.
6. Narrowing this down to an implementation plan.

The creativity techniques can then be used to apply many people’s minds to each of the stages. The most commonly know approach is brainstorming in step 3. There are many such techniques, however, all with different properties and needs. It is the application of many minds to the problem in a way that isn’t often achieved in traditional meetings that really gives this value for IT. Choosing the people to bring into the problem at each stage carefully will allow a much better problem solving approach. It will also mean that they will tend to buy into the solution that is eventually chosen, which can help when it comes to implementation.

So next time you have an IT problem, and most of us have many on a regular basis, consider whether a way to apply moiré creativity to it might help. If the answer is “Yes” then consider how that might be achieved – even if you can’t get out the finger paints. If, of course, you need help in doing so then feel free to contact me at sales@sarquol.com or call +44 7887 536083. The ideas can be surprisingly effective when applied appropriately.

• The most obvious approach to assure performance is to have sufficient capacity from day 1 to allow the system to perform in the long term. This means that you don’t, in theory, need to monitor the system carefully. The problem is that you then buy considerable capacity up front – which may be an expensive approach given the falling cost of hardware and the reducing time value of money. This approach is also liable to involve extensive up-front testing, which further extends any project pay back period.
• The other extreme is to have hardware, software and procedures in place to only install capacity on a “just in time” basis. This means that you only invest in capacity when it is strictly necessary. In turn that means there is more spend in monitoring, projection and control. It also leaves a question over the objectives during volume and performance testing, and exposes the organisation to a level of additional risk.
• There is an intermediate point where capacity is installed that is believed sufficient to cover a period (such as a year). This is coupled with an end of period review process that examines a need for extra capacity in time for the end of the period. This needs monitoring and projection, coupled with some purchase of excess capacity.

Thus the answer to the original question depends on the strategy adopted for capacity management. Unfortunately, the most appropriate strategy inherently depends on the individual situation. If the cost of the hardware needed in the long term is low then up front installation of the projected capacity requirement makes sense. If the organisation already has the necessary tools and procedures to meet just in time capacity management then that would make sense. What is most critical, however, is that this is a management decision made with a through understanding of the considerations and implications.

If you would like advice, or to discuss how to decide on the most appropriate approach in your circumstances, then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

In essence the ITIL approach to capacity management and that which is outlined in Sarquol’s “Principles of Capacity Management” White paper are very similar. The Sarquol Whitepaper provides some information on the “How to…” of Capacity Management and provides less information on the products and activities that are needed. The way that ITIL is constructed is documentary and procedural in nature, which is consistent with the overall objectives that it is seeking to meet. As the basis of a capacity management process it is intended to provide a foundation on which to construct an organisation’s service management approach. As would be expected, however, there is a long way to go from the definition provided by ITIL and a fully worked out process.

I can strongly recommend the design and organisational implementation of a mandatory performance and capacity management approach. If this is to be started then examination of ITIL Capacity Management will provide a strong basis for the early design. If, of course, you need help in such an initiative then Sarquol would be able to provide expertise and support. Please contact me at dh@sarquol.com, or call on +44 7887 536083.

This is a model for a new system implementation that is played out, with a few variations, for the majority of new system implementations. I have left out the blood, sweat and tears part of the story for brevity. I have also left out the successful implementation memos and party. I have left this part out because I would suggest that whether the implementation was successful won’t really be known for quite a while.

The rest of the life of the system will generally be complex, and involve change requests, and support calls. From a performance perspective, however, it is all too common for a system to get gradually, or dramatically, slower during its lifetime. Initially this may not be noticeable, but by a year or two into a system’s lifetime complaints start that the system is slowing down to the point that it is impacting the business. The way that the initial project performed, approached and managed the system’s performance and the monitoring and management techniques used dictate how likely this scenario is.

In the “Principles of Capacity Management” document I have indicated that the expected volumes of usage will need to be examined over time. As systems are used they will tend to grow both in data volume and levels of usage. This means that a system’s capacity requirements will expand over time, as will the stress on the underlying algorithms of the system. I will skip an outline of the Order of algorithms (e-mail us if you would like this included in a future bulletin), but depending on the way the system is produced this additional volume can cause complete failure. To avoid this it is important to make sure that the likely levels of future usage and data volume are estimated and built into the performance testing. Thus separate “Volume Tests” are needed to check that the system can cope with the predicted data levels for the future.

The “Generic Performance Model” supports the analysis of a 10 year time window. In the case of a new system, therefore, this can be used to project the likely performance over a 10 year lifetime. In the case of an existing system it is probably more effective to model between 2 and 3 years of past and current behaviour, with the remainder extending into the future. This model uses as its inputs the expected number of users per year and their behaviour profile. From the changes in volume figures it is then possible to calibrate the model so as to estimate the increase in resource utilisation over time. To this is added the expected architecture in order to estimate the likely response times from the system.

If you need help in working out how to approach analysing the likely future performance then e-mail me or phone me on +44 (0)7887 536083. It can be difficult at first to understand how best to approach this sort of modelling and the approaches needed to calibrate and validate the modelling. The long term benefits of this approach, however, are substantial and so well worth the initial effort.

Firms waste billions on network over-design

Who needs desktop Gigabit Ethernet anyway?

http://www.theregister.co.uk/2006/05/22/network_overdesign_gartner/

It is true that simply upgrading hardware until the system performs well can look like an effective solution in many cases. It can avoid often complicated analysis and testing work, and in many cases will be effective in the short term. Simply continuing to throw hardware at problems as a strategy, however, doesn’t really work. The issue is that solving a solution in this manner will generally be a short term fix. If the solution continues to be to keep adding more resources then eventually the costs stack up to be unacceptable. In many cases there will also be a point of diminishing returns where even the best hardware on the market will fail to keep up. A more informed decision can be made by characterising a system and estimating the capacity that may be required to meet future requirements.

The key to deciding is to consider the level of risk that performance problems will pose to the business. There seem to be relatively few organisations that use a blend of testing and future projection based on a risk-driven approach. It is this approach that is going to produce the most cost effective projects, since the degree of testing and proof provided will reflect the business risk that is inherent in the system. Spend sufficient to offset the cost of risk that a system carries if the performance is insufficient in the long term. Remember that it is likely to be much more expensive to solve a performance problem a number of years after initial delivery than when the project is in full flow. However important the initial delivery may be, a project is not complete until it has been proven to be capable of being operational for the long term.

Suggestion:

Use a simple set of standard criteria for a project representing “average” performance risk for the business:

1. A soak test to prove that the system will run for an extended period, say 12 hours, at average loading without performance degradation.
2. A load test to demonstrate that the system can process peak demand volumes for a predefined period, such as an hour, without degrading.
3. A volume test, to prove that the system can operate with production volumes at a defined point in the future – say 2 years hence.
4. Within any performance tests use a small set of key business functions to test that the system performs adequately.

If the risk related to poor system performance, or failure, is especially high then these performance criteria would be made more stringent. The degree of performance proof required, however, should be kept proportional to the level of risk in the system failing to perform well. If the system was business critical, for example, it may be considered appropriate to require that the system be run using a much wider set of business functions, for 72 hours continuously, and at 5 times the expected peak volumes for the system for the next 20 years. Unsurprisingly, as the proof requirements become more stringent the cost and time needed to prove them will increase significantly.