A node between the physical and digital.
The rants and raves of Simon Wardley.
Industry and technology mapper, business strategist, destroyer of undeserved value. "I like ducks, they're fowl but not through choice"

Thursday, June 28, 2007

One of the things I talked about was the need for open source hardware and how as the technology develops, value will be in the designs and raw materials (even the printers will be ultimately printed).

So it's good to watch how new sites and services are growing in this area.

Following on from Artur's post on Amazon's SLA - I've picked up Scott Hanselman's questioning of the Skynet compute cloud.

Balancing supply and demand for computer resources over a few large scale common resource providers enables efficiency gains (in terms of money, people and energy) which are not achievable with today's fragmented infrastructure. However there are barriers to its adoption, whether it's legal issues or concerns over lock-in to a specific vendor and the resultant exit cost.

I've long believed the key to this is establishing a competitive utility computing market, but this requires portability of applications from one cloud to another and hence an open and free standard (implemented through an open source reference model).

As I've commented before the issue is not the lack of an SLA with Amazon EC2 but that there is no Google EC2 or Microsoft EC2 or etc.

Creating such portability is one of the key ideas behind Zimki, though obviously slightly higher up the stack than raw machine images. This is one of the reasons why the open sourcing of the Zimki engine is so key to us and hence my disappointment in our delay.

On an aside, it is good to note that other frameworks are being developed in JavaScript. I was pleased to hear about Steve Yegge's port of Rails to JavaScript.

You can read more about this on Steve's blog. It's a shame they don't seem to be open sourcing it yet.

One thing worth noting is Steve's reference to "NBE", I just hope that the "E" stands for engine.

Google has the infrastructure and brand to make such a move into the NBT(Next Big Thing) and we would all benefit from an open sourced standard engine providing portability between clouds.

The original but very sucky name of Zimki, was libapi - as in liberty, liberal and liberation API.

It's always been about freedom from "Yak shaving" but that freedom also requires choice.

Tuesday, June 26, 2007

Having worked in the software industry for too long to quite remember, this made me laugh intensely.

I couldn't resist but add a few more tongue in cheek examples myself. I've republished here:-

WBD or Worth Based Development:

Unfortunately this one I invented a long long time ago and in general it doesn’t work in today's climate! The concept is quite simple, rather than being paid on a fixed price or on a per hour basis, the client (business) and the development team agree a measure of worth for what is being proposed.

Generally if the development team don’t think the idea is going to bring value they won’t agree to any measure (this is useful information telling you to stop!). If a measure can be agreed, such as “for each extra $ of revenue” or “for each product sold” etc then the business and the developers agree a percentage split of this worth. The developers don’t charge a fee for the system but take their cut out of the worth generated, the business doesn’t pay for the system but pay the developers a percentage of the value it creates. Hence both parties, the business and developers, are interested in the success of the project and both make value out of its success.

It’s simple, it involves the business and the development house in the process and it focuses on the value generated. However it doesn't generally work. Why?

Because inevitably large businesses are budget focused, and so you always get into a situation where the business says ...

“hang on, for each widget this system sells you get 5% of the value, let’s say $10. That’s ok if you only sell one hundred but what if you sell one hundred thousand? That’s $1 million! I’ve only got budget for $50K”

...of course, you try and point out that if you are selling that amount, they have increased revenues by $20 million but it always comes back to budget. At which point it’s just easier to agree to bill the business $50K for building a system which won’t generate any worth … which seems to be a fairly normal practice in much of IT … and then suffer the complaints that IT doesn’t create value … which seems to be a fairly normal practice in much of business.

BAUD : Business As Usual Development.

An advanced adaptation of WBD (worth based development). Knowingly building a system for a business which won’t generate any value, because to be quite honest the $50K they are offering is useful and you can’t be bothered to argue.

BORED : Blindingly Obvious Regurgitated “Enterprise” Development.

Discovering that whatever you built with the BAUD method (as above) can be repackaged and sold on in small $20K bundles to lots of other companies as providing “strategic value” in an “enterprise” environment. This can safely be achieved as most businesses have little way of ever identifying or measuring value of IT and if you are asked just tell them their competitors are evaluating it and mention the words “Competitive Advantage”.

Well no-one wants to get left behind.

This is also known as Keeping Up with the Jones’ (KUJ development) and other such terms and is in widespread use.

WMD : Wrong Methodology Development.

This is the approach of using static-like processes of project management to solve dynamic classes of problems and vice versa. Generally leads to corporate carnage through massive cost over-runs and cancellations.

Unlike the other form of WMD, it does not lead to MAD (mutually assured destruction) hence preventing its use. Instead it is commonplace and used frequently within corporate and government boundaries, leading to a situation that MADness is the common state of affairs and WMD is applied liberally.

a "super-aggregator" that "allows users to aggregate all types of feeds (blog feeds, search feeds, news feeds) and collaborate around them. It provides tag clouds, Digg-like voting, Technorati and Alexa widgets, user tags and many other features.

Friday, June 15, 2007

"Capitalism, then, is by nature a form or method of economic change and not only never is but never can be stationary"

The second is :-

"products or technology don't make great businesses, people do."

Your products are going to change, your markets are going to change - if you want to survive you are going to depend upon people. Now, I've been through this a number of times with Fotango; from a photo service to a software house and now to utility computing services.

The trick is transformation. You need to maintain one existing business whilst building an entirely new future. It's not an easy challenge, it takes a lot of time and energy.

I'm lucky though to have a wonderful team of skilled, passionate and talented individuals. I'm very proud of them and their achievements.

Zimki is a cool piece of software backed up with good ideas, a strong movement towards utility computing grids and viable new businesses to be created. There is still a lot more to be done, and then we need to build a community around it.

Transformation is not always a smooth process, sometimes there is too much to be done and sometimes that next step is just too high or you are not quite ready yet. At moments like this, you need to take stock, regroup and try another way.

Obviously we are disappointed to miss our target and some of the reaction has been negative. I do understand this, I understand the frustration and concern. I'm deeply sorry for this.

As I said "we'd rather do it right rather than just right now" of course given the choice "I'd rather do it right and right now" but sometimes that's just not going to happen.

My talk at OSCON will be on the impact of commoditisation in both manufacturing and IT and how open sourcing is driving the acceleration of innovation. I'll have to leave the announcements on Zimki to a later day.

So what's the third rule? Well that one I'll keep to myself. I can't give away all my secrets! That one is worth at least a cup of coffee.

Wednesday, June 06, 2007

I've waxed lyrically for a very long time about the distinction between CODB (cost of doing business) vs CA (competitive advantage) in IT, commoditisation of IT and the need for a "national" grid of utility computing resources.

We covered many of these subject in detail, along with 3D printing & worth based development back in Euro 2004.

So it is interesting to see how things have developed since that time and a lot of the new companies arriving on the scene.

There are so many it is difficult to keep track, but I noticed recently this announcement of a SaaSGrid. The concepts seem similar to our Borg system (which we've been using internally since about 2003) and Zimki (which previously was called libapi and internally is known as fish - more on the naming of Zimki.).

A platform you can build another application on, you charge for it with a utility pricing model and you sell it forward with a utility pricing model. Excellent.

Though they don't seem to have launched yet, it is interesting. However, there is one disappointment for me - "do it all without technological lock-in" and "host it with patent pending scaling and reliability technology ...".

The key to generating a true federated grid and avoiding any lock-in, is and has always been an open and free standard (i.e. running code, an open source reference model for implementation which defines the standard). I'm talking at OSCON this year and most of my talk will be on this matter.

The people behind SaaSGrid seem to be Matt and Sinclair from SaaSBlogs. They seem smart enough cookies, and I wish them best of success.

I hope they consider the whole open standards issue of a federated grid, because this is where the real battle will be fought and is it really to everyones interest to create multiple competing standards?

For the love of gold seems a more apt description of Damien Hurst's latest work. I'll refrain from calling "For the love of God" a work of art yet, though it does show technical skill and does question what is art? Why refrain? Well, I find this idol to mammon currently on sale for some £50 million somewhat ethically disturbing. I would find it difficult to describe a montage of video torture as art because it does nothing to improve the greater common good. The ends do no always justify the means.

Purpose and means has always been an important part of art for me.

Damien's idol would appear to be a celebration of materialism over all else and as such it can be argued that it questions our relationship with wealth? But does it? Surely the purchasing of such a gaudy item, the material cost of which could instead save thousands of real lives just reinforces our celebration of wealth over life? Does this serve the greater common good? Well in my opinion it debases it. As such it is not good art, and therefore not art in my books.

However, in all such things there is always a sting in the "tale".

The funds raised from selling this idol could be used to save real lives - greed turned into need - a sort of "For the love of Gold". Allowing a montage of real lives saved because of one buyer's desire for a macabre bauble. This creates a virtuous circle which truly explores the relationship between wealth and life, in a way that this gilded "sepulcher" sold commercially for profit could never do.

Maybe Damien is planning something like this, a next step. Maybe the exclamation mark is not the end of the story but just the end of one chapter?

What's worth more a montage or the bauble? This does question our relationship between wealth and life.

So to me, it all depends upon on the real purpose of this work - Damien maybe planning, what I would consider to be, one of the greatest pieces of conceptual art this century and exposing us to these searching questions or it may just turn out to be an expensive trinket which says more about the purchaser than anything else. I'm more than a little curious about which way he takes this.

Saturday, June 02, 2007

Now there is nothing revolutionary about providing a utility computing cloud through an online development environment - it's just a common sense application of previous ideas.

Since we launched Zimki back in early 2006, we've talked constantly about "yak-shaving", the benefits of simplifying the process of development and for only paying for what you consume etc. We've haven't just been handing out the T-Shirts though, we've been doing this for real. There are some really decent ideas behind it.

Firstly,"it is more efficient to have multiple network services share a common infrastructure that can absorb failures and bursts in client demand than it is to have every service over provision resources to accommodate peak requirements" - see Chaki Ng et al.

Secondly, assuming that every provider uses a common standard or engine then resilience can be achieved through a network of providers greater than any single provider.

The key to this all, is creating the federated grid of common service providers (think of a national grid of electricity providers), an exchange of computing resources and eventual virtualisation over multiple providers and even P2P. The problem has always been, how do you achieve this? You can't just move from one environment to another and expect it to work, there's usually installation, set-up etc, limitations involved.

Hence the reason why open source is such an important part of this puzzle. It's all about building that free and open standard to allow this to happen.

This has been a personal mission for me, as I hate all the stuff which gets in the way of me building something new. I want the freedom to build my application and it's data and release it into a cloud, knowing that it will work. I want my application to move from one cloud to another either because of demand or because I tell it to or because some fault happened somewhere. I want to know that it will still work. I don't want to be shackled with building infrastructure, worrying about capacity planning, demand spikes, disaster recovery, load balancing, test and staging environments and worst of all the cost of it all. All this stuff gets in the way of me building - I want freedom from this "yak shaving" - I just want to build new and interesting things.

Undoubtedly, at the beginning, any standard will come with limitations.

With Zimki you can build whatever you want but you need to write it in JavaScript, which runs on our servers. We chose JavaScript because of web services (XML, JSON etc) and all the other stuff happening on the web - it just seems logical to run the same language on the client that you run in the cloud and relatively straightforward to add persistence to JavaScript on the server.

The plan has always been to open source Zimki to try and create that first standard. Even if it is adopted, Zimki would be just a starting point on this journey. We are going to need others to join us, provide infrastructure clouds which fit with the standard and help develop the standard. Everyone competing and sharing in this federated grid.

But won't that "alienate one crowd that, well, we owe pretty much everything to - software developers and engineers" as Matt says?

That depends upon whom you're talking about - certainly you are going to upset some people because fundamentally it's about commoditisation and turning an often customised but commonly needed item (like a computing environment with CPU resources, storage and bandwidth) into a standard. Commoditisation does means less customisation, but is that a bad thing? Users of a web application have no idea about your infrastructure, they only care that your applications works. In developing an application, I don't care about the infrastructure only that it works reliably, provides my application with the resources it needs, doesn't cost the earth and that if I'm not happy I can move to another environment quickly and easily.

I don't mind if it's two boxes or ten thousand, I'm not interested in how many disks or blue lights there are - I'd rather that this was someone else's problem to solve. I just care that my app works, runs well, cheaply and simply. Of course, some people earn a decent living out of making life complex - I'm sure there were a lot of upset people when the national grid formed, or railway gauges were standardised or TCP/IP became the standard network protocol or when HTTP appeared on the scene.

This always happens whenever you deal with infra-structural goods. There are always some losers, but overall such standardisation is to the greater common good. The upside of commoditisation (forgetting the massive reductions in waste and so forth) is that it allows for new opportunities to develop. It allows for progress.

So yes, it will alienate some people - but for most it will hopefully be liberating, allow for more creativity and free us from the shackles of the old way. All that's needed is an adopted open and free standard. An open sourced Zimki might help us on that road, maybe something better will come along.