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.

So, what’s the catch? According to Gartner’s hype-cycle Cloud Computing is at the peak of its inlated expectations and will take 2 to 5 years to become mainstream after plummeting through a trough of disillusionment. I would agree with them that the technology has significant potential issues, but the presentations of what has been achieved at Gigaspaces’ Cloud Crowd event were significant. There are significant potential issues in adopting the technology, and so strong architectural and project governance will be required but there are solutions to many of the potential issues.

As an example, in many applications the safety of committed data must be paramount. Losing a few transactions because of unforeseen events is just not acceptable. A solution to this is to write to a database, or use a connector to another application out of the cloud. This can, however, decrease performance and increase development complexity. To help in this area NT/e have added to the technology pile a system called CloudTran. The solution provides a database connection mechanism with simplified development and a potential for performance that is much closer to that of the rest of the cloud software. The result should be an acceptable level of data safety without removing the benefits derived from the massive scalability.

Thus, if you have a project that needs this sort of capability then Cloud Computing may be worth consideration. Its potential is significant, but treat it as a leading edge technology. Use strong architectural governance, proof of concepts and consultancy from the supplier to ensure that everything is being used effectively. The result, however, might well be a system with strong capability 2 to 5 years ahead of its time.

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.

http://www.businessgreen.com/

Among its articles is this one about the green IT:

http://www.businessgreen.com/financial-director/comment/2214911/emerald-city

The article concentrates surveys about the state of green IT, and the lack of trust that IT purchasers have in the “Green” claims of suppliers. The rush to green wash products is leaving many, me included, sceptical that the benefits extend to the environment and purchasers bank balance – rather than the suppliers.

It is true that there are products that have the capacity to reduce IT’s carbon footprint and hence have real environmental benefits. It is these that need to be examined in the search for a coherent and effective green strategy. If implemented correctly these should also have a reasonable payback period – since the energy consumption will have to be paid for if it isn’t saved.

Without buying new technology, however, it is worth pointing out that only deploying the capacity actually needed may be a strong green IT option. A strong capacity management approach will mean that only the capacity actually needed in the short term will be operating in the data centre. Thus, only that hardware will be using space, power and cooling. If your capacity management strategy is to have sufficient capacity from day 1 to allow the system to perform in the long term then this may be inconsistent with any green agenda.

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

Table of contents for Performance Model Example

1. Performance Model Example
2. Example: Function definition
3. Example: Defining users and locations
4. Example: Usage Definition
5. Example: User demand estimation

Having defined the key system functions and the user population it is now necessary to define how the users place a functional demand on the system. (The online version of this article has more detail again.) The first part of this definition is to lay out how the usage of the system varies over time. Thus the relative usage of the system needs to be defined. The initial definitions are on an intra-hour, hourly, daily, weekly and monthly basis. These figures effectively have no units and simply provide a relative level of usage. Thus any metrics that are available to allow calibration of this data can be used. As an example, estimated percentage utilisation of the system for the time period could be provided. Alternatively, there may be historical data available from a production system.

In the majority of the usage profile sheets the data entry allows a default profile to be entered at the top of the sheet. This can then be varied for individual user sections where they vary significantly. Thus, for example, most of the user sections have similar behaviour this would be used for the default profile. The significant variations from this behaviour would then be entered individually for the separate user section rows that this was required for.

There is a further possibility of varying the use of different functions within a time period, in our example there is likely to be a bias in the number of payments created and approved around the cut off times for making those payments.

The facility extends to a monthly and weekly specification:

The “Intrahour” entry is different. In this case a simple ratio is provided between the peak activity within an hour and the average activity for the hour. This value represents the relative activity instability of the system under consideration, with a higher value representing a system with very unstable usage within any given hour.

The “Annual” data entry is different again. In this case a reference year for the modelling is defined, and the modelling extends for ten years including this starting year. The number of working days per year is also entered in this sheet, and then the size of the user population for each user segment in each year. Thus, the expected population growth for each of the user segments may be defined over a ten year period.

Note:In this exmple it is worth noting that the “User population” count for the email and standing order systems has been set to the expected number of items per day. This is a useful modelling mechanism in the case of batch oriented processes.

Lastly in the definition of the system demand by the system’s behaviour types (“Behaviour type function usage”). In this case the average use of each function by each user per day broken down by behaviour type. Using all of this information it is possible to calculate a detailed profile of the expected system demand. This information and its usage will be examined next.

Yahoo! outsources! India’s! giant! supercomputer!

This is a HP/Yahoo initiative that seems to be a match for a recent IBM/Google move.

The idea of hiring out computer power is obviously not new. Sun are already in the market to hire computing power and deliver it to organisations using the Internet. It is interesting to speculate as to why Yahoo and Google want to hire out this technology to academics. I wonder if they see themselves as better placed to deliver this computing for hire to business than the traditional technology companies. If there were a realistic possibility of hiring short term processing power for small to medium businesses then I can see there may be a market for it. This is not, of course, the reason that is given in the press releases.

Table of contents for Performance Model Example

1. Performance Model Example
2. Example: Function definition
3. Example: Defining users and locations
4. Example: Usage Definition
5. Example: User demand estimation

Location definition

Specification of the locations within the model

Behaviour type definition

The next set of information to define is the behaviour types to be used in the model. In this case the main behaviour types being modelled are: Retail Banking, Corporate Users and Corporate Managers. To this are added behaviour types for the email processor and standing order processor, which will be used to model the batch processing within the system.

Specification of the behaviour type within the spreadsheet

 User Section Definition

Now the sets of users themselves can be defined to link locations and behaviour types. Thus, there would be corporate banking users and managers in the UK, New York and Europe. For this example, Retail baking users are only to be found in the UK, whereas the batch processors are located in the primary data centre. This is defined within the “User Section” sheet, which literally defines the different sections of users by their behaviour type and location giving each a representative name.

Specification of the user structure within the model

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.

• 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.