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

The field of business strategy has looked at this issue of an uncertain future and come up with a number of approaches for managing considering it. One of these is called “Scenario Planning”, and basically consists of building a set of different future scenarios which are considered plausible. They are not attempts at predicting the future, only of painting plausible futures. It is then possible to consider how these scenarios may play out according to the decisions you are taking now. This allows a form of sensitivity analysis on the decisions that you are making.

A process for approaching this would be to:

1. State the architecture decisions that need to be made.

2. Identify the major environmental forces that impact on the architecture.

3. Build four scenarios based on the principal forces.

4. With the scenarios in hand, identify architecture opportunities within each scenario.

5. Examine the implications of the decisions across the range of scenarios.

As an example, lets assume that you need to decide between two architecture design patterns, A and B. For the example “A” provides a highly resilient and fault tolerant solution but involves significant additional hardware, operational administration and development costs over “B”. The decision that needs to be made is whether the extra capability of “A” is justified. If this is a new system then it may not initially require large processing volumes, and may be able to accept a system outage. The scenarios, however, could be used to examine under what circumstances the additional capability would be justified. If the system catches on, for example, how long might it take for the system to become business critical? Would you have time to re-engineer it? This may lead you to decide the additional capability is justified now, or would allow you to understand what changes in the environment might lead to the additional capability being needed.

In terms of the Architecture Roadmap then, the Scenarios developed and decisions taken may then be included in the roadmap. With this in mind a Planning Scenario is chosen. This defines the assumption set on which the roadmap has been built. In doing so, however, the other scenarios are not discounted but used as alternatives to which to architecture should be resilient. Where the architecture isn’t resilient to a scenario, then the roadmap will be able to indicate symptoms that will indicate that the architecture needs to be revisited. These then become business risks that must be managed based on the selected architecture.

All of this seems relatively complicated, so why bother? The answer is that architecture decisions are taken on a regular basis under the in the knowledge that the requirements of the system are known and understood. This may be true of the explicit requirements elicited from users, but these are based on assumptions about the future. In reality the future is generally much more surprising than we would like to believe, and so taking the time to consider what this might mean for the decisions you are taking can be worthwhile. An exercise like this can be considered surprisingly quickly, and may significantly help decision making.

The CMMi has been developed and integrated with other approaches and become the CMMi. This process has increased its apparent complexity, as well as its flexibility. The information on the SEI web site (link) has split into either detailed manuals of CMMi and presentations that primarily seem to say “Why you need to buy in our consultants…” The CMMi has been adopted by large players and so there is a strong consultancy market surrounding it, including training and appraisal of your organisational level. The manuals are reference material and not intended to be a thrilling read. The presentations do well at selling CMMi benefits but don’t offer much in the way of a “how to guide”.

The best links that I found to describe the CMMi to allow a quick “Is this for me assessment were:

Tutorials point:

http://www.tutorialspoint.com/cmmi/cmmi-process-areas.htm

Wikipedia:

http://en.wikipedia.org/wiki/Process_area_(CMMI)

These sites provide an overview of CMMi at a level more suitable for someone who needs simply to understand the core nuggets of wisdom contained in the CMMi. The still are quite long though, so here is a quick summary of the summary…

CMMi is structured to allow consideration of how an organisation does things, for simplicity I will assume it is software development that is being performed. The CMMi assumes that the road to improvement means ending up with a standardised approach for doing this which can be measured, optimised and customised to the situation in a controlled fashion. It has this in common with many “Quality” processes including the international quality standards. It asserts that there 5 levels of maturity:

• Level 0 – Incomplete – We can get there, we’re sure we can. Not sure how though, and sometimes it don’t quite work right.
• Level 1 – Performed – We can do it as long as it is about the same as the last time.
• Level 2 – Managed – We can do it, and we can manage the process.
• Level 3 – Defined – We can do it, and have a definition of how.
• Level 4 – Quantitatively Managed – We can do it, and can provide numbers about how well. After all what you don’t measure you can’t manage!
• Level 5 – Optimising – We can use the numbers as a basis for continual improvement of how well we do it.

The idea of CMMi is to move up between the levels, and the way to do this is to develop various process areas in your organisation at each level. The areas form a structure, so it is very hard to fully benefit from a higher level process until the lower level ones have been addressed.

The processes organised by level are:

Level 2:

• Requirements Management
• Project Planning
• Project Monitoring and Control
• Supplier Agreement Management
• Measurement and Analysis
• Process and Product Quality Assurance
• Configuration Management

Level 3:

• Requirements Development
• Technical Solution
• Product Integration
• Verification
• Validation
• Organizational Process Focus
• Organizational Process Definition
• Organizational Training
• Integrated Project Management
• Risk Management
• Decision Analysis and Resolution

Level 4:

• Organizational Process Performance
• Quantitative Project Management

Level 5:

• Organizational Innovation and Deployment
• Causal Analysis and Resolution

It is likely that if you are having quality or delivery problems that by looking at these process areas in turn and considering whether you “Do that” you can start to gradually improve. The CMMi manuals have a lot to say that can support you, or you can start looking on Google etc. for ideas that might help you improve.  If you need help then seek outside help – it can be value for money. If you need to be certified to a certain level then the game is very different and outside input becomes a necessity.

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.

What Garner have done it to convert this trend into a pseudo-scientific analysis method, and then to look at various technology areas in this light. The result is a set of reports that looks at areas of technology and state where on the curve the various technologies are, and predict how long it will take before the technology gains mainstream adoption. The reports make for interesting reading, but should people use Gartner’s opinion within them in order to develop their strategy. To say the least the idea of the hype-cycle has its negative side, as illustrated by this article.

The challenge is that the hype cycle is basically a Gartner opinion about the future, and any opinion about the future is likely to be wrong. This needs to be borne in mind if you are planning to develop a strategy based on the hype-cycle. So what could this hype-cycle be used for? My own though is that it is reasonable to use it to consider which technologies are most likely to be of use to you in the future. That is, to prioritise the application of you own analysis.

The reports contain a summary of each technology, and this can be used to consider whether it would be applicable to you if worked fully.  The position in the hype-cycle and the length of time Gartner predicts to full acceptance, however, should be considered in the light of the potential benefit of the technology to you. To make a decision, if the technology has sufficient potential value then it is worth trying to build a serious case for whether it is worth being on the bleeding edge of this one. In doing so, however, be aware that working on the bleeding edge has its own management challenges that need to be considered and mitigated.

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.

The quick answer is that “yes it can be true”. A little more analysis would be needed to be absolutely sure it is true for a particular implementation. This can be validated by considering what happens for a disk read: The OS will request a data block from the disk. The block may be cached, but if it isn’t then a disk read is necessary. It is not uncommon for such a read to take of the order of 10ms to complete, and the request is likely to be queued behind other requests. This is then returned to the processor.

This process is basically the same whether the disk is a storage device or a local disk. For a network device, however, there is a cache at the client and another at the server and network communication between them. The storage on a network device, however, is also likely to be spread over more disks and so the number of requests being queued to each disk will be lower. The data may also be stored as copies in multiple places, which again allows optimisation of requests and reduced queuing. The server side cache is also likely to be much larger than the cache on a standard production server. The network communication overheads are therefore traded for improved disk storage mechanisms in a dedicated device. To look at a particular instance, however, would need consideration of:

a)     Network interface efficiency;

b)    Network loading and communication efficiency;

c)     Relative disk performance;

d)    Disk duplication mechanisms, allocation strategy and efficiency;

In most cases a high quality storage device with a well designed network link will outperform a standard set of local server disks.

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.