Infrastructure convergence – the two sides of the coin

Let’s be fair – IT isn’t the only industry fraught with jargon, but it can certainly hold its head up high among the leaders of the field in terms of gobbledygook. The minefield of acronyms we all have to suffer is worsened by the astonishingly bad practice of overloading individual, sometimes quite innocuous words and combining them with new ones, which in turn are subjected to unnecessary and distracting debate. And so we are subjected to hearing such things as, “That’s not a business process,” or “Adaptive virtualisation through best of breed solutions.” Members of the Plain English Campaign must be constantly shaking their heads in desperation.

Realistically however, it’s nobody’s fault. I put it down to the fact that we’re working in such a new sphere of human development that existing language just isn’t sufficient to support the dialogues we need to do our jobs. It doesn’t help either that the industry is stuffed full of geeks (I’m one of these) and armchair philosophers (and these) in equal proportion, but that too is a symptom of the times. Take away the people that are inventing all the convoluted phraseology, and you’d take away the innovation as well.

And so to convergence. There’s a word. It may have existed before the IT revolution – “The massed forces of Napoleon’s armies converged on the plain,” for example – but we’ve taken it and made it our own. Convergence means different things to different people, and given that it looks like it is becoming a very important word indeed, it is worth exploring a couple of these meanings.

IT is all about convergence. Convergence pressure comes from the top down, as a counter to complexity. My dubious understanding of evolutionary theory tells me that it is as much about diversification, as survival of the fittest. Innovation is another word for the relentless drive by vendors to release new products, and providers to release new services, in the hope that some of them will become as popular as Windows, Google or the iPhone. Deep in the infrastructure as well, plenty of new-and-improved technologies deliver all kinds of clever benefits, but only add to the complexity of the infrastructure. Understandably, then, IT environments start to hit issues of fragmentation, of complexity management, of interoperability.

We’re seeing it right now with virtualisation for example – lots of benefits, cost savings etc but we’re only starting to see some of the issues (e.g. virtual server sprawl, back-end bottlenecks) that ensue when virtualisation moves out of the pilot and into production.

Meanwhile, convergence also comes from the bottom up. New technological advances tend to get subsumed into the infrastructure or application architecture – which is why we see waves of merger and acquisition activity throughout the history of IT. But it’s not just about making different things work together – it’s also recognition that certain technologies, which may start independently to solve separate problems, eventually need to come together in some ways.
And so in the telecomms world we have that wonderfully obscure acronym, FMC, which stands for fixed-mobile convergence – bringing together traditional telephone infrastructures with mobile infrastructures. We’re also seeing the convergence phenomenon in the data centre – or more importantly, in how the different devices in the data centre communicate with each other, that is, storage, servers and communications devices. IT has always been about processing information and moving it around – and historically, the three types of device have evolved along their own, discrete-yet-interoperable paths. But right now the industry is coming to terms with the fact that there can be only one data movement standard that all devices share – without getting into the fuzzy words too much, this is called 10 gigabit Ethernet.
The timing for the convergence of data centre technologies couldn’t be better, given what we’re seeing with virtualisation. Note that it’s not just about everyone saying, “let’s all use Ethernet,” rather, the 10GbaseT standard has had to be defined to support a wide variety of requirements imposed by the data communications, application latency and storage throughput needs of modern IT environments.

In other words, the data centre convergence we’re seeing is not only an inevitable step given the evolution of the underlying technologies, but it is responding to a real need caused by the fragmentation of today’s IT. It’s important to see both together – as there have been all kinds of technology convergence that have come at the wrong time – i.e. not responding to a significant enough need – and that have fallen by the wayside. Examples include policy-based management of security, and perhaps even FMC which will remain a slow-burn until it becomes an necessity. But for data centre convergence, the time could well be right.

[Written at Fujitsu VISIT 09 conference, during a keynote by Dan Warmenhoven, Chairman of NetApp - who famously said "Never bet against Ethernet!"]

Towards dynamic systems management methodologies

I do take my hat off to the people who first put together the IT Infrastructure Library, which (like the end of the cold war) celebrates its twenty-year anniversary this year. It’s one thing to learn, both on the job and with little support, the ‘golden rules’ and best practice principles of any discipline. It’s quite another to have both the gumption and skill to document them in a way that makes them usable by others. And I should know – the time I spent working in the methodology group at a large corporate were a fair illustration of how tough this can be.

So, when the books that made up what we now refer to as ITIL were first released, they must really have hit the nail. First adopted by public organisations in the UK, they have since become one of the de facto standards for large-scale systems management. Their authors can feel rightly proud: as indeed can the authors of other best practice frameworks that have, through force of adoption, been proven to it the spot.

However, there could be a fly in the ointment, and its name is dynamic IT – the latest term being applied to more automated approaches for managing the resources offered by our data centres. I know, I know, this is one of those things that people have been banging on about for years – indeed, for at least as long as ITIL has been around, if not longer. So, what’s different this time around?

There are a number of answers, the first of which is virtualisation. While it is early days for this technology area (particularly around storage, desktops and non-x86 server environments), it does look set to become rather pervasive. As much as anything, the ‘game changer’ is the principle of virtualisation – the general idea of an abstraction layer between physical and logical IT does indeed open the door to be more flexible about how IT is delivered, as many of our recent studies have illustrated.

The second answer has to be the delivery of software functionality using a hosted model (’software-as-a-service’, or SaaS for short). No, we don’t believe that everything is going to move into the cloud. However, it is clear that for certain workloads, an organisations can get up and running with hosted applications faster than they could have done if they’d built them from scratch.

I’m not going to make any predictions, but if we are to believe at least some of the rhetoric about where technology is going right now, as well as looking at some early adopter experiences, the suggestion is that such things as virtualisation and SaaS might indeed give us the basis for more flexible allocation, delivery and management of IT. We are told how overheads will be slashed, allocation times will be reduced to a fraction, and the amount of wasted resource will tend to zero.

We all know that reality is often a long way from the hype. If it is even partly true however, the result could be that the way we constitute and deliver IT service becomes much slicker. IT could therefore become more responsive to change – that is, deal with more requests within the time available. In these cash-strapped times, this has to be seen as something worth batting for.

But according to the adage, the blessing might also be a curse, which brings us back to the best practice frameworks such as ITIL and what is seen as its main competitor, COBIT. In the ‘old world’, systems development and deployment used to take years (and in some cases, still does) – and it is against this background that such frameworks were devised.

My concern is how well they will cope should the rate of change increase beyond a certain point. Let’s be honest: few organisations today can claim to have mastered best practice and arrived at an optimal level of maturity when it comes to systems management. Repeatedly when we ask, we find that ‘knowing what’s out there’ remains a huge challenge, as do disciplines around configuration management, fault management and the like. But in general, things function well enough – IT delivery is not broken.

The issue however is that as the rate of change goes up, our ability to stick to the standards will go down. Change management – i.e. everything that ITIL, COBIT and so on help us with, has an overhead associated with each change. As the time taken to change decreases, if the overhead stays the same, it will become more of a burden – or worse – it might be less likely to happen, increasing the risks on service delivery.

To be fair, methodologies aren’t standing still either – indeed, ITIL V3 now builds on the principle of the service management lifecycle. But my concern about the level of overhead remains the same: ITIL for example remains a monolithic set of practices (and yes, I know, nobody should be trying to implement all of them at once!). There’s part of the framework called ITIL Lite, designed for smaller organisations, but to be clear, the ‘gap’ is for an “ITIL Dynamic” for all sizes of company. In methodological terms, the difference would be similar to DSDM and its offspring, compared to SSADM in the software development world – fundamentally it’s the difference between to-down centralisation, and bottom-up enablement.

Perhaps the pundits will be proved wrong, and we’ve still got a good decade or so before we really start getting good at IT service delivery. But if not the question I have therefore is, how exactly should we be re-thinking systems management to deal with the impending dynamism? We could always wait for the inevitable crises that would result, should the dynamic IT evangelists be proved right this time around. But perhaps its time for the best practice experts to once again put quills to a clean sheet of paper, and document how IT resources should be managed in the face of reducing service lifetimes. If you know of any efforts in this area, I’d love to hear about them.

Losing a device – what’s the big deal?

(This talk was originally given at a CBR dinner club event in October 2009)

It shouldn’t come as a surprise to anybody, to know that mobility does bring with it a business advantage. Last time was asked that question a couple of years ago, two thirds of companies of all sizes consistently said ‘yes’ – and we can be reasonably confident that the figure will have risen since then. In the same study, a staggering 80% of companies permitted access to corporate systems from company-owned laptops and/or PDAs. And meanwhile, from the same research, we found that a quarter of companies saw the risk of exposure through device theft or loss was ‘high’ (and a further quarter as ‘medium’).

From our own experience, laptop theft is like car accidents – everyone knows someone who has been involved, but it always happens to someone else. As for phone loss – is there anyone who hasn’t lost a device at some point? I can think of hotel bar, roof of car, casino bar… is there a theme developing here? Actually, we do know from some more recent research – about 15 percent of respondents had personally suffered accidental loss or theft of ‘bag, keys, wallet/purse, phone, laptop’ in the six months that preceded the study. (And incidentally, 25% of organisations said they had suffered theft of corporate equipment in the same period – so it all adds up)

But really, the loss of a device doesn’t matter so much. Sure, there is the capital cost – you wouldn’t want to do it too often. From a corporate perspective, we know consistently from our research studies that the biggest IT-related risk involves the loss of business-critical information.

The problem only starts to surface when the two worlds collide. When I lost my Motorola flip-phone in the Fairmont San Jose, the most annoying thing was that I still had a whole bunch of connectors, chargers etc that immediately became redundant. When I left another device in the Venetian, it also contained my entire contacts, task list, recent email conversations and various other files. Fortunately I had put a PIN on the device – or rather, our hosted Exchange service had enforced a policy which set a PIN for me. Of this, more later.

But for now we have to face the fact that mobile devices are astonishingly capable of storing quite huge quantities of data. And it’s not just mobile phones either. When I was speaking to an IT Manager at IP’09 last week about disaster recovery policy, I asked him how much data was involved – expecting the answer to be in the Terabytes. “A few hundred Gig,” he said… that is, the amount of data that could quite comfortably be stored on an iPod.

It was so much easier in the mainframe world – have you ever tried to lose a mainframe? But these days, we have the combined effects of the gadgetry becoming increasingly easy to lose, coupled with the fact that devices can store exponentially increasing quantities of data.

The ‘so what’ becomes clear when we define what we mean by ‘business critical’. Private (and increasingly, public) organisations case about one thing the most: money. So, information loss matters for one of two reasons: if information is lost, either it’s going to prevent the business from making so much money, or it’s going to cost the business money to deal with the impact. There are mitigations for the former – organisations have a plethora of data protection mechanisms available to them (and if you want to know more, let me know and I’ll send you a copy of our next book when it comes out).

But the latter is harder to mitigate against. If a company ‘secret’ is released into the wild, it can be copied; if customer data is released, there is a compliance cost as well as reputational damage. Having said that, it does astonish me how blasé people are with their information – to be fair, me included. I believe T-Maxx actually increased sales having lost all those credit card details.

So, what to do about it? Well, there are a variety of technological measures that can be brought to bear – either to lock down devices, prevent information from being released without authority, audit where it has gone, remote-destruct the data and/or device (with just a whiff of Mission Impossible) and so on.

We know that this area is underserved – roughly half of the organisations we surveyed felt well protected against the kinds of inadvertent breaches they suffered as a result of theft or loss, compared to external attacks. While we know data leakage tools and technologies are not implemented to the same level as malware protection, this is also an indication that technology alone is not the answer. When we looked into this we found little between the challenges of dealing with the existing security infrastructure (i.e. plugging the holes), implementing appropriate policies/processes, or indeed making the necessary cultural changes to get the right tools and mindsets in place. These areas are all hard, though not insurmountable.

What the research also highlighted, were the places to start however. The absolute ground zero is understanding risk – we could paraphrase “knowing the price of everything and the value of nothing” to be “seeing dangers everywhere, but risks elsewhere”. In this context, the only important risks are business risks – that is, those that can impact an organisation and its dependents.

The second lesson we have learned is around policy. Draconian rules don’t work – they are tough to implement, difficult to enforce and impossible to keep up to date. So put away the superglue. We advocate a ‘minimum necessary’ approach – for the simple reason that if you can’t implement that, you don’t stand a cat’s chance in hell of implementing the maximum possible. Simple example: PIN numbers on PDAs (I said I’d come back to that!).

Finally, we look for cause and effect in our research, and one factor which surprised us in its effectiveness was awareness raising – in some cases breaches were being reduced by an order of magnitude in organisations that had some kind of awareness programme in place.

Security tools are just that – tools of the trade. All for it – but organisations who think that tools alone will solve the problem, are cruising in the fast lane with a blindfold on. When the crash happens, it won’t matter how good your airbags are.

The Bathtub Curve and other over-simplistic ideas

Every now and then, a certain model or other seems to have direct relevance to a whole series of challenges. It’s funny how it happens – at one stage (for me anyway) it was Eli Goldratt’s Critical Chain theories for project management (and the whole world started to look like projects), at another it was Rich Man, Poor Man by Robert Kiyosaki (and the whole world started to look like a series of investments), and elsewhere it has been Charles Handy’s Sigmoid Curve (which makes the whole world look like a series of false starts). Right now, as companies tussle with balancing capital expenditure (capex) with operational expenditure (opex), it’s the bathtub curve.

The bathtub curve? Yes, the bathtub curve. It does seem worth an explanation, since I’ve had to explain it every time I’ve mentioned it. “You know,” I say, “When you first implement something there are lots of faults – like snagging in a new house – and over time things settle down… but then after a while the number of faults starts to rise again?” And of course, everyone agrees, because it’s a very familiar picture for anyone working in IT.

I was first introduced to the bathtub curve when an old colleague of mine was working on the railways (or at least for the railway companies as a consultant) to try to help them save money. His findings weren’t pleasant reading. As UK railway companies (and before that British Rail) had tried to sweat the assets – rolling stock, track and the like – to the maximum, things had inevitably ended up right up the wrong end of the bathtub. Maintenance costs were huge, downtimes and delays frequent and so on, as indeed they still are. Trouble was, investment was only ever in one area – “We’ve funded another thousand miles of new track,” someone would say. But that would be without fixing the rolling stock, which would wear out the track more quickly, and so the cycle would continue.

There’s been plenty more written about the bathtub curve, so I won’t dwell – but I did want to relate the challenge with maintenance in general, to IT in particular: that is, when to make investments and upgrades? There will never be an absolute answer to this: while some recent data suggests that a three-year rolling cycle may be appropriate for desktop PCs for example, for a mainframe that may be the amount of time required between reboots. Ultimately, the bathtub curve gives us, for any ‘closed system’ (in IT terms, set of infrastructure assets that need to operate in harmony) a relationship between capex and opex. Capital expenditure will be required on a discrete basis, to replace older parts, upgrade software, and so on, whereas opex covers the costs of more general servicing, support calls, diagnostics and so on.

Wy is this important right now? We understand from out conversations with all but a few IT decision makers that “attention is turning to opex,” which roughly translates as “we haven’t got any cash for capital investments, but we do need to keep the engine running.” Which is fine, of course – but only if an organisation’s IT is still running along the bottom of the bathtub, as measured by SLA criteria and the costs of service delivery. Perhaps the most important question to be able to answer is, “How long have we got before things start getting expensive?” A simplistic question perhaps, but inevitable if things are not treated before time runs out for them. As another adage goes, “A crisis is a problem with no time left to solve it.”

European analyst of the year

Well I certainly wasn’t expecting that! A couple of weeks ago, Freeform Dynamics and yours truly were announced as award winners in the annual IIAR survey of analyst relations professionals. Here’s the stickers:

From an EMEA perspective, Freeform Dynamics was ranked as number 2 after Gartner. I was selected as EMEA analyst of the year, and number 2 (after the illustrious Ray Wang) globally.

I know there’s all sorts of ways of measuring these things – and I also share a number of views with those who say there’s a wider picture of influence (though Vinnie, there’s more to technology decisions than procurement decisions!). That being said, the results are not to be sniffed at – and it’s a distinct pleasure to be viewed in such esteem, so thank you everyone who voted!

Virtualisation and security – the two-edged sword

All new innovations in IT are a double edged sword – with the benefits come challenges and unintended consequences. Not least server virtualisation, which does have a number of security advantages over running software directly on servers. While it’s worth considering these, it’s also worth weighing them up against the challenges, particularly given the relative immaturity of the technology.

To be fair, virtualisation has been around ever since the dawn of computing – what is an electronic computer other than a virtual environment? I did get into trouble a few years back for crying foul when Microsoft claimed, “We’ve been doing virtualisation for many years,” but to an extent they were right – as soon as there is layering or abstraction in a computer system, we have something that could be termed ‘virtualisation’. So, we have virtual memory, virtual disks, and indeed virtual machines.

It’s this latter version of virtualisation that’s garnering most interest currently, and to be more specific still, virtualisation when applied to X86 (i.e. commodity) servers. Until this side of the millennium, server computers didn’t really have the horsepower to run multiple, virtual machines (mainframes did of course, but were still a bit pricey – a factor which is notably changing). Now, with multi-core processors that build in virtualisation hooks (essentially, enabling instructions to be run by the virtual machines in a fashion which makes them pretty much as fast as running on physical machines), server virtualisation has crossed into the mainstream.

From a security perspective, virtualisation has a number of advantages. The first, almost a by-product, is how virtualisation adds to the fundamental security principle of ‘defence in depth’. The virtualisation layer provides an additional level of abstraction which needs to be cracked if the core application is to be reached. In this way it’s a bit like Network Address Translation (NAT) in that it keeps core applications one step further away from the bad guys.

Virtualisation also offers what’s referred to as a ’separation of concerns’, That is, different workloads (i.e. applications) can be run within their own virtual machines, such that if there is a problem with one, then others should not be affected. Building on top of both of these concepts, security features can be built into the virtualisation layer – in principle (see below).
However, virtualisation does have its security downsides. I’ve already mentioned the additional virtualisation layer – this can either exist as a hypervisor (for example that from VMware or Microsoft) or as an extension to an operating system kernel (for example using KVM in Linux). For the additional layer to be effective, it needs to be secure – in some ways more secure than the operating systems and applications it hosts, given that if it gets hacked or goes down, they all go down.

Without dwelling too long on specific vulnerabilities (there’s a handy summary of some here), suffice it to say that the presence of an additional layer adds to the security burden rather than reducing it. Not only is it necessary to secure the hypervisor, but also the management tools that go with it (which may be, for example, susceptible to brute force attacks to attempt a login). There are a number of ways of mitigating these risks, both in terms of patching against specific vulnerability, and also defining building security into the virtual architecture with appropriate use of firewalls and other protective measures. Baking such capabilities into the virtualisation layer is still, admittedly, a work in progress as illustrated by recent announcements such as VMsafe.

There are some additional risks resulting from the increased flexibility that virtualisation brings. For example, a virtual machine may be moved from one, highly protected server, to another far less protected server with out it being absolutely clear that anything untoward has happened. This scenario becomes even more likely if there is insufficient controls over the provisioning and/or management of virtual machines. A virtual machine could even be moved off-site, onto a third party server (at a hosting site or ‘in the cloud‘, to coin a phrase.)

Perhaps one of the biggest security risks at the moment is that organisations are deploying virtualisation without always considering the security implications. At a panel I hosted at Infosecurity Europe a few weeks ago, one security pro in the audience explained that in his organisation virtualisation was being brought in primarily for cost reasons (nothing wrong there), but also that the rush towards savings was made without taking security into account (e.g. by costing it into the business case). Security comes at a cost, and like fault tolerance and other risk management approaches, it never works quite so well when it is retrofitted; the knock-on effects of rushing towards virtualisation may also include the aforementioned proliferation of virtual machines, resulting in a more complex (and therefore riskier) environment.

This factor is borne out when we consider recent Freeform Dynamics research suggesting that less than a quarter of organisations feel they are operating at ‘expert level’ when it comes to virtualisation – the impact is that knowledge of security best practice for virtualisation will still be lacking for many.

In conclusion, then, it is important to remember that these are still early days. Virtualisation undoubtedly has its benefits, not least from a security perspective. However organisations adopting virtualisation today would do well to ensure they do not increase the level of security risk they face. A simple risk assessment at the start of any virtualisation deployment, together with an appropriate level of vendor and product due diligence from a security perspective, could be the stitches in time that save a lot of heartache later.

Quick take: Will Borland find a good home with Microfocus?

Having written quite recently on Borland, I felt obliged to comment on its recently planned acquisition by Microfocus. While the press release talks about ‘market opportunity’ and the like, its also important to think in terms of what it means for software tools customers. A couple of starters-for-10:

1. Borland, having sold off its developer tools division to Embarcadero and kept its application lifecycle tools, has just been picked up by Microfocus
2. Microfocus, having moved from being ‘the COBOL company’ to being ‘the application modernisation company’, has also just bought some testing tools from Compuware

Putting both points together, Microfocus is starting to have quite a comprehensive portfolio when it comes to software development management. But there is a deeper question here. Borland, for all its problems, was doing pretty well in terms of reaching out to the agile development community. Meanwhile Microfocus’ core audience remains organisations that have a larger pool of legacy applications, COBOL or otherwise. Undoubtedly, there is an overlap between the two communities – but it may not be that great: research we have done in agile development draws out one audience, while traditional development and maintenance continues on a somewhat different track.

Where’s the hinge? I believe it lies in SOA – or at least, in the drivers towards an IT environment in which the principles of SOA make sense. This convoluted statement is somewhat deliberate given our consistent finding that many organisations may be doing SOA-like activities, they just don’t use (or even dislike) the term.

A story. A few years ago I did some work with a large, traditional organisation – my task was to train up staff on modern development techniques. Trouble was, I arrived to be told that the CIO had blocked any new application development – any ‘developer spend’ needed to be focused on enhancing existing systems to deliver against new business requirements. While the CIO later relented, it certainly focused how I was to approach what I had been tasked to do.

After a series of workshops, the result was not awfully different from what might be considered a legacy modernisation exercise – understanding the new requirements, mapping them against services provided by the legacy applications, and (through gap analysis) prioritising development activities. Essentially, the first part of the exercise enabled us to identify what needed to be done, at which point ‘development’ could take place in a way that made the most sense.

And what was that way? Certainly, waterfall approaches would have been a poor fit given that there was already a great deal of functionality available – while some (re-)development was necessary, as much focus needed to be placed on a more integration-led approach to software delivery – something which today we might call an enterprise mash-up. Offering a far better fit at the time were timebox-led development approaches such as DSDM – such approaches have of course led to what we call agile approaches today.

From a Microfocus/Borland perspective, then, there is the potential for a good fit between traditional and modern, legacy and agile. Taking into account questions of scalability, availability, security and the like, application modernisation can lead to a platform of functionality to be used across the organisation, which can then be built upon using agile techniques to respond to specific business requirements. I’ve not talked much about the (Compuware) testing piece here – though this is clearly an important element of any integration-led development story. But this is a good start. If Microfocus/Borland looks to help its customers in such a way as to balance old with new, then the acquisition will have my vote.

Virtualisation – The State of Play

I presented this at an IBM-hosted event a couple of weeks ago. Enjoy.

Why Sun Microsystems makes me angry

It’s not often in this job that I feel genuinely cross about an industry situation, but I find that’s the case with Sun Microsystems. before I start I should declare my hand – I used to run a Sun environment of a few tens of servers and a few hundred workstations. When I say “I used to run” to be fair I had a team of people doing most of the work, including Oracle DBAs, UNIX administrators, software tools people and the like, all of whom were pretty good at their jobs – but I did still get my hands dirty, mostly on the sysadmin side.

Sun was one of the very first companies I ever knew the tagline for – “the network is the computer” – something I first learned when I visited their offices to run some benchmarks on a cross-compiler available from the Catalyst catalogue. To be frank, twenty years on I’m still not sure what the tagline means if I think about it too hard – but it still sounds good. Perhaps Cisco has finally cracked it with its, “no, no, we’re not a server company,” Unified Computing fabric, but time will tell on that one! Something for another post perhaps, I’m here to talk about Sun.

Another declaration I should make is that I haven’t got a monopoly on the facts. But I have, in one way or another, been following Sun’s activities for the past couple of decades. For better or worse: while the hardware has frequently been impressive, and wile the level of innovation has been fantastic at points, equally, I have suffered the consequences of when ‘open systems’ meant ‘anybody can get in unless you know how to fill the holes’, the battles between BSD and System V, the dangers of having the wrong support contract, and so on and so forth. These are no rose-tinted spectacles, I assure you.

But today we see the company failing to agree a price for its own demise, having failed to convince the world that open source is ‘the one way’, and having failed to monopolise its clear advantages in development software, and yes, it makes me angry. Not because of these failures in particular, but because even while Sun has been under-performing in each of these, they all ignore what has always been the company’s core strength – that of building world-class data centres and surrounding infrastructures. Sun’s reputation and brand is built around IT architecture with all its ‘ilities’ attached – scalability, availability and the like. In this, Sun has not so much been giving away its crown jewels, more that it has left them to crumble into dust .

When and how did this happen? It’s difficult to argue otherwise than the wind went out of Sun’s hardware-centric sails five years ago, when the company became “the dot in dot-bomb”. Too much inventory of second hand stock, e-customers literally vanishing left, right and centre, massive commoditisation of the market (cf HP/Compaq), proprietary vs ‘industry standard’ all played their part. Scott McNealy may not have retired at that point, but a little part of the spark died, and the company was late to many parties after that (the decision to adopt AMD chips for example).

I could talk about Java, and my agreement with a Sun exec a few years ago that it wasn’t so much that Sun was in the wrong ball park, it didn’t even get that there was a game on. But software has always been peripheral to Sun, stuff that runs on the boxes. This isn’t what makes me angry however. What does is that a few people at the top of a company can be in denial about what great things it could be doing for its customers, and can set a strategy which not only ignores what people want from Sun Microsystems, it also ignores what the majority of customer organizations want from their IT. Here’s a clue: it’s not wall-to-wall open source, as the open source model is a means, not an end. Ultimately, as an ex-customer, I feel let down as the values I thought I shared with the company have been eroded to a point of irrelevance.

What should, or indeed can be done at this stage? If I knew I could be very rich of course, but that would also assume anyone at Sun Microsystems would listen – the company hasn’t been famous for this in the past. I would start squarely in the mindset of IT architecture, and building efficient platforms that can deliver appropriate service levels to enterprise and mid-market customers. Isn’t that what Sun does? I only wish I knew – it certainly isn’t what it seems to spend its time talking about. I would drop the argument about open source vs proprietary – it’s laughable, particularly given Sun and its own proprietary history. Sadly a Damascene conversion to open source and a few (arguably sound) acquisitions doesn’t make an open source company in practice. Its customers don’t want it from Sun, and Sun can’t deliver it.

Not everything that Sun is doing is necessarily bad – the cloud-for-developers approach also seems sound for example. But any goodness is being lost in the noise of delusion. I genuinely hope that Sun Microsystems, once proud, returns to its former $200 billion status, for the right reasons – notably that it is delivering what customers want. And on this latter point then, finally, if I were Sun I would stop talking about how great everything is (when the whole of the rest of the world knows it isn’t), knuckle down and start delivering.

How hard can it be.

Reading The Big Switch #1 – the economist’s world view

Recently I’ve got into the habit of picking up (largely from the Library) a number of books of a certain genre, and ploughing my way through them – in general, it is the ones that are most compelling that will drive me past the first few pages. And so, I currently have, on the bedside table, amongst others:

• The World Is Flat by Thomas Friedman
• The Long Tail by Chris Anderson
• The Big Switch by Nicholas Carr

As well as providing the selection, an advantage is that such books can be seen as a set, as well as individually. Fantasy books for example often seem to start a short period after a massively destructive event, following the perpetrator when he/she is still small, as they pick their way through calamity; meanwhile, popular tech-business-economics books like to mingle anecdote with theorising (to the extent I have likened them to guys in a bar in the past).

To the point – which is the book that has reached the top of the pile – Nicholas Carr’s Big Switch. Highly eloquent, but I can’t help myself wanting to pick holes in it – not through pedantry or resentment I should add, more because in places it just appears plain wrong. “Computing is turning into a utility,” it says on the back cover. “No, it isn’t,” I say. “Cloud computing is a revolution,” it says. “Nope,” I find myself responding – in the knowledge that in the many debates I have with my colleagues Dale, Tony and Martin on the subject, these are points on which we unanimously agree.

Don’t get me wrong, I’m all for provocative titles that get people thinking, yadda yadda. But it’s not just the conclusions I’m finding flawed, it’s the justifications as well. Which wouldn’t be such a problem if the chap wasn’t so widely read – kudos of course, but what if people actually acted on what is proposed without thinking things through first? Given that by the time I have finished the book I know my flighty mind will already be moving onto even fresher fields, I know I will have missed the opportunity to compose a suitably well argued riposte (if that is what is required). So instead, here is the first in a series of posts about The Big Switch, which offer thoughts as I go along. I promise less introduction, more meat next time.

A. Technology shapes economics shapes society

This appears to be a bit of a theme in the early sections of the book, both explicitly (page 22). Perhaps it’s because I’m not an economist (so what do I know) but I don’t believe the relationship is either linear, nor in the right order. “Technology shapes society shapes economics” would be more accurate, though society does drive technology (particularly in terms of military demand). Economics, from the layman’s perspective, is the mathematics of society – the former may be able to model the latter, and even enable certain predictions to be made, but economics is the mirror, not the thing.

The reason I bring this up is not to illustrate my knock-kneed incompetence when it comes to economics (and to be sure, I would no doubt be left for dead should I meet a bunch of economists in a dark alley and attempt to argue my way out), but because it illustrates the framing of the debate when it comes to The Big Switch. Mr Carr is fundamentally one of a clan who believes economics offers the route to explaining most things societal (and equally clearly, I am not) – with the result that arguments will have an undoubted economic slant. Unfortunately there are many perspectives that need to be taken, of which economics is only one in this case. IT architecture is another (given which, I believe a better parallel for IT might be the evolution of the transport system rather than the harnessing of electricity), and business readiness is a third.

A point I will come back to no doubt (as it is the central premise here) is that while economic drivers for full-fat utility or cloud computing may be compelling, there are a whole bunch of other reasons that make it impossible today. Or indeed tomorrow, or in 10 years’ time. We are currently struggling with the data privacy issues that are caused by single companies or government departments building increasingly complex information stores. Such challenges exist to be ironed out, it could be argued – or equally perhaps they are a demonstration of why we shall never fully consign our personal and corporate lives to the cloud. It’s a similar debate about whether there should be a global super-government – of course it would be more efficient if it could ever work (which is moot), but would it be desirable?

While not knowin’ much about economics, I do understand it isn’t all about money – which is a good job. But to see economics at the centre of the debate – the fulcrum if you will – is as unfortunate as seeing architecture as the centre, or business processes or whatever (I remember having a conversation with someone at a certain large software company, who said everything was about ‘management’ because there was management everywhere). As Anais Nin was reputed to say, “We don’t see things as they are, we see them as we are.” Or indeed, as our vested interests drive us – it was Mr Carr who pointed out McKinsey’s vested interests, but in his own debating stance he has been very clear that he has decided a certain stance to be true, and his own interest will inevitably to be defend his position.

From here I shall be moving onto more solid ground. The next blog in this series will cover the book’s misunderstanding of client-server, or more importantly, what is really the cause of data centre inefficiency today. Stay tuned.