From punched cards to connected kettles

I’m a ‘big picture‘ person, something of a mixed blessing.  It means that while I’m pretty good at predicting and understanding the overall consequences of a complex set of actions and events, I’m actually pretty crap at explaining to most people why their excessive focus on specific detail is probably irrelevant in the grander scheme of things.

In the possibly misguided belief that ‘a picture is worth a thousand words’, over the course of my working life I developed what many of my colleagues doubtless saw as a Bad habit of doodling these ‘big pictures’ in PowerPoint.  To me, it seemed that any complex situation could be reduced to a single PowerPoint slide in much the same way that my mentor believed that ‘any worthwhile expedition can be planned on the back of an envelope’.

(If you’re a ‘detail thinker’, it might be wise to close this post right now!)

. . .

The slide below was drawn almost twenty years ago, triggered by a customer’s requirement to develop and maintain a common global web commerce site.  The picture is not exactly rocket science, its origins stretching back twenty years earlier to the days of pencil, paper and punched card.

The customer requirement was relatively straightforward;  build me a single, global system solution with a ‘front end’ translated into multiple local languages and a ‘ back end’ transacting business with international and local suppliers in their appropriate currencies.  (OK, so there were a few additional detail requirements for stock control, logistics, billing, product catalogue, customer reference etc., but none of this stuff should have been ‘new’.) Enabling an overview of business performance across the global estate presented another obvious level of corporate requirement and key to it all was the need to effectively and efficiently plan, deliver and support releases of business solutions capable of meeting foreseeable future global and local marketing initiatives.

The ‘Sales team’ had, as usual, already sold a flagship software product as the answer to a maiden’s prayer, blissfully ignoring the obvious fact that the stuff in the box covered only a fraction of the total picture.  On my first sight of the English language prototype in the harshness of a Canadian winter, I asked the question ‘how will this scale across the next two country implementations’.  The response, after a lengthy pause, was “we’ll build two further environments, modify and translate them”. Brilliant!  Three times the hardware revenue, three times the software revenue and yet more unplanned services cost.  No need to worry about the lack of a viable global solution, just look at how the projected revenues grow!

It was at this point that I sat at home in my study, dumping down the previous twenty years of global ADM experience into a single chart.   A few long evenings later, reaction to the finished slide was depressingly predictable:

  1. “This chart is unnecessarily complicated. We don’t need to consider this until we’ve delivered the first implementation” [Er… Are we missing something important?].
  2. “This chart represents a waterfall delivery approach and is therefore wrong. We have to use an agile approach.”  [Actually, the chart shows an iterative delivery process in a global environment. We could debate the issue of agility at length, but that’s for another day]
  3. “The software package we’ve sold doesn’t have multi-cultural support until ‘release n.1’.”  [Now that’s a terrific argument for selling more hardware and software and delivering an unmanageable solution]
  4. “Why have you been wasting your time drawing something that has no relevance whatsoever to the project?”  [Sadly, this was the predominant reaction]

. . .

If you’ve stuck with me this far, I have a question for you:

“Since the chart was as valid twenty years ago as it was forty years ago, is it still valid today?”

(You might want to click on it and apply maximum zoom)

My personal hypothesis is that since the overall process architecture for a global solution is independent of the tooling used, then it’s probably just as valid in this age of clouds and interconnected ‘things’.

. . .

Anyone still there, or am I just talking to the toaster?


Leave a Reply

Your email address will not be published. Required fields are marked *