The Pebble and I work well together.
But he is an Arts graduate, so I have to humour him from time to time.
This entails having to listen every so often to one of his "stories" about history or politics.
Today, for some reason, he decided to explain why the Red Army initially collapsed during the German invasion of Russia during 1941.
"Barbarossa", "Lebensraum", "OKW", "Timoshenko", "Smolensk", "Stavka"...
The Pebble often talks about interesting things but occasionally he uses too much terminology. As is sometimes the case, after a few minutes I felt my eyes glazing over. My mind started to drift into that strange state where you feel conscious and unconscious at the same time. The lights were on, but there was definitely nobody home.
His talk about matters military must have had some impact though. Through the haze I began asking myself - when did IT last go into battle with a genuine understanding of what the business was trying to do?
When did Business and IT last plan together strategically, agree tactics, and march together with clear objectives?
How about ten years ago...?
If we think back, the strategic objective was to locate and destroy all of those date fields containing only two year digits which would cause mayhem and havoc if they weren't fixed as the calendars changed to the Year 2000. In most large organisations this was done with the kind of precision you usually find only on the parade ground.
But the "War on Y2K" didn't just consist of programmers fighting on the front line to remediate code. Business Continuity and Contingency Planning were used as a rear guard action to ensure that if any of those little bugs made it across No Man's Land there was a mechanism in place to neutralise their effect on the business.
The often forgotten skills of the Systems Analyst were called upon once more. They became the "embedded journalists" within the business, reporting back in meticulous detail the inputs and outputs to the systems.
The Analysts mapped out how IT systems were used throughout all parts of the business, and how information was passed from department to department. (What I call the flow of data ).
New systems were developed, old systems were remediated, command and control buildings were established, and paper based systems were put in place just in-case the worst should happen. This was achievable only because, for the first time and at considerable expense, the relationships between business processes and the portfolio of deployed assets were investigated, catalogued and analysed. Capturing these relationships was key to planning disaster recovery, business continuity, contingency planning et al.
The current talk in ITIL v3 about maintaining similar catalogues of business services and technology assets will go some way to enabling business processes optimisation, enterprise architecture, governance, SOX, compliance and alignment, to name just a few. The problem faced by business, however, is how to achieve this with the minimum number of casualties - that is, at a reasonable cost.
Y2K still divides opinion. Some people say that resources were sacrificed needlessly and it was another huge waste of money by the IT department to fix a non-existent problem of their own making. Others feel that it was unprecedented hype and scare-mongering by the media to fill column inches and TV schedules. Many who worked on the problems, however, believe the operation was a success and the lack of system failures was testament to them doing a fine job and fixing all of the problems.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.