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.

How to be a Problem Solver

http://www.digitaltonto.com/2009/how-to-be-a-problem-solver/

The advice in it is interesting, but it also caused me to reflect on the dual nature of problem solving, and how the two aspects need to be handled almost separately. The article above more or less discusses the stakeholder aspect of problem solving with the original raiser. In fact managing the stakeholders of a problem goes further than this, as there may be a whole set of people involved with any given problem that need to be considered in solving a problem. An example is the person who is in the role “at fault”. If they are not engaged in the solution then they might consider your “problem solving” to be a threat to them, and so block progress of your solution.

The other major aspect of the solution of problems will tend to be technical. I have proivided advice on a technical process for considering solutions previously. In that article I didn’t consider the stakeholder management aspects of solving problems. It is likely, however, that at each step of resolving the technical issue it will be necessary to engage the different stakeholders to the problem, to make sure that they are bought in to the solution. A failure to do this will result in blocking behaviour, which will hamper the progress of the solution.

The following outlines a generic approach to rational problem solving that has been adapted to the situation:

1. State the problem
2. Collect evidence
3. Identify possible causes, and check they are consistent with the evidence gathered. Consider testing or gathering new evidence to prove the cause is present.
4. Look for evidence to identify the relative impact of each cause.
5. Restate the problem with causes, level of impact and confidence in the conclusion.
6. For the causes with the most significant impact decide on a set of solution options, and work out the associated costs and potential benefits of each.
7. Examine in detail potential dependencies between solutions, some will be reinforcing and others at odds. Some solutions may also have functional impact or benefits, and need to be considered beyond the performance arena.
8. Recommend the most appropriate selection of solutions, and gain acceptance of this. Remember to include obtaining the necessary budget, which may require a business case.
9. Develop, test and implement the chosen selection of solutions. Check throughout that the expected benefits will be realised.
10. Monitor the results to check the problem has been resolved to the degree expected.

This process may seem self evident to you, or it may seem un-necessarily complex and long winded. I would strongly recommend, however, the adoption of an approach that is: a) standardised; b) evidence based; c) concentrates on predicting a level of benefit; and d) proves that the level is achieved. There are few organisations with complex applications and infrastructures who have never implemented a performance solution only to find little end user benefit. A structured approach can reduce the incidence of such expensive problems.

If you would like to discuss an appropriate approach for your organisation then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

When creating test scripts via “record and playback”, however, the tool will usually record page delays and play them back during the script run – and so the problem is solved. Isn’t it?

There are two issues that must be considered here. The first follows on naturally from the comment above: If the recorded wait time is not realistic then the resultant loading will not be realistic, and so the test will be better but still not correct. This could be fixed by simply using a user who is likely to have realistic waits – assuming you can identify such a user and make them available for the testing. I can be surprising just how long real users do spend on think time.

The next issue is more important, and harder to understand. For illustration let us assume we have 10 users with a 5s think time. Let us further assume that requests usually take 0.1s to process, and that simulated users are started 0.5s apart. In normal operation these requests will never coincide. This could be an issue in itself, but this isn’t the worst of it.

Let us now presume there is a problem – a temporary server issue would be sufficient – that causes all of the responses to arrive back at the client at the same time. It does happen in load testing for various reasons. Now all of the scripts will wait 5s and send the next requests at exactly the same time. The message loading on the server suddenly goes up dramatically, and is likely to continue in this pattern for some time. The result is that the system doesn’t seem to be able to cope with even 10 users in realistic conditions.

The solution is to introduce a level of randomisation in think time delays. It is then possible to introduce an appropriate statistical think time profile – and to break up bursts. The cost is extra test script development time, but the benefit is much more realistic testing.

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

This presentation on managing performance problems was created as an overview of the techniques to use. The best advice is to start with a clear statement on the symptoms that are being experienced. The obvious symptoms will be user complaints that the system is too slow, or in many cases that it is unstable. A system that is performing badly will tend to exhibit near-random instability as different parts of the system experience race conditions or timeout behaviour. This problem statement is important because it is all too easy to find a potential performance issue and rush to solve it. Unless this issue is likely to be the cause of the symptoms being experienced, however, resolving the identified issue will not resolve the symptoms.

When investigating the source of the technical issues, therefore, it is important to relate them back to the symptoms being experienced. To evaluate whether the issue identified is likely to be causing the symptoms experienced will need many of the techniques and data sets from building a capacity plan. For example, let us assume that an issue is located whereby two functions executed on the same data at the same time will cause both executions to hang. This is a performance problem that could be located via stress testing of the system. If you have production logging of the operational environment then it is possible to state whether this is occurring around the time of the reported symptoms. If it is then there is a strong case that this is the root cause of the problem. If that isn’t available then a detailed knowledge of business process and a performance model will allow the probability of this occurring to be evaluated. If it seems probable then there is a weaker case that this is the root cause. If the probability of this happening is very low then place this on a list to be fixed and keep looking for the root cause.

Using this sort of approach it is likely that a resolution to the current symptoms will be identified and a resolution approach found. It is important to then consider whether the capacity management approach being used for a system is sufficient. System performance problems are not like hardware failures – they often develop and build over time rather than having a single point in time cause. If processes are in place to proactively manage the performance of an operational system then it should be possible to identify a potential performance problem before it starts to impact the business. If an IT department does not have this capability for all of the core operational systems then it is worth considering developing it. The development of this capability is usually expensive, but there is also significant business value in having fast IT systems. It is worth looking closely at the business case investing in improving and maintaining the performance of your systems for the business.

If you need help in resolving performance problems that you have identified, or in working out how to improve you performance management processes then e-mail me. Alternatively, if you are involved with or aware of business struggling with slow systems then please feel free to forward this bulletin to them.