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.