Monitoring the "cloud" ...

At E-Tech (March 2007), I talked about :-

• The commoditisation of IT.
• The need for competitive utility computing markets.
• The "potential" green benefits of large scale computing providers.
• Why open source was essential for SaaS.
• The need for open hardware.
• The change of consumer from a passive to active participant.
• Why patent length needs to be variable and set to the likely time of independent discovery.

All of these themes were connected to the underlying process of commoditisation.

I continuously keep tabs on how different business activities are affected by this process as this enables me to help my clients determine a better strategic choice for their activities. There are numerous stages in an activity's lifecycle, each with its own methodologies and strategies.

Now whatever the "cloud" is, it is certainly about the commoditisation of IT. It's therefore about the creation of a competitive utility computing market for which there are a number of requirements.

One of these is a high degree of substitutability between services (what I jokingly called Fungitility and Patration and James called Software Fluidity). Substitutability between services in the Software as a Service or Cloud Computing or whatever term is in vogue, means:-

The freedom to move from one service provider (including internally) to another without hindrance (including excessive cost, time or effort), without boundaries and predicated on the existence of an equivalent service or services.

This term really is about the portability of data, applications and frameworks (see my talk from OSCON) between providers but that terms is used by the DataPortability group to mean something equivalent to "access to data". It's all a bit messy but it's the concepts that matter not the actual terms. They will all get cleaned up at some later point along with aaS wars when there is less buzz.

All you need to know is that IT is moving from a product to a service based economy (hence all the different aaS terms), and in a service based economy the freedom to move from one service provider to another without hindrance is critical. This of course means there must be more than one service provider.

Oscon, July 2007

Substitutability between service providers will require the portability of any necessary data, applications and frameworks from one to another services that are interoperable. For this, and for reasons of strategic control, the services will need to be based upon open sourced standards. This is starting to slowly happen for example with the open SDK of GAE and Eucalyptus. Another requirement is compliance and assurance services. It seems like we have a first step being made along this path with CloudStatus.

Back in July '07, I said: "Six years from now, you'll be seeing job adverts for computer resource brokers."

The speed at which things are moving, it could be even sooner.

Columbus, I'd like a detailed plan before you go ...

When it come to managing an activity, there are three wise sayings that I always keep in mind. The first and second are:-

• proper planning prevents poor performance.
• an imperfect plan executed today is a better than a perfect plan executed tomorrow.

The former simply tells you to make enough of a plan. Obviously for a commodity-like activity, which is well defined and ubiquitous, such a plan can (and should) be quite detailed. For a genuine innovation that plan becomes more of a fuzzy haze of intentions; it's an undefined activity which will change.

The latter wise saying simply advises against missing an opportunity because you've spent all your time planning. Opportunity, as in a genuine competitive advantage, is often fleeting.

Now what is true of planning, is also true of mapping. When mapping a business, it is worth remembering that some are commodity-like activities that can (and should) be mapped in detail, whilst other processes are innovations which tend to be more of a shifting smudge.

For me, the purpose of mapping out activities, beyond process re-engineering and the normal operations, is to enable the organisation to build a framework of services on which future innovations can be built. However, embarking on a Service Oriented Architecture (SOA) without some form of map is like saying "we're going to build common services but we don't know what we do" (see wise saying No. 1).

However you can't wait until you finished a perfect map before you start, because within any commercial ecosystem activities constantly change (see wise saying No. 2) and to be honest, you've got those smudges. So you'll have to do some exploration.

The reason why most organisations adopt a service oriented approach to design is because componentisation of business activities as services is a powerful enabler of innovation (part of the theory of hierarchy). Columbus needed the resources, organisation, infrastructure and might of Venice before he could embark on his exploration of the unknown. Though certain activities (such a ship building) can be planned in detail, the discovery of a new territory cannot. If Columbus had been required to create a detailed map before he left, then he'd never have left.

In business, the discovery of a new territory, such as a new product or service to sell, is essential for the survival of company. This brings me onto the third wise saying:-

• innovation requires organisation to survive and vice versa.

Move over Bellatrix ....

In the software business, there are several unforgivable curses which deserve a one way ticket to Azkaban. These include "What backup?", "What version control?" and "What testing environment?". Fortunately, the days when you might have heard such words are long gone as we all have learnt the folly of the dim distant past.

However, we are always living with our future curses, e.g. the naive and foolhardy things we do today which we will laugh at tomorrow. So, I've decided to pick out a couple of candidates for future curses.

What model?
The purpose of business process modelling (BPM) is not just to provide a view of what we do as an organisation but also to enable an architecture to be built to support our current and future activities. Obviously we cannot model innovations with any certainty, they are constantly changing. However commonly repeated activities can be modelled and subsequently used to create a supporting infrastructure. I was under the misguided impression that companies embarked on a Service Orientated Architecture (SOA) after first having examined what they do by Business Process Modelling (BPM). Apparently this is not the case, some companies start building without actually knowing what it is they do. There is always a balance to be struck between the two morals of "an imperfect plan executed today is better than a perfect plan executed tomorrow" and "proper planning prevents poor performance". I'm not sure that this novel approach achieves this.

What lifecycle?
Whilst BPM will give you an overview of what you actually do and help in the design of an architecture, it doesn't actually tell you how you should manage an activity or process. As I've mentioned before, I tend to "colour-in" my models to identify activities at different stages of their life-cycle. This provides me with information on how to deal with an activity, for example :-

• whether an activity is ripe for outsourcing or SaaS (assuming a suitable external ecosystem of providers exists).
• how I should manage a particular activity (for example more agile or more defined processes e.g. SCRUM or Prince 2).
• how I should measure it.

I'm fully aware that this runs contrary to our desire for simple measures; however even a simple measure such as ROI (return on investment) is only valid for particularly stages of the life cycle. For innovations, you need to work on a worth based mechanism whilst cost is your only ally with CODB (cost of doing business) activities.

Arthur C. Clarke said that "any sufficiently advanced technology is indistinguishable from magic". We shouldn't forget that we are all just underage magicians and tomorrow will look back at much that we thought was "magic" and just cringe.

Additions

I couldn't resist but add a few more unforgivable curses.

We only release once per month
Commodity like activities should be released or updated as little as possible, once per year is probably once too often. Innovations need a completely different timescale, once a week is possibly too slow. The one size fits all idea is instead one size doesn't fit anyone.

A lunchtime interlude

Before I get stated on a discussion of the stack, I'd like to talk about the pleasant lunch I had today with a friend who is a research analyst. I discovered that something which I thought everyone had known for the last decade may not actually be that widespread.

Most organisations tend to spend more on CODB-like activities than necessary, because it is easier to justify, and less on CA-like activities because worth is such a difficult concept.

Since CODB-like activities are in the majority, then the correlation between investment and worth is generally broken.

I have been operating under the illusion that this was common knowledge. The revelation that maybe it isn't may help to explain some of my frustrations with our IT industry.

The ideas of worth which I discussed in earlier posts are not mine, nor are they new - they are an amalgamation of my "collective experiences" from others and in most cases are at least a decade old.

The main problem appears to be that most organisations do not segregate activities (into for example CA, transitional and CODB) and tend to instead use singular approaches to manage activities (such as cost focused). As discussed in earlier posts, this leads to the perverse situation that we tend to spend more than required on the necessities which don't bring value and less than required on things which might.

Customer: "I have $300 to buy some essentials like food and some books on finance. I'm hoping to improve my understanding of the field and therefore my prospects"

Sales Rep: "Certainly, now food is a necessity, something you really need."

Customer: "Of course"

Sales Rep: "Well, I have lots of studies here to show how much food is important to you. Everyone uses it you know?"

Customer: "Really, wow that's interesting. I can see food is really important."

Sales Rep: "Hmmm ... I don't seem to have any reports on why improving your understanding of finance will help you?"

Customer: "Well, it's just this idea I have. It's just a hunch, a gamble."

Sales Rep: "Sounds expensive especially if you don't know what the return will be?"

Customer: "Well, it was just this idea."

Sales Rep: "Are you sure you just want any old food? You look like a dyanmic, go-getting sort of person surely you want to compete with the best?"

Customer: "Naturally"

Sales Rep: "Well this report says that if you increase your intake of blue coloured food, your performance ... as measured by athletes ... will increase. All the top notch people are using it - here's a client list"

Customer:"Wow, oh look I'm definitely more go-getting than Fred"

Sales Rep: "It's more expensive to buy blue food - quality always is - but it will give you the edge over others. I've got some ROI calculations for you and case studies if you like?"

Customer: "That's impressive it certainly explains the value. I can also see all these other people I know buying blue food. It certainly justifies the expense. Listen forget the books, just give me $300 of the blue food."

Sales Rep: "Not a problem. Would you like me to book you a session with one of our consultants to tailor the shade of blue required to create synergy with your own lifestyle and to maximise your advantage?"

Customer: "Sure."

Now, I'm not knocking the necessity to eat a well balanced and satisfying diet, but assuming you are fortunate enough to do so then food is just a CODB of living. If you want to improve life beyond this, you'll to need to look further up Maslow's hierarchy of needs.

It's a glib and somewhat turgid analogy, but It's no different with an organisation.

So when I first came across Paul Strassman's work in the 1990's that IT spending was not correlated to company value - it wasn't a shock, just empirical evidence showing this effect. I was delighted that someone had taken the time and effort to gather the evidence which showed what was plainly occurring in my day-to-day experience.

When much later Nick Carr published his article, I felt elation that finally we had a spokesperson willing to take on the insanity and the industry around it.

With the growth of open source, I expected as a side effect there would be a greater shift towards commoditisation of CODB-like activities and an acceleration in innovation and hence disruption of existing industries. So I was delighted when Andrew Mcafee published his report showing increased turbulence in the IT industry.

I expect that turbulence to increase as the "X as a Service" industry grows.

I was just part of the huge crowd who appreciated these breakthroughs to "sense and reason", who understood that the singular magic bullet approaches, the over-hyping of ROI and the sweeping broom of cost focus combined with an organisational inability to identify worth was at the heart of the problems.

After the discussion today - I'm starting to feel that crowd is either smaller or more quiet than I realised. Maybe I'm missing some critical point or a lot more discussion is needed?

Well, if I am operating under a delusion - it is probably best to continue ...

Future stuff .... Worth Part VII

The creation of standards and providers of those standards at all levels of the stack, will allow for the formation of competitive utility computing markets.

This will have multiple effects, not least of which is the balancing supply and demand more effectively than today's situation and the creation of a downward pressure on price.

They will also allow for the formation of brokerages - swapping your service between providers to obtain the best cost - and exchanges whilst simultaneously undermining subscription type models for service provision.

They will also enable developers to focus more on building the new rather than repetition, as well as reducing some job categories in IT but also creating others.

Most importantly these markets will provide a direct relationship between what we use and what we pay.

This should challenge the ideas that every company needs to store everyone's data, further encourage the growth of SaaS, the creation of open business procedures, configurable virtual niche businesses and so forth.

It may also force more businesses to look closely at the worth of something in order to determine their choices and priorities, as by their very nature utility environment are more worth based.

The more you consume, the more it costs you.

Client: "We'd like to build this internet thingy - how much will it cost?"

Supplier: "Can you give me details on what you want and how many people will use it?"

Client: "Sorry? we want to know how much it will cost?"

Supplier: "The service is charged on a utility basis - so it depends upon how much you use it"

Client: "We don't know that, it all depends upon what happens, what people will want and how popular it is. We need to get the cost sorted in order to get the budget and determine the ROI"

Supplier: "Well the cost will vary with success of your internet thingy - do you have an idea of the worth of this activity?"

Client: "no"

Supplier: "there's your problem."

Commoditisation and web 2.0 .... Worth Part VI

The process of commoditisation is simply the movement between the novel, rare and new to the common, ubiquitous and necessary. As such the nature of a system changes in the process from for example potential high worth, scarce, risky, non standard and non-essential (source of CA) to low cost, ubiquitous, low risk, standardised and necessity (CODB).

Much of IT is CODB. That is why we are starting to see the first utility like environments for IT appear (whether at the HaaS, FaaS or SaaS level). However such environments whilst they often contain necessary services for any business at a lower cost than the build your own variety, generally they are neither low risk nor standardised.

Low risk in this context would mean multiple providers of the same service which you can swap between, as opposed to the implementation details of any one provider. To be able to swap between services you need not only standardised services but multiple providers and the freedom to move data, application or framework (depending upon which level of the stack you are talking about) between the providers.

In this context open source is a necessity to provide not only the base standards but also an operational means of implementing that standard. It is neither a tactic or a strategy.

However, open source (and in this context I mean ideally GPLv3 over other licenses) is not sufficient, you also need some form of additional information to ensure the users of such services that they aren't being locked-in, or that this provider is really compatible with another or they can run their own installation should they wish to.

This can only be achieved through monitoring and the use of trademarking, by an authoritative group providing assurance to end users that this provider meets the standard, that any primitives have not been modified and that what you run with one provider will work on another.

The idea of utility computing, running on others infrastructure etc are bundled with other concepts into the term web 2.0. However, the importance of the term is not the details but that it describes that there are some fundamental shifts from an old world to a new world.

There are changes occurring between users and companies, ownership of information, producers vs consumers, conversation vs product, virtual vs real business, the spread of the idea of openness into business, hardware and other areas, the commoditisation of sections of IT and in particularly the web 1.0 components of it.

It's all about the new stuff, creative destruction and new sources of CA and worth.

Is it a buzz word? Yes, but it's a timely intervention to enable us to start letting go of the things which matter but we shouldn't be concerned about.

It's all about progress, which is the only true sustainable source of worth.

--- Update April 2013

General notes

Depressingly, almost six years later, we are still talking about the issues of interoperability, trademarks and competition in the compute utility space.

The terms have changed, HaaS has become IaaS, FaaS has become PaaS and compute utility has become "cloud" but the concept remain the same. Progress has been slow in the open source world.

My personal blueprint .... Worth Part V

The general blueprint I use when dealing with such issues is as follows. First, I divide IT projects into three categories - CA, Transition and CODB. Then for each category I take a different approach :-

With CA like projects (i.e those which are novel and new in the industry, few examples in the wild, minimal whitepapers, some percieved value and relevant) then use more of a VC like approach (IT Finance) or Worth based development. Focus on worth and dynamic like processes for development (e.g. SCRUM, XP etc).

With CODB like projects (i.e. those which are common in the industry, necessary, lots of examples, lots of whitepapers, even conferences on the matter) then focus on cost reduction, standardisation and static like processes (e.g. Prince2 etc).

With Transition like projects (i.e. those betwen CA and CODB) then either:-

* If new to the field then calculate potential worth, risk and costs and then it's a judgement call - wait and adopt or disrupt.

* If already in the field then attempt to move your service to become the standard product for the industry and hence reduce cost of migration.

Now this is my method, there are many others ... this is not about which method is better. I used my own blueprint to illustrate what I believe is an important point:-

the type of approach which should be adopted depends upon the nature or the class of the problem you are trying to solve

It's not about one approach, a magic cure to solve all problems.

Transition .... Worth Part IV

The most difficult area of IT to deal with, is those systems which are neither novel and new (i.e. some examples of the service are already in existence) nor common and ubiquitous.

Now what is key here, is to know how you to got to this position.

If you created a CA like system which is now being copied by other competitors (presumably because of your success) you run the risk of the cost of migration.

This is where someone releases a product that becomes the standard in your industry and you are constantly maintaining and upgrading your service to keep up with the standard. You will almost certainly in the long run have to switch to the standard - so your costs will be the switch and the cost of continuing your own in-house product until you made the switch. This cost can be very significant.

The best tactical approach to secure the most value in such a situation, is to release your service as a product when other competitors start copying your service. Give it to someone to sell, give it away, open source it etc. If your service becomes the standard, then there is no cost of migration. Open source is potentially a powerful tactic in this context.

Now, if you are instead a laggard into this new field and you see that some of your competitors have such a service whilst no standard product exists then you have two choices. The disruption game or the wait and adopt approach.

Both you'll have to balance carefully in terms of worth, cost, risk and migration effects.

In the disruption game - you try to be the first to release a product and to get that product adopted as the standard. Steal your competitors teams, pay them to develop and release a modified version etc. It's a risky play and it all depends upon the service - whether it could become some form of strategically important platform, like a universal airline booking system? How much influence do you want to purchase over its future direction? etc

The wait and adopt, is just that. Don't do anything and wait until a standard product is released, then adopt it.

In this class of problem, the ROI syndrome is very much secondary to the pure tactical play.

Cost of Doing Business .... Worth Part III

If a service is common, ubiquitous and necessary - then it is termed a cost of doing business. The market or potential is well known, there are plenty of other examples, whitepapers, case studies etc. As such it is much easier to identify the potential benefit of the service and hence its worth - it should also be much clearer over what is needed being a much more well defined problem space.

In such circumstances, the worth of the service is meaningless as all your competitors are using equivalent systems and you need such a system just to keep a level playing field. Any actual worth generated (additional sales or cost reduction) will be passed onto your customers or will simply help maintain your existing market share. Any growth, if there is any, will be over the laggards to this field and probably at best temporary.

In such cases, your focus should be cost alone - as standard as the industry has (either product, or utility based service) and as cheap as possible.

Unfortunately, the existence of so many whitepapers, case studies etc and the ease at which a potential worth can be calculated, makes it easier to often justify larger expense especially when the product is configurable to meet the individual requirements of the business.

About five years ago, I saw the sales sheet for one particular product as sold to around sixty different organisations in London. The product sold was identical, but the price (normalising to a standard number of licenses) varied from $100K to over $2M for the same thing!

It's a testament to the sales people involved, but it's the equivalent of :-

Customer: "I'd like to buy that TV"

Sales Rep: "Excellent, what's your name?"

Customer: "Simon"

Sales Rep: "That'll be $300"

Customer: "Actually my name is Peter"

Sales Rep: "That was naughty of you ... well then it's $100"

Customer: "What if I'm called Harry?"

Sales Rep: "$3,000 - would you like us to modify the knobs so they turn faster or slower according to your need?"

Sales Rep: "We have a whitepaper here on how this will improve your channel switching over Simon & Peter"

Customer: "Is it extra?"

Sales Rep: "I'll arrange for a visit from one of our consultants to determine your exact requirements"

Let's not also forget the dreaded upgrade cycle and also the abyss which is the non standard upgrade path, whereby those modifications you asked for (for reasons of improved channel switching or conforming to your current way of doing business etc) forever cost you more everytime you upgrade.

Unfortunately, all those whitepapers provide support to the potentially higher benefits of a common and ubiquitous service. This often make people feel more comfortable justifying higher expenditure from the ROI calculation ... which is exactly the wrong sort of behaviour desired.

The rule of thumb here should be cheap as chips, ideally cheaper than everyone else and no modification. You need the service in order to compete but your focus should be on price and standardisation - any thought of strategic value should be banished from your mind.

Competitive Advantage .... Worth Part II

If a service is novel and new (a potential differential, a source of competitive advantage) - then the market or potential is unknown (there are no other examples, whitepapers, case studies etc) and hence the likelihood for any sales or benefits is also relatively unknown.

There is a lot of uncertainty - it's novel and new.

Since you can describe the service roughly but you can't quantify the benefit easily, the tendency is to get several quotes for the system and then choose the lowest price with the supplier you feel most comfortable with.

What then tends to happen is the cost is used with the ROI required, to calculate what benefits the system must bring - often referred to as targets. As long as these seem comfortable and someone can magic up some data to support it then it's ok.

There are some massive problems with this approach:-

• The supplier is focused on delivering to a specification rather than delivering a product or service which generates the highest possible benefit.

• The client is focused on getting the product or service they specified at the lowest cost, without really knowing what the final end result needs to be. If it's a novel and new service then the process of development is also a process of discovery for the client in this new market.

• The calculated ROI based "worth" has little or no correlation to actual worth, it's a function of cost alone.

Tell tale signs of this are the vagueness of the specification, the inability of the client to specify likely usage of the service and a wandering focus in terms of functionality. However the problem here is not the client but that a static process is often being used to deal with a dynamic problem. The client invariably cannot specify the system upfront as they have little or no reference point to compare against - they can't say "give me something like they've got" or "one of those", they don't really know what it is.

The result is almost always the same :-

• Changing specification causing arguments between client and supplier over specification and rising cost.

• The system is either a major success - in which case the additional costs are soon forgotten about - or the system is mediocre or a failure, in which case a blame game often ensues.

Any blame game which does evolve generally centres around :-

• The client believes the supplier failed to deliver or be flexible

• The supplier believes the original idea was daft anyway (something they would never have built themselves) or the client kept changing the specification.

If none of the above is familiar to you, then I'll assume you either don't work in IT or business or you have never built anything new or you've been very lucky.

Modern approaches use much more dynamic techniques (agile development like XP and SCRUM) to deal with the uncertain elements of the functionality. Both techniques appreciate that this is a discovery like process for the client as well. However, both still focus on the delivery of a product rather than delivery of worth - which after all is what is supposed to be happening.

The reason for this is often because of the whole pricing structure and contract which is often in place between a supplier and client.

Now there is an alternative - worth based development (WBD) - which is something I've used heavily since 2002. It can work but it also has pitfalls.  Under WBD you agree an arrangement where both the supplier and the client make money from the value the system generates - the cost of building and managing the system being borne by the supplier.

The conversation should constantly revolve around worth and ideally be :-

Client: "We'd like to build this system to sell widgets for $100, we reckon this will sell lots"
Supplier: "It's risky, the data looks good and ok we will build this and charge you $5 for each widget sold."

Client: "agreed"

Unfortunately it rarely works like this. First because the client needs to identify and agree a measure of worth  (which businesses generally are pretty poor at) and provide figures to justify this measure and second because the supplier needs to be satisfied of the risks and upside involved and of the commitment of the client to make this work.

From my experience the conversation often tends to be one of the following :-

The ROI gambit

Client: "We'd like to do this thing"

Supplier: "How will it make money or create value?"
Client: "Can you tell me how much it will cost to build it?"
Supplier: "Do you know how it will make money or create value?"
Client: "Can you tell me how much it will cost to build it?"
Supplier: "Do you need the cost for an ROI calculation?"
Client: "Yes, how did you know?"
Supplier: "Would you like a fixed price contract?"
Client: "Yes please"

You really shouldn't do this gambit

Client: "We'd like to build this system to sell widgets for $1000, we reckon this will sell lots"

Supplier: "It's a daft idea and not worth us taking the risk. Would you like a fixed price contract?" 

Client: "Yes please"

We're not sure we want to gambit

Client: "We'd like to build this system to sell widgets for $100, we reckon this will sell lots"

Supplier: "Ok, it looks good and I agree but I'm not comfortable that your committed to promoting this?"

Client: "Well we haven't decided whether to promote it yet"

Supplier: "Well if you don't, I won't get paid as it won't sell .. would you like a fixed price contract?"

Client: "Yes please"

The clueless gambit

Client: "We'd like to build this system to sell widgets, we reckon this will sell lots"

Supplier: "Ok, it seem like a sensible idea but what are these widgets worth?"

Client: "We haven't decided that yet"

Supplier: "Well, what is the market like?"

Client: "We don't know that yet"

Supplier: "Would you like a fixed price contract?"

Client: "Yes please"

Within large organisations, you also tend to hit the budget constraint barrier. For example ...

The budget gambit

Client: "We'd like to build this system to sell widgets for $100, we reckon this will sell lots"
Supplier : "It's risky, the data looks good, the upside is good and ok we will build this and charge you $5 for each widget sold."

Client: : "Fantastic"

... add time

Client: "hmmm, we've sold 100,000 widgets"

Supplier: "Yep, we will charge you $500,000"

Client: "hmmm, but I've only got a budget for $500,000"

Supplier: "and you just sold $10,000,000 worth of widgets"

Client: "Yeah, but I've only got a budget for $500,000. Can you switch it off please?"

Supplier: "You want me to switch a revenue and profit making system off?"

Client: "Yep, I need to go through another budget approval. It takes six months."

... and you're back to square one. All of the above problems I've hit and yes, I've been asked to switch off profit generating systems for the client because of arbitrary budget limits. That awkward conversation that despite a system making tens of millions in revenue for the client can we switch it off because we've exceeded some budget limit. 

This is why many of the outstanding new services, which tend to get bought out by large organisations, tend to be built by smaller organisations, funded to create a risky but new venture with staff motivated around generating value or worth.

Large organisations tend to lack any internal VC function or Financial risk function for the development of the novel and new in IT. They lack the processes needed to make this happen and as such they tend to treat all IT as the same and normally as a cost function.

So anything which is a potential CA in a large organisation, tends to have a rough ride as the ROI syndrome comes into force and everything focuses on cost rather than worth.

--- Update 20th July 2013

Read this lovely post on value based pricing (which is the same thing as WBD) - http://sixrevisions.com/business/earn-more-on-projects/

Yes, it works sometimes but others ... oh boy.

--- Update 8th October 2015

Outcome based techniques is simply the next incarnation.

The ROI syndrome .... Worth Part I

I haven't posted for a bit, so I thought I'd post some personal and somewhat unpolished views on worth, utility, web 2.0 and why it's all connected and why we are entering a major transformation of the IT industry.

To start with I'm going to explore the concept of worth within corporate IT.

Most organisations seem to be shockingly bad at determining the potential worth of an IT service. This is something I've been harping on about for over a decade and it usually starts with the following conversation.

Client: "We'd like to build this internet thingy - how much will it cost?"

Supplier: "Can you give me details on what you want and how many people will use it?"

Client: "Sorry? we want to know how much it will cost?"

Supplier: "I'll tell you once I know the details and how much it will be used?"

Client: "We don't know that, it all depends upon what happens, what people will want and how popular it is. We need to get the cost sorted in order to get the budget"

Supplier: "Ah, the old ROI syndrome"

The old ROI syndrome

Most organisation have ROIs (Return on Investments) that internally they need to achieve, and IT projects need to show an ROI - whether it's value added or cost saving.

Now the ideal way to deal with this, is to calculate the worth that a new service will bring (sales, cost saving, risk etc) and then calculate the maximum you can spend based upon the ROI required and finally determine what your spending focus should be. The problem is that calculating worth of something can sometimes be very difficult, it depends upon popularity, usage, what your are trying to achieve and other factors and hence most ROI calculations tend to be based upon the cost of something.

Now there are three class of problem - CA (competitive advantage), Transitional and CODB (cost of doing business) - I'll deal with each one of those in turn over the next few days.

Blink ... did I miss something?

I'm following some discussions on organisational structure and development on the 21st Century Organisation Blog

Euan and Jenny have been very kind not to shoot my observations completely out of the water (thanks!) - there are some very smart cookies on this blog. Well worth a good read, it's certainly got me scurrying off to check up on stuff.

Excellent job, this is a field which my eyes are being rapidly opened on ... it's way more developed than I realised.

Last week, I thought I knew something on this field ... now I'm in the dark ages .... that information cycle has certainly speeded up again.

I'd have got away with it, if it wasn't for those damned pesky kids ....

Today has been fascintating.

It started off with Michael Schrage and a panel on Search Technology as the new frontier. Part of the panel was arguing that search was the principle core of any business - and Schrage, well you could just tell that he wasn't convinced and he certainly wasn't buying the argument that search was a purely technological issue which can be solved by a specific product.

This spilled over into Andrew Mcafee's impromptu session on enterprise 2.0.

The session was packed with views from the worlds of collaboration, search & enterprise 2.0 with Euan Semple to Mcafee to members of the Enterprise Irregulars

Questions were raised about why should companies adopt web 2.0 like technologies and the issue of long adoption cycles. There are a couple of key points to note here.

First, there is a trend towards canonical sources of information and the appearance of curators, or editors as Tony Fish (AMF Ventures) calls them. The democratic web chooses its own curators but in order to be in the running you need to be providing information openly, honestly and with integrity (the ideas of P2P reputation and searching across such networks).

Now this causes a problem, if you don't become the canonical source of information about your company - someone else will. Once that happens it's going to be damned hard to replace them. In some cases wikipedia is becoming that source, in other cases it's bloggers and other sites. What the industry is waiting for is a method of bringing P2P reputation networks into the public domain and allowing searches based upon your interaction with that network.

This can only be a matter of months away; you see elements of this in technorati and when it happens, if you're not engaged you'll be cut out of the loop.

Imagine a world where you search for company ABC and the top, most relevant, most respected result is Blogger Jim. As the trend towards conversation being more important than product continues (i.e. our experience of ABC is created from all those moments or interactions with ABC), then it's a poor start when the first conversation begins with Jim, who doesn't even work for ABC.

So there really isn't much choice to adopting a more open method of providing information unless you want Jim to be your public voice.

Tony also raised some good points (following on from his session of mobile web 2.0 and his views on convergence and search) about whose data is it anyway. There has been a growing trend towards customers owning their digital footprint, which in reality belongs to them anyway (it's worth looking into open ID, Sxip and the whole identity issue).

It's probably an uncomfortable concept, in much the same way as open source was and the idea of opening up everything about a company (warts and all) probably doesn't fit well with some views of marketing and branding. However the market will decide how it wishes to search, how it wishes to engage and who it trusts. You can try to impose your own taxonomy on the web but you'll soon discover that such things are emergent and not prescribed and the best way of dealing with this is openess.

The second point was the importance of the web 2.0 term. What is really essential in my view is not so much what is in web 2.0 but what has been left out. It's a milestone, a way of describing these excluded terms as old hat, CODB, necessity to compete and dull.

A decade ago, having a company web site was really exciting ... now it's a norm. The same is true of many "strategic" IT initiatives from CRM, ERP, E-Commerce etc.

There is no strategic or differential value in these initiatives, except in the area of execution if everyone else executes them poorly (see Andrew McAfee's blog about such concepts).

Overall interesting day - there are some excellent speakers and good corridor chat, congratulations to Fast Forward '07 on that.

The lessons for me are that much of what was once considered important is no longer, and openess and being the canonical source are imperatives.

No more hiding away those corporate secrets.

I'd have got away with it, if it wasn't for those damned pesky kids .... welcome to the new world.

Worth based development

Butler Group's master class was better than I hoped for. Tim Jennings and Martin Butler gave some interesting presentations on IT value, measurement of value and in general what is wrong with our industry - too much focus on cost, with no clear measureable value.

The content was similar to a discussion group I had a Foo camp last year.

Take home messages were

1. No correlation between IT spending and business value.
2. No correlation between IT spending and cost reduction.
3. Strong correlation between knowledge capital and business value.
4. IT in general is focusing on cost and automation, where it should be focusing on knowledge capital.
5. Big gap between Executive and IT in general.
6. In general there are no clear measurement of business value in IT projects.
7. Difference between Competitive advantage, Cost of doing business and Transition of projects.
8. Focus should be on worth first (or as I would say what's important to users).

and much more. Overall great.

Today the duck count was up to 8.