1. Product innovation, whereby a new product or service is brought to market or a current one improved;
2. Process innovation, whereby processes and procedures are modified to make them more efficient
3. Positioning innovation, whereby a product or service stays fundamentally the same but is sold to a different market or as a different proposition
4. Paradigm innovation, whereby an innovation is effectively disruptive and facilitates some form of fundamental change

This is an interesting way of looking at the possible innovations available, especially since it is likely that one company might be pursuing more than one of these approaches at the same time. On reflection, however, I found it more interesting to consider where one type of innovation is purported to be another type. It is clear that this happens in the IT industry on a regular basis. The release of Windows 7 is an example, whereby the change is quite clearly a Product innovation in that it has changed the way Windows works internally. The product, however, is still Windows. Looking at the Advertising of the launch, however, one might be forgiven for suggesting that Microsoft is trying to position the change as a Paradigm shift. I believe that this allows them to “spin up” the perceived value of the new Windows version to users. I would suggest that some of the “Green IT” initiatives (c.f. “Green wash”) are similarly positioning pre-existing products as environmentally friendly initiatives.

Is it also possible, however, to position a change the other way? If you have a change that fundamentally changes the way that a business works then might there be value is positioning it as a simpler product or process innovation? In doing so the threat that the change poses to stakeholders might be downplayed and so allow a change into the environment that would otherwise meet excessive resistance. I can see that there might be good reasons for doing this, but would this be unethical? That is a difficult challenge that I suspect would need to be dealt with on a case-by-case basis. I don’t believe that the process has to be inherently unethical unless you really are getting an organisation to take on more cost and risk than it would otherwise be willing to do. This, in the final analysis, is the ethical challenge of any form of spin. When does “spin” spill over into out and out lies?

In more practical terms, it may be worth considering this as a checklist when introducing a change which is innovative, and in IT most of our significant projects are effectively innovative change to someone.  Once the innovative direction is considered then there will be consequential considerations that need to be taken into account. In the case of process innovation, for example, there will be a need to focus on the people who will be receiving the change and engaging them as early as possible. In a product innovation scenario, however, it is much more likely that simple communication about the changes will be necessary.

If you wish to read the article it is: “Francis, D. and Bessant, J. (2005), ‘Targeting innovation and implications for capability development’, Technovation, 25.”

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.

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.

First of all, however, let me steal a definition of strategy from the Open University:

“Strategy is the pattern of activities followed by an organisation in pursuit of its long-term purposes.”

This is a slightly strange definition, but an important point to note is that it doesn’t mention change or planning. The planned change approach to IT strategy seeks to examine what is happening in the IT industry; decides which technologies will win and then tries to implement those in current projects. Thus, the strategy is seeking to modify projects to use what is perceived to be the best selection of technology trends.

I would assert that the reason this doesn’t really work is that this is both trying to guess the future, and it ignores the “in pursuit of its long-term purposes” part of strategy altogether. The IT strategy of an organisation should be closely aligned to achieving the strategy of the organisation as a whole. This, in turn, should be closely aligned to the organisation’s long-term goals and objectives. Anything less than this is playing with new technology, or worse following the IT suppliers’ strategy and serving their purposes.

The real difficulty occurs when a project is asked to deliver a “strategic solution” which doesn’t actually provide a benefit to it. The delivery projects usually represent the delivery of the overall business strategy. To impact them negatively is to impact business strategy for the benefit of delivering IT strategy.

This is not to say that the selection of technology from those that are emerging in the market isn’t important. The key difference is to choose those that are:

• likely to exist in the long term;
• are sufficiently mature to be useful; and
• will improve the delivery of current or planned projects.

This is not, however, an easy thing to do. In particular there is a real challenge to make any strategic technology choices at all – since there will be a tendency in projects to select a diverse set of technologies.

If the improvement of current or planned projects is clearly maintained, however, then it should be possible to strongly engage the organisation’s non-IT people in the delivery of the IT strategy. This would solve the issue of the strategy being obsolete before it is implemented, and decrease resistance to implementing strategic solutions. The IT strategy group does, however, need a more subtle set of influences to be successful than simply stating: “Do it this way because it is strategic”. If they truly have a case for their strategic approach this should be possible. If they can’t make a positive impact overall for projects then they should question if their changes are truly strategic.

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

It seems that each new version of a product tends to be claimed by its manufacturer to perform better than the last, and be more scaleable and so forth. It is also true, however, that the system products around at the moment could not have run on the systems available even a few years ago.

The cycle of upgrades definitely serves manufacturers well, as the need to stay supported fuels software purchase, which fuels hardware purchase and so forth. On the back of this manufacturers also add new software features that increase the power and flexibility of the tool set. It is common, however, for upgrades to be performed purely to stay on a supported release – indicating that the customers often upgrade because they have to rather than because they see benefit in doing so.

Do we really need all this to do the job – or are we just buying in to the products the manufacturers want to sell us?

An interesting example of technical innovation has come to my attention recently. Data federation was recommended as a way forwards for an information management system. This is an innovative way to build a data warehouse without copying and moving data into a central store. It comes from the Service Oriented architecture stable and has been “main stream” for a while. It should have significant benefits if you believe it really works. One of these benefits should be that good performance is achieved by having a caching and management layer above the production databases. The fundamental question was whether it could perform well enough in the environment we needed it for. Was acceptable performance achievable using this innovative technology?

I have been left wondering why this should be so in a number of organisations who are all highly professional in every respect. An explanation that depends on short sightedness or lack of strategic thinking is insufficient, as the organisations in question succeed in highly competitive and complex environments.

My belief is that it relates to the stakeholders within the different parts of an organisation and their input to the development process. It is very difficult to deliver a business change programme, and the time scale is always as short as possible. Most organisations roll-out new software technology in an incremental fashion, and so they believe that they will buy time to fix any performance issues as they occur. The project delivery is primarily driven by stakeholders who wish to drive the change as quickly as possible with as low a schedule risk as possible.

When the system is in production there is usually a warranty period, and then the system transitions to an operational state. In the operational state the stakeholder drivers are to minimise maintenance costs. Thus fixing the issues that haven’t appeared yet will not be a high priority – especially since there are usually plenty of issues that are a high priority to work on.

So what is the answer? Unfortunately it depends on the organisation and their culture. In a highly structured and procedural culture the answer would be to make sure that there are identified procedures for following through the need to complete performance assurance. In a less structured culture the answer would be to make sure the operational stakeholders have sufficient power and understanding to put in place protective measures. If you need advice please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.

The most valuable way to validate a performance model is to monitor a production environment and then to check that all of the predictions of the model are reflected by the production system within a reasonable tolerance. This allows all of the assumptions and mathematics to be checked in a single stage. The practice should be a matter of routine after the implementation of systems, and acts as an important operational performance assurance activity.

In the time before the initial implementation, however, it is only practical to check the technical aspects of the model using a set of performance tests. Thus, it is possible to test using a defined level of user load, and to make sure that the predictions of the model match the performance profile experienced to within an acceptable tolerance. If not, the reason for the differential needs to be investigated and resolved. It will usually be necessary to run a series of tests until the model’s accuracy is sufficient for the model’s use.

It is important to stress, however, that this form of validation still leaves a significant level of uncertainty about the level of demand to be placed on the system. It is worthwhile, therefore, using the model to predict the likely performance under a range of demand-profile assumptions. At least the impact of the level of unknown for the demand can then be investigated.

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.

When working with the team I would acknowledge that their approach was effective, but thought it too “front heavy.” The team acted as a limiting factor on the timely delivery of system projects, and the rigour they required was sufficient to manage the system in the long term but seemed unnecessary for pilot delivery. Their assumption was that once a project was delivered to production then there would be no further capacity management applied unless there were production issues – which would then be their problem to see resolved. Thus the system had to be proven as fully suitable for production before it was allowed in. I now have experience of the full lifecycle of a number of projects. This includes being brought into projects when they have run into performance issues a number of years down the line. The governance approach that the employer took was definitely correct, even if they could have been a little more cooperative in letting the system into pilot.

To be clear: A project must plan to provide evidence that the system they are putting in will perform well in the long term. A project must have clearance for, and so sufficient business benefit to fund, the capacity that will be needed to run the system in the long term. A project is not complete until it is proven that it will perform correctly in the long term, and there are monitoring methods in place to make sure that it continues to perform. If a system is allowed into pilot before this point for expediency then the project still has to complete its evidence generation and sign-off before the system is accepted into full operation.