There was a parody about this subject called ColdPizza by Scot Lazar - an excellent article published in Jan 2006. However back in Nov 2005 I wrote the following comment on Slashdot Where's Parody Rights Management when you need it? The world is going mad :-)
Twenty years ago when environmental concerns were not so trendy - I was an activist. I was later on involved in environmental groups in Cambridge, undertook a masters in the subject and worked in the industry for several years right at the mucky end.
Many of my compatriots have now gone on to become the great and good in the environmental world. I stopped.
Because in my heart of hearts - I'm an economist - it's my mother's fault, long story. My principle objection, was one concept - carbon tax, and the use of market economics to solve this problem. Carbon tax (or specifically Carbon permits) works like this - this isn't the technical definition, but the practical one.
The environment is a common to everyone, and owned by all.
Many rich people have become rich because of industries and products which pollute the environment.
Poor people have bought these products or worked in these industries because of aspirations, often created by said industries to drive sales.
The environment is now a bit messed up.
Poor people should suffer.
Rich people won't.
The environment will be owned by the rich.
Fundamentally market economics works on exclusivity - which means a lot of people get excluded. Now I have no issue with this for luxury proprietary goods - like TVs, cars etc - but this is not the way to deal with infra-structural or common goods - like clean air, health, education etc. Sometimes these tricky "infrastructural" things get labelled externalities, as if somehow in the future the environment could be treated as an excluded good. Alas, the environment will always contain an economic externality because the economy is a subset of it and not the other way around.
The market economic system is highly efficient at exploitation and resource usage - which is great if that is what you intend to achieve. It should be remembered that a market is nothing more than an economic tool, as is a centrally planned system - it's a question about practicality and effectiveness not dogma or one being more 'right'. Neither tool is an excuses for poor governance or a vision-less society or ignoring the wider environment we exist within.
So how do you fairly deal with environmental exploitation with a system which discounts the environment and pretends to supersede it? On a purely equality basis you can give everyone equal right to the world they are born in, and equal share in this - this is known as a quota. Unfortunately that doesn't work well in a market system which needs excluded goods which can be transferred.
So what's not the answer? Well, I predicted fifteen years ago that in the next thirty years we would develop an inappropriate excluded market based system, where the rich will win and the poor will become more excluded i.e. some form of transferable permit on carbon usage.
So what is the sensible response to such a scheme? Refuse it.
Eventually people will share, but not if you say "ok, you've been living your fabulous life styles - champagne, flights abroad etc - I'll cut back on mine, eat dung every day and live in a hole in the ground and suffer some flooding because of damage you created in the past, so you can keep on living your fabulous lives."
You see the rich have more in the long run to loose than the poor, and what is at risk is everyone's quality of life. This isn't the end of civilization stuff but simply horrendous deprivations based upon tipping points which no-one fully understands.
Carbon permits were a bankrupt idea many years ago and they are a bankrupt idea now. Somethings are infra-structural & not externalities waiting to be included (and hence some people excluded). If you're going to try and solve the problem with an equitable solution then you need annual, non transferable carbon quotas per person. --- 29th Sept 2013
Andrew categories IT into three types - functional, network and enterprise and discusses how each of could be managed. It's a good article, very insightful.
Of particular interest is the last bit.
"For a resource to have an impact on a company’s competitive position, it must be valuable, rare, inimitable, and nonsubstitutable. Oil wells and diamond mines meet the test; pencils and paper don’t. What about IT? At first glance, it would seem that all three IT categories fail to meet these criteria. Vendors offer a wide range of FIT, NIT, and EIT, so these technologies are not rare and seem to be highly imitable. However, people often forget that while the software itself might not be any of those things, a successfully implemented system isn’t easy to replicate"
The majority of I.T. systems do appear to be CODB and no matter how you categorize them, they would appear to fail to meet the criteria of valuable, rare, inimitable, and non-substitutable. However, this doesn't mean there aren't examples of novel and new processes which are differentiators with real return (CA).
Whether you agree with his ideas or categories, in my view Andrew does make one exceedingly good point.
The process of execution is separate from the purpose of the activity i.e I can just as easily wreck a viable CA through poor management as I can wreck a CODB.
Poor implementation of a CA doesn't mean it wasn't a potential CA and a single fantastic implementation of something which is CODB doesn't turn it into a CA.
Upgrading the power to a factory in such a way that you leave it without electricity for two months is costly, whilst getting the upgrade done in a day means we can start producing again. This upgrade is all about the cost of a CODB like activity and the cost of implementation is part of this.
Of course if being good at implementation of CODB projects is novel and rare in your industry - then that is a potential source of CA.
If everyone else's power upgrades knocks out their factories for two months, and I have the only team in the world that can seem to do it without such problems - I have a source of genuine if maybe temporary CA - that team.
It only remains an advantage whilst everyone else is constantly making a mess of the implementation, so when I have "power installation consultants" knocking on the door with examples of simple easy installation in a day as "Best Practice" and horrors of not doing "Best Practice" - then any source of advantage has long since gone.
Getting it right, when others do with a CODB like activity, is not a source of advantage or a benefit - it should be expected. In such a world, "cheap as chips" becomes the order of the day with CODB, and this is why commodity like operating environments and services are now becoming more relevant.
Times up on this merry go round. Salesforce, Amazon's EC2 and others have pointed the way. Of course this says nothing about how you deal with genuine CA-like I.T. projects (the rare examples) for which a VC like approach is more appropriate.
"The Legislative and Regulatory Reform Bill marks a crucial step toward a Britain free from unnecessary red tape." - yep, such as parliamentary scrutiny.
It is part of the "Government's radical new agenda for regulatory reform"- this seems to mean removing parliamentary control of legislation and putting in the hands of ministers.
"The new Bill aims to make it simpler and faster for us to cut the burden of regulation" - hmmm, I thought the burden was a result of how much new legislation has been created. Maybe they mean is makes it faster to create new legislation and cuts all those bothersome type things like parliamentary process and voting.
"The Bill is essential to deliver our wider radical regulatory reform programme ... ambitious plans to simplify or reduce unnecessary bureaucracy across Government" - hmmmm, is parliament seen as unecessary bureaucracy? If you have one person making all the decisions, it's more efficient than a committee - though probably less effective for a democracy.
"enabling regulatory reform to be delivered swiftly and efficiently" - Hold on, I like my law making processes to be slow and thoughtful.
"This power to reform the law by order is intended to be used to implement" - Wait a minute - what do you mean intended? How about will only ever, ever be used in these specific cases, full stop. Intended implies it can grow.
Now more upto date ...
Well it has been watered down by the House of Lords and through committee, and it is supposed to have its report stage to the House of Lords tomorrow.
It's not over though, nor will this be the last time.
In world of warcraft language
The horde has 1800 points and is close to victory. [Skeletor]: well done guys, gj [Deathmask]: let's camp their GY [Monsterbash]: yeah [Doomslayer]: yeah The alliance has captured the farm The alliance has captured the mine The alliance has captured the stable The alliance has captured the blacksmith [Skeletor]: What? Hey defend you guys [Doomslayer]: Why don't you defend! The alliance has captured the lumber mill The alliance has 1800 points and is close to victory The alliance wins [Deathmask]: pawned, you @£!%%
What's the difference between an IT consultant who charges you $10,000 per day and one that charges you about $1,000 per day?
Usually about $9,000 ...
This is old stuff which I presented back at Euro Foo 2004, but it seems at the moment a lot of my friends are talking about it again.
The problem is ... what is something worth?
In the world of IT there are some attempts made to equate CODB type services (in some cases labelled as "strategic" in much the same way that having power for your building is also a "strategic" choice) to a notion of worth. These rarely consider any market effect (see the Warren Buffet loom example and why investing in something which improves productivity may not be a good idea) and returns do not always live up to expectation (assuming they are ever measured).
In reality many of these projects don't add any value - however they are needed to compete as a CODB (the IT arms race argument) - so what are they worth? Well, the least you can get away with - "Cheap as Chips".
This doesn't mean that all such projects don't create value - some are novel, new and with real return. These differentiators, CA like projects are worth something - but as the worth is related to the value they generate, and as this is uncertain (being something novel and new) it doesn't fit in well with cost focused fixed budgetting.
These projects are more suited to a VC type method of funding, but that involves different mechansisms of finance, calculation of risk and willingness to gamble.
However in the IT arms race, where there is often little or no link between value creation and IT spending (Strassmann etc) because of the mix of the majority CODB (often labelled "strategic"), minority CA (the ones which create value but have the biggest hurdles) and the big puddle of in-between projects being treated in the same way - most people seem to act in cost focused manner.
No suprise really.
Creating a link between worth and cost is not any easy task - you need to understand value, risk and be willing if necessary to take a stake. But creating a link between percieved value and cost is subjective and easy - it's often the other side of the same coin.
Which means you can just as easily underprice yourself as overprice, as the perceived value of your advice is often linked to what you charge for it - regardless of the actual value (and hence it's worth).
I was asked recently why we are intending to open source Zimki?
Well, there are some concerns with commoditised web operating environments around lock-in fears & availability concerns. By this action and some other releases in our roadmap, we plan to create the infrastructure for a "national" grid for Zimki environments.
This means that not only can people and companies swap suppliers easily but also suppliers can sell capacity into the grid - which is an important part of the process.
Yes it means we are going to give an easy route to competitors into this environment, but that's the point - to create a wider market.
I'd always go for the small bit of very big pie rather than the whole of a very tiny pie and commoditised web operating environments won't really take off until a company can change supplier as simply as changing electricity provider.
That's why open source and the "grid" is part of our roadmap.
Anyway, we are on that road now - things are starting to happen.
An ugly word for a wonderful process and something I've been passionate about for about the last decade (yes, someone pointed this out to me, time -> whoosh).
Though it has a formal definition in plain old English it is a shift from novel, new, exciting and rare to common, used, dull, generally unloved and taken for granted.
The point of Zimki is to take care of the now mundane (setting up servers, configuring databases, backups, scaleability, yada yada yada ... stuff we call "yak shaving") and allow developers to focus on the interesting stuff of building something new by providing "pre-shaved yaks".
Back at Euro Foo '04 I ran a session on the concepts of CA (Competitive advantage & worth based development) vs CODB (cost of doing business & commoditisation -> "cheap as chips") in I.T.
Whilst most I.T is CODB we don't yet seem to treat it in this way - lots of those yaks are still shaved in-house, and we are all doing it. A lot of these views are shared by many other people, and it's good to see that so many people talking about it.
I know I'm very grateful to Strassmann and Carr who for me anyhow have clearly put this whole subject on the map.
However, there have been a lot of people who have helped refine my ideas over the last decade and helped in my current pursuit.
This is the first real product for Fotango outside of general software development. It's an amazing feeling to be part of this change for the company and light years away from where we started six years ago.
The principle we follow is about encouraging innovation and creation. We've always said Zimki is about making it easier for developers to develop and removing the mundance or other obstacles which get in the way - i.e. all the "yak shaving" which needs to be done before you start creating something.
We now have a growing community of people working with Zimki, along with a host of new things to release for the system.