What is Technology Maturity?

@madgreek65 asks whether cloud computing is "mature", and whether it matters (What the masses are missing about the cloud).

I suggest that there are several characteristic features of a technology or product, indicating whether it is mature or immature.

	Immature	Mature
Stability	Subject to frequent and significant improvements. In a state of "permanent beta".	Stable. New releases are fairly predictable upgrades.
Technology-in-use	A small number of early adopters trying ambitious stuff. Little consensus about how the technology should be deployed and used.	A large user community doing similar stuff. Use of the technology has become standardized "best practice".
Growth	Large untapped market. Rapid growth possible, under favourable conditions.	Relatively little scope for further growth.
Metrics	Absent or unreliable	Systematized
Adoption Risk	High	Low
Adoption Benefits	Potentially high	Moderate

This notion of technological maturity has the following consequences.

1. It is unrelated to quality or value. A mature technology or product can be unimaginative, boring, almost obsolescent, whereas an immature technology can be visionary, exciting in conception and engineered to the highest standards.

2. Maturity is as much to do with the community of users (technology-in-use) as about the designed products (technology-as-built).

3. The adoption roadmap for an immature technology may be rather complicated. One of the main reasons for this is that the adoption programme needs to bridge the gap between technology-as-built and technology-in-use. There is also a common preference for a cautious stepwise approach - pilot projects, proof of concept and so on. But the stakes can be much higher.

As Mike points out, for any technology that is in the hype phase, there is a lot of resistance to change, and this is certainly true for cloud computing. Mike suggests that a lower-risk adoption approach will win over the sceptical.

"The reason why I encourage those who are pessimistic about the cloud to try one of these low risk scenarios is once they see how easy it is, how productive they can be, and how inexpensive the project will be, then maybe they will see the value and investigate further."

For many people, this is the preferred approach for an immature technology. However, there are some specific risks associated with a slow adoption curve, which I shall discuss in a future post.

IT suppliers face architectural risk

@tonyrcollins reports on the implications for large IT contracts of the Centrica v Accenture dispute (Computer Weekly, 9 December 2009). The dispute concerns a "best-of-breed" replacement billing system for the entire British Gas business, which Centrica ordered from Accenture in 2002.


Centrica is invoking a clause in the contract that refers to "fundamental defects", and a lot of the legal activity has been trying to determine what this phrase actually means. Although Accenture argues that the various problems experienced with the system have been unconnected and therefore don't count as fundamental, the High Court has accepted Centrica's interpretation that the cumulative effect of these defects may indeed be regarded as fundamental.

 The article quotes Peter Clough, head of disputes at law firm Osborne Clarke:

"One of the important points to note about this case is that IT suppliers can be liable for claims for fundamental breach arising from the cumulative effect of a series of faults, each of which could look relatively minor in isolation. The majority of systems will of course be inter-linked so that a defect in part of the process could affect another part, snowballing into a more serious issue."

So this is about architecture and risk. From a risk management perspective, a critical responsibility of the architect is to make sure that a lot of small problems don't add up to a big problem.

And it is also about procurement and risk. If this judgement stands, it appears to shift certain kinds of risk from the customer to the supplier. Obviously one solution to this would be to redraft procurement contracts. But another solution may be that large IT suppliers may be required to engage much more proactively with the broader architectural context for the systems they are building.

So can we expect all the major IT suppliers to look at architecture and risk from a new perspective?

Crowdsourcing Policy and Politics

@ruskin147 and @bryanglick draw my attention to a crowdsourcing experiment by @craigelder, Online Communities Editor at the Conservative Party, who has posted a leaked copy of a Government IT strategy onto a website called Make IT Better.

Rory Cellan-Jones posted a question on the Make-IT-Better website asking whether comments made there would feed directly into Conservative policy. Well obviously the Conservatives cannot commit in advance to using every comment, as some of them may be too idiotic even for the fringe parties. Craig Elder is too polite to spell this out, but in his reply to Rory he does acknowledges that the Conservatives will "pick out the best ideas that fit with our political narrative".

But "narrative" suggests not merely policy formulation but also political debate. In other words, they reserve the right to use any comments posted on their website as a stick to attack the present Government. However, it is good that the BBC is monitoring this crowdsourcing experiment, and I trust that Rory and his colleagues will catch any overly party-political use of this material.


Having said that, it is difficult to see anything much in the comments from which any political capital could be made. Most of the comments seem to be at a purely technocratic level - discussing the detailed opportunities and threats of particular technologies, and barely discussing the overall vision for public sector transformation. There are a few comments raising serious challenges, but these are posing questions for the Conservatives as much as for the present Government, and it is difficult to see how the crowdsourcing experiment in its current form will contribute to finding answers to these questions.

Having read some large chunks of the original Government IT report, together with many of the comments, I am minded to do a deeper analysis of the issues, but I may not be able or willing to cram the results of my analysis into a small comment box on a party website. However, I shall monitor the experiment and post any further comments here.

Confusing Expenditure and Investment

@jpmorgenthal offers A Better Metric for Analyzing the Value of the Cloud.

I agree that the concepts of ROI (return on investment) and TCO (total cost of ownership) don't really work. One reason is that they confuse expenditure with investment, and ownership with use.

Proper investment is what people like Warren Buffett do - buy a railroad in the hope that it will increase in value. Real estate investors may buy a plot of land, build something on the land, and then hope to get their money back by selling or renting the units.

Buying a car isn't an investment, even if the car salesman says it is, unless you are buying a rare antique vehicle that will appreciate in value. Buying IT is like buying a car - you want a car because it's going to be faster than walking and more convenient than taking the bus. You think about the purchase cost and the running cost, and you consider how much you can afford.

Depending on your lifestyle, you might decide that it works out cheaper to rent a car when you need one, than to own and pay parking charges for a car that sits idle most of the time. Alternatively, if you drive to work every day, it might be a lot cheaper to own your own car. In this context, the purchase of a car might count as an "investment", justified in terms of cost-saving.

Using The Cloud is like having a fantastically good public transport system, so you don't need to buy your own car. The city authority invests in public transport so you don't have to. The private citizen doesn't invest in public transport, just spends money when he uses it. Isn't this what the Cloud is like?

Next Practice Industry Analysis

Is the business model broken for traditional industry analysis? Or is Carter Lusher right to argue that the traditional advisory analyst model is thriving?

It is certainly true that the large analyst firms continue to make money from a largely symmetrical analytical model. As I see it, the problem with this symmetrical analytical model is that it fails to deal with some of the critical complexities (asymmetries) of the software market, and therefore falls short of providing genuinely useful guidance to its customers.

• The first asymmetry is that the product is not the technology. Software products do not always fit into neat technological categories, but typically provide a shifting and overlapping bundle of features.
  

• The second asymmetry is that the business is not the solution. Classifying a software vendor is not much use, when the relative advantage of one vendor over another changes dynamically with each announcement (especially mergers and acquisitions).
  

• The third asymmetry is that the value of a given solution is relative to the context-of-use. As @monkchips puts it, business success is not a function of IT purchasing. That's why the traditional IT analyst business is broken.
  

Furthermore, the symmetrical analytical model is not compatible with a multi-sided business model, in which analyst firms may appear to have a conflict of interest between taking money from vendors and providing disinterested advice to purchasers.

@mcgoverntheory reckons analyst research tells you what people were thinking about yesterday, not tomorrow. It's like driving a car using a rearview mirror. 

If all you want is an expensive analyst report that absolves you from blame if you buy the wrong product, then you can spend your money on the large firms. But if you want to engage critically with technology and make intelligent judgements about what you are going to do with present and future technologies, then you need to participate in a different kind of conversation.

A Long Shot?

William Hill, the UK bookmaker, is offering odds of 1000/1 on the possibility that the latest footballer baby will become prime minister. (News Release 3 November 2009)

Anything's possible, I guess. But from an IT perspective, my first thought was for the extraordinary cost to William Hill of this publicity stunt. Given that people can become prime minister at any age, William Hill is going to have to maintain records of these bets for at least seventy years. What are the lifetime IT costs of this commitment? Not cheap.

I suppose the upside for William Hill is that the punters will have to stay in touch with William Hill for the duration.

I have no idea whether the planners at William Hill thought through the implications of this, but there are too many organizations where the IT implications of an apparently minor business decision would not have been considered until it was too late.

---

Further clarification having discussed this with @EnterprisingA on Twitter.

1. I never said William Hill itself was wrong or foolhardy. I merely raised the question whether this had been thought through, and said I knew lots of organizations that would probably fail to do so. Jon suggests that good EA should help to resolve this kind of thing, but of course that would only be true if EA could anticipate all possible future business ideas, or were consulted whenever such business decisions are made.

2. Maybe assuming an IT solution was jumping to conclusions, but I couldn't see how any other acceptable alternative would be any cheaper. Jon thought that a bookmaker wouldn't need to store the details of every outstanding bet, and has confirmed this with the Gambling Commission, but even if this is true for this particular example, I think my general point is still valid.

Blame Powerpoint

@cybersal asks @RSessions a different sort of s/ware complexity question from his usual stuff: "How would you compare complexity of Powerpoint 2007 v 2003?"

The first point I want to make in discussing this question is that there are two different things, both called "Powerpoint". One is a lump of shrink-wrapped software, which I call technology-as-built. The other is the Powerpoint that people actually use, which I call technology-in-use. (Fans of Chris Argyris will recognize the parallels with espoused theory versus theory-in-use). If different groups or communities use Powerpoint differently, there may be many different Powerpoints-in-use corresponding to a single Powerpoint-as-built.
 

The distinction between technology-as-built and technology-in-use is extremely important for technology adoption and management. (My favourite example of this remains Lotus Notes, which for some time after its initial release was mostly used in pretty boring and unimaginative ways, merely as a jumped-up file management system. I guess it took at least two years before the technology-in-use started to catch up with and then exceed the intentions of the Lotus design team.) My notion of technology maturity is based on a stable relationship between technology-as-built and technology-in-use.

However, this distinction is largely ignored by IT analysts, who try to rank the "vision" of the software producers but entirely overlook the "vision" of software consumers. This is related to my point about Venturesome Consumption.


By the way, the distinction is implicit in my post yesterday, Blame Excel, where I distinguished between blaming things on Excel itself (technology-as-built) and blaming things on people using Excel stupidly (technology-in-use). Is Microsoft responsible for how Excel or Powerpoint are used? Clearly software providers cannot be blamed for the stupidity of their customers, but Microsoft clearly has a strong interest in promoting good use of its products, and providing some protection against bad use.

Now here's how this distinction applies to the question of software complication and complexity. Let's acknowledge that each successive version of Powerpoint-as-built has loads more features, new menu options, design styles and so on. But let's also acknowledge that many Powerpoint users are still using

• the same limited subset of features
• the same font (Ariel)
• the same style (bullet points, like this)
• the same clip art (those horrible cartoon men). 

When people talk about Death-By-Powerpoint, they are generally talking about Powerpoint-in-Use. It is clearly possible to produce lively and informative Powerpoint presentations, but many people (including Bill Gates) don't seem to find this very easy.


So there is a growing gulf between the technology-as-built and the technology-in-use. This is where the unnecessary complexity gets in: I call it The Baroque Style. The more complicated the technology-as-built,  the greater the risk of poor results from the technology-in-use.