A Cloud and BYOD metaphor - Why I never take the bus

{EAV:cf4fab46891e8edd}

A slightly off-the-way post today, but I wanted to get to the intrinsic root of demand that is driving the cloud computing and BYOD trends.

I never take buses.  I prefer to walk everywhere I go.  Thankfully I live in a city that is small enough to do so without having to wake up at 4 a.m. to walk to work.  I planned ahead when choosing a home to take the operational costs of commuting into account when I made the CapEx purchase.  There are parallels with the drivers that are pushing the cloud computing and BYOD trends.

Each day, I want to get from A to B.  A being my home, B being my office.  If I take a bus, I have to adhere to the bus company's schedule.  Unless I fit my life around the bus timetable to suit the bus company (which I'm not going to do), then I would spend time waiting at a bus stop every day, twice a day, 5 days out of 7.  Five minutes, twice a day adds up to about 40 hours a year - almost two days.  Spend half an hour waiting for a bus twice a day and you've just lost 10 days out of the year.  That's over £1000 for an average UK earner.  Overheads.  I digress.

I don't like waiting for other people before I can make progress.  I hate when a task I have to complete is dependent on somebody else.  The dependent task is never their top priority, so I have to go and do something else.  Loose ends are not my favourite thing and standing still is not a good strategy for anything.  A late bus is a failure in the 'supply chain', resulting in unproductive periods where costs are incurred ('time is money').

"Tickets please"

Sometimes when I walk to work it rains and I get wet, but because I'm not dependent on the bus service (and all its potential failure points) I get to work at a predictable time every day because it is an inherently simple process (move left foot, move right foot).  Predictable progress has a cost, but also a benefit, so I don't mind getting wetting 5 days out of a hundred.  Sometimes when it rains I will be passed by a bus, but this only represents the 'nice-to-have' requirements.  It would be nice to be on the dry bus - but not essential.  Paying for the bus every day when I would only really like to be on it a handful of days is akin to an organisation buying an on-premise IT tool with a spec far outside the scope of their current must-have requirements.  Just because one day I'll no longer be able to walk isn't a reason to buy a bus today.

If the bus can't deliver a service that suits me to the very minute, then I'll take another route.  The good thing about me legs is...they deliver a 100% flexible A-to-B service on demand.  And they’re my own legs so I already know what they can do.

Flexible, low cost, self-service, outcomes-focused, familiar, predictable, pervasive.  No contest.

The impact of social media on business and politics

[This is an article I posted to another blog back in April 2010 which is about to be shut down, so I thought I would rescue it.  Sometimes it's interesting to look back at perspectives from the past.  I like this post because it barely mentions IT stuff.  Although technology is the underlying enabler, it is in effect just the amplifier of human interaction.  It's the people element that is most important - and that applies to IT as much as it does to anything else.]

In prehistoric times, when monolithic companies ruled the earth, there were few competitors, no saturated markets and every industry had a handful of established leaders.  Driven by market research, these companies responded to the world’s requests for ‘more of the same but cheaper please’.  The monolithic companies were good at managing expectation.  Customers didn’t expect much, so they didn’t get much.  Change was slow, but nobody was in a hurry.  Standardization was the key to mass production and these monolithic firms got so good at producing standard products that it became the business model that defined the best part of the 20th century.  Despite what some people might think about the past, interaction with the market was impersonal, driven by interruptive one-way advertising on TV and radio networks.  Salesmen were the top dogs and doing anything to get a customer to part with their cash was the way to go.  Organizations were regimented into functional silos and slow-moving decision hierarchies.  The world wasn’t changing fast, so these monolithic firms could afford to be slow.  Markets were steady, supply chains were solid and blue chips were unassailable.

Then the world got connected and everything started to speed up.  Look at what’s changed over the last 20 years.  Yet the internet still reaches fewer than 30% of the population.  As technologies do become more widespread, tending towards 100% coverage, the rate of change is going to increase exponentially.

Any individual will be able to communicate with any other individual in the world in real-time.

Telephone, cell phone, VOIP, email, instant messaging.  Many methods are available to us now.  More (or indeed more likely fewer) will be available in the future.  I’ll leave you to ponder why pervasive real time communication should be a fundamental objective for us as a race.  Of course, this is only effective if it is supported by universal freedom of speech.

Heading back to the topic of the changing business environment, people in business are evolving to meet the challenges of rapid change.  Rules and rigid structures slow things down.  Agility is now the key to survival.  Standardization of products and services has been replaced by a custom approach.  Hierarchies are being dissolved to make way for business process management models, with horizontal processes cutting across silos to deliver what the individual customer wants.

The rules are – there are no rules.  The large blue-chips that dominated the world’s markets are finding themselves left behind.  Cumbersome structures and old-world thinking is giving light-weight competitors an advantage and with new attitudes towards partnerships and the latest technology supporting them they can deliver faster and better than the monoliths.

The internet meteorite has hit, and the old-world dinosaurs are choking on the dust, while the nimble warm-blooded mammals have taken a foothold.  There are still a lot of dinosaurs about, but their time is short.

What will IT 4.0 look like?

There has been much talk about IT 3.0 of late – shifting the focus away from technology and process towards people and their needs: meeting user-centric demands for access to technology, any time, any place, on any device.  We have a pretty good idea of what IT 3.0 looks like, which raises the question - what will IT 4.0 look like?

• Rocketpacks for faster desk-side visits.
• Cold fusion powered servers that put power back into the national grid and smell of pine forests.
• A 4D user interface which allows service desk analysts to go back in time and solve the root cause at the application development/infrastructure purchasing stage.
• CMDB models the entire universe for Ultimate Impact Analysis©.
• HiveMind crowdsourcing tool taps into the knowledge of advanced alien cultures.
• Hot-swapping of staff in business units, as these are the components most prone to failure.
• Borg monkeys hooked up to HiveMind provide cheap tech support staff.
• Hypochondriac bio-servers that self-medicate when they get a sniffle.
• Empathic network switches that also provide dating tips for tech support staff.
• 7thSon™ module automatically orders and builds infrastructure in anticipation of the CEO’s 'back-from-a-conference' whims.
• A 3D IT performance dashboard that picks up on the CIOs concerned facial expressions to automatically drill down into the database.
• The Redundanator5000™ - A sentient service management system which monitors Twitter for emerging service demands - and designs and deploys new web services without human intervention or human error.
• Solar-powered TCP/IP helmets turning people into thought-crowdsourcing internet nodes.
• Edible hardware makes upgrades something to look forward to.
• Mechanical pterodactyls automatically deployed to deliver cup-and-string-based communication solutions at short notice as a workaround for when VOIP and video-conferencing facilities fail.
• Bruce Lee clone robots police the IT infrastructure to make sure servers don't get 'out of line'.

"What do you mean 'Fatal error in disk mode'?  I'll tear you another A drive!"

Contributions to IT 4.0 invited as comments.

The ITIL glossary needs a defibrillator

In an earlier post I highlighted the fact that ITIL-speak is not aligned with customer terminology.  Now I want to take this a bit further and say that ITIL-speak isn’t even aligned with common IT speak.

IT has a natural language of its own that varies slightly from organization to organization.  To a certain extent, ITIL has tried to go against this in the name of standardization.  Adoption of a global terminology standard benefits the industry as a whole, but does it benefit an individual organization which has already settled on terminology that is understood clearly within the organization?  Naturally, it is very difficult to get people to adopt new terminology in place of a lexicon that has become established over many years, so there are major cultural change issues involved in throwing out something that works for the sake of standardizing with the outside world.  People will not get behind such an initiative because they will not see any value in it – only disruption – which is a fair point.  Standards that don’t bring real benefits to the individual organization fail to take hold.

• IT Manager: "We're calling it X instead of Y now"
• Techie: “Why is that word better than this one?”
• IT Manager: “Because it’s the standard”
• Techie: “Not in this organization it isn’t!”

Indeed, the ITIL glossary is far too cumbersome, with the ITIL V3 Glossary running up a total of 58 pages, there will be few people on the planet who have digested and assumed the entire ITIL dictionary.  Thus, we can never expect mainstream adoption whilst the effort required is so great.  Perhaps terminology should be chopped up into chunks and associated with different processes or maturity levels so that it can be adopted in a focused manner.  After all, there would be little benefit in force-feeding your IT department terminology that applies to processes which are outside the ITSM roadmap.  Once again we find ourselves back in the position of looking things in terms of what is of practical value to us, right now.

 "Mr ITIL, tear down this wall."

To simplify ITIL terminology, each process should have a surrounding cluster of terminology, indicating the standard terminology that is commonly used in the strategic and day-to-day management of that process, including the ITIL, IT and business/customer terminology – and how one maps to another so that it actually helps develop understanding and communication in real life.  This would allow organizations to select a standard set of terminology, but one that fits the context of their own business.

• Customer: “I’ve got a problem with my printer”
• Service Desk Analyst: “Actually, Sir - I think you mean you’re having an Incident.  It will be a Problem when we create a Problem record in our ITSM tool.”
• Customer: “@&#? #$*!”

Organizations that think a change in dialect is going to fix IT won’t make much progress.  It’s about adopting the ideas behind the words, not just the words themselves.

Why anybody who attends a meeting with no agenda should be shot

As promised in my You might be an email junkie if... post, I've finally got round to an attack on corporate inconvenience #2 - meetings!

Many of you will be familiar with the problem.  If you don't think there is a problem, then maybe you ARE the problem.  Everybody sits somewhere on the 'love-meetings-hate-meetings' spectrum.  I personally dislike meetings.  Some people justify their existence with meetings, turning a 2 minute face-to-face into an expensive, hour long pow-wow with a dozen slightly confused people.

Why I don't like meetings

• Decision by committee is rarely productive.  People have roles and responsibilities for a reason.
• No agenda means no direction, too many tangents and a lot of yawning.
• Granularity.  Obsession with working out all of the minutiae in the meeting.  A 30 minute meeting become a 3 hour meeting.
• Value for money.  Multiply the number of attendees by a ballpark hourly rate by the number of hours spent in the meeting to calculate cost.  Would you show the figure to your boss?
• Failure to set action points makes the whole thing worthless.
• Opportunity cost.  What could you be doing if you weren't in that meeting?
• Mobile devices.  Ban them.  If you need to have a meeting, the spirit should be present, not just the body.

Someone once emailed Chuck Norris about a mandatory CMMI meeting. Chuck Norris emailed a blank reply with no subject and one attachment… a roundhouse kick to the face.

Solutions

• Ask if a meeting is really the answer to the problem?  Many problems can be solved by individual face-to-face interactions.
• Refuse to attend meetings with no agenda (emergency CAB meetings and a few others excepted as these have an implied agenda). Commit to using the 'decline' button more.
• The staff or systems which manage room bookings should reject bookings without an accompanying agenda. No agenda = no meeting.
• Use a money clock to easily identify cost and maintain focus.
• Assign actions - clearly.
• Take minutes, distribute and use them.
• Ask if the meeting was worth it.
• Management should run spot checks - examining the agenda, attendee list, minutes, action points, costs and results.  5 minutes every month can keep meetings from regularly spiralling out of control.

Of course, because life is never simple, there are always exceptions.

IT S.W.O.T. Analysis

(Click to enlarge)

More ITIL-Bashing - Institutionalised IT-speak

ITIL-bashing seems to be reaching fever-pitch, so I’m going to throw in a personal gripe – ITIL-speak.  Terminology is one of the few prescriptive elements of ITIL, and although it is useful to have a common lexicon to aid communication, this only helps communication within IT - not between IT and the business users.  IT bods have real problems translating IT-speak, which is riddled with TLAs and long-winded geekery, into language that the business understands.

"Quit your ITIL jibber-jabber!"

I'll give you an example:

Service Request

ITIL-Speak:

• Service Request (ITILv3):    [Service Operation] A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

Customer-Speak:

• I need something new from you

Incident

ITIL-Speak:

• Incident: [Service Operation] An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example Failure of one disk from a mirror set.

Customer-Speak:

• There's something wrong with the thing I have.

However...
Despite the trend for ITIL-bashing, I find myself stepping in to defend it.  Yes, there are problems, but it is the best we have got at the moment.  It doesn't need to die, only to evolve.  I still believe that an expert-moderated ITIL wiki would provide the best platform for ITIL to realise its potential.  When will that be?  That will be the day the ITIL consulting industry dies.

Availability Management: Get rid of the 'nines' and bring in the $$$s.

Availability management is at the core of customer satisfaction.  Without availability, no service is delivered and there is no service revenue.  However, due to the continuous changes in patterns of service consumption, the bottom-line business impact of service downtime ('unavailability' is not a word) will vary from one instance to the next, according to the volume of demand that has not been met, and the value of that demand - after all, not all customers are equal.

IT organizations need to define how service availability translates into revenue.  Availability has become a critical business metric that IT can use to improve service provision and drive increased revenue, particularly for ‘clicks-and-mortar’ e-commerce organizations where downtime equals lots of lost revenue.  Although availability management isn’t the most glamorous corner of IT, from the user perspective it is a key influence on customer satisfaction and thus business success.  If a service is not available, revenue will be lost, the brand will sustain damage and customers will look for other service providers.  Your competitors are only a mouse-click away, so customer loyalty is lost far more easily than ever before.

Why availability is a problem
Many IT organizations are still device-oriented departments, fixated with system uptime as the key availability metric.  These have a grand total of zero relevance to the business. For IT, a ‘five nines’ availability metric (99.999% uptime) may be seen as quite an achievement (about 5 minutes downtime a year), but if that 5 minutes of downtime falls right in the middle of the busiest business period of the year, the direct impact (lost revenue) and indirect impact (brand damage and customer attrition) is likely to be job-threatening.  IT managers who let this happen will have to answer tough questions on why IT wasn’t ready.  IT managers need to understand that downtime is not random, nor does it have a uniform cost every time it strikes.

The Nines - Crap film, crap IT metric

Work from the top down
In the ITIL 3 process map, Availability Management quite rightly sits in the Service Design Processes group, indicating that it is a critical part of the process of designing a service.  Designing high availability into a service is a good start, but there is always a threat of downtime during the operation of the service coming from external factors.  Downtime is always caused by a change of some sort - either a haphazard change applied by the service provider which has impacted the service in an unforeseen manner, or a change in the pattern of service consumption that has resulted in an overload.  Thus, the business needs to be aware of IT changes so they can veto badly timed changes, and IT needs to be made aware of marketing activity that will drive spikes in demand so that they can plan for capacity to meet demand.

Take a holistic approach to ITSM and avoid a world of pain

The Incremental Approach to ITIL

Many organizations want to improve on the cost, quality and agility of their IT service provision by implementing ITIL best practices, but this often seems like a daunting prospect.  As is often the case, the burning question is – how do we start?

You can’t boil the ocean.  Tackling 10 processes simultaneously is prohibitively complex and almost certainly doomed to failure, so the default roadmap to ITIL nirvana is to slice it up process-by-process, selecting the most urgent process (or couple of processes) for improvement first and finding a tool to that supports.  This strategy makes good sense in principle and outputs a rather smart roadmap chopped up into manageable, bite-size chunks. However, there are two major pitfalls with this process-based approach:

• It draws organizations into a web of integrations and upgrade problems as an incremental approach to procurement is assumed by default.
• It ignores the fact that it isn’t 100% of a single process that would bring the most immediate value, but selected elements of multiple processes – to create a ‘thread’ of value across ITIL.

Turn to page one of your ITIL roadmap and the focus may be on applying service desk automation or a solid change management process, but are you giving consideration to the last item in the roadmap?  Vendor evaluation tends to work on a very narrow “what we need now” basis.  If you need a service desk tool, you need a service desk tool, so go out and buy one that fits your needs.  Makes sense so far.  But turn to page two in the roadmap and change management is the next priority.  Does your service desk vendor supply an adequate change management tool?  No?  Then you’re looking at another vendor evaluation cycle.

The vendor evaluation cycle

Integrating two incident and change management tools may not involve a great deal of effort, but each time an additional module is added in line with the roadmap, the cost of integration is multiplied and the pitfalls of integration become all too apparent.  Each stage in the roadmap will be affected by delays, costs and risks.  Implementation is delayed by vendor evaluation.  Integration is often complex and requires expensive consultant time.  Risk of failure is high.

Oops! You failed to plan and fell into the Incremental ITIL trap.

The Holistic Approach

Individual ITIL processes don’t exist in a vacuum.  The greatest value to be gained from the ITIL framework comes from the interconnected nature of the processes.  Much of this comes from the sharing of data across processes (e.g. CMDB).  Implement one process in full and there is no data sharing.  Implement elements of Incident, Problem, Change, Release and Config and you’re leveraging that data five times over.

By slicing ITIL horizontally and tackling the must-have elements, irrespective of which ITIL guidelines they are associated with, you can create a thread of value that spans across ITIL and takes advantage of this leveraging.  Instead of taking a short-term view and putting 100% of your resources into an ‘ideal world’ Incident Management strategy, there is more to be gained by distributing efforts and tackling the must-haves for quick wins, wherever they might lie. This ‘long thin thread’ forms a solid starting platform from which you can get quick results, demonstrate the value of ITIL in action, justify further investment and develop your roadmap in a safe, stable manner.

At a lower level, there are strategies for ensuring a smooth roll-out of your ITIL roadmap.  For example, look at the information you will need to capture to run process.  By standardizing the information stored at an early stage you can avoid administrative issues later on.  A broader view of the specific data requirements can help avoid later projects to realign.  It’s a lesson that organizations often learn in hindsight and one of the areas where a consultant can really help out.

Holistic ITIL gets the "Pareto Middle-Distance Stare of Approval"

Planning is, as ever, critical to enabling this holistic path to value.  Work out what you need now, but also look at what you want in the long term from your ITSM strategy.  Having a 3-5 year view may not be of great use to you now, but it can certainly help avoid some of the many pitfalls in the future.  Factor this into your vendor selection and you stand a better chance of supporting your long term goals without getting stuck in a quagmire of integrations projects, upgrade paths and administration overheads.  Evaluating toolsets against how they can support your extended roadmap is the key to avoiding many of these problems in the future.  How many vendors do you need to work with to enable your plan?  Fewer vendors means fewer of the issues that plague enterprise IT solutions initiatives.  Selecting a vendor with comprehensive support for ITIL processes can mean that you don’t get the best-fit for each one, but it’s unlikely that your ITSM needs vary more than 20% from any other organization in the same industry vertical and gaining 80% of the value from 6 processes is better than 99% from just one.

Remember, ITIL is a means to an end.  Don’t just focus on applying ITIL.  Go for breadth, instead of depth, to leverage process overlap and interconnectivity.  Focus on the parts of ITIL that are of value to you and prioritize them in terms of value to the business as a whole.  In these days of economic flux, IT needs to be seen as an asset to the business.

Cloud Nonsense - A Collection of Cloud Computing Faff

The trend for bad cloud metaphors has been going on for some time now.  Thankfully it seems to be running out of steam and the wave of cloudmania has hopefully broken.

Bad Cloud Metaphors

• Storm warning for cloud computing 
• Lightning Talk: Crunchy Cloud Computing (???!)
• The Fog over the Grimpen Mire: Cloud Computing and the Law
• Cloud computing - Storm clouds or is it smooth flying? 
• Above the Clouds: A Berkely View of Cloud Computing 
• Cloud Computing: Overcast and Spreading Gradually 
• Cloud computing faces an overcast future before skies will clear 
• Partly Cloudy - Blue-Sky Thinking About Cloud Computing 
• The Dark Side of the Cloud 
• If the Clouds Burst 
• Clearing The Air On Cloud 
• Cloud computing promises a rainbow of benefits
• Not Every Cloud has a Silver Lining
• Lightning strikes Dublin cloud computing

 "Don't you dare associate me with this nonsense!"

Winner of the Cloud Nonsense Award 2011

Cloud computing can cause rain and land the poor villager in jail

This is a direct quote:

"Cloud computing is unreliable in a storm; if it rains, the data might get washed away. Information stored in mobile phones leaches into the phone’s battery and stays there even if the SIM is destroyed. Whatever you say hangs in the air around you for an hour, and can be sucked into recording machines and played back."

Priceless.