- AI
- ambiguity
- APIs
- architecture
- augmented reality
- books
- bureaucracy
- career
- change
- Christmas
- cloud
- collaboration
- communication
- complexity
- computer history
- corporate life
- data
- decisions
- delivery
- devops
- end user tools
- ethics
- failure
- fear
- fundamentals
- gaming
- government
- halloween
- history
- humans
- hype
- identity
- infrastructure
- innovation
- language
- leadership
- learning
- legacy
- management
- measurement
- mental health
- money
- networking
- New Year
- operations
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- robotics
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- talent
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
The fox and the hedgehog
A fox knows many things, but a hedgehog knows one big thing.
I am sure that you have heard this saying before: it’s attributed to the Greek poet Archilochus, who lived in the 7th century BCE, so it’s been around for a while.
I think that this saying is useful in enterprise technology: we work in a field full of foxes (technology capable of doing many things) and hedgehogs (technology which is good at doing one big thing). It is often difficult to tell foxes and hedgehogs apart, especially when we are also surrounded by people who want to convince that their hedgehog is a fox: that it’s not just a great piece of technology that can solve one big problem, but that it can solve all our problems. If you have been working in the technology field for a while, then you will have seen several technologies and approaches promoted as the answer to everything, before they either faded away, or settled down into the life of happy hedgehogs (ESBs, anyone?).
Into the ever rising ocean of data
Data is, at the same time, the most mundane and most exciting aspect of computing.
It is mundane because of its origins in the world of folders and filing cabinets. In my first ever paid programming job, for a government department in the 1980s, the team I was part of was not called Information Technology (and certainly not Digital), but Automated Data Processing. And, while I was thrilled to get paid for writing code, the work we were doing was about as exciting as that title implies: we were doing the computing equivalent of shoveling coal from one pile to another (or moving records from one file to another). All of the data we were working already existed, in written paper records, in printed documents or even on micro-fiche. By creating Automated Data Processing systems, we were enabling data to be processed with greater speed and accuracy - but we were not creating new data.
Based on some informal surveys, I think that most people who have not had the chance to work in technical jobs, still think of data in this way. When we press ‘send’ on our mobile banking app, we imagine that the work that computers are doing is similar to the work that clerks would have done with printed ledgers many years ago: the data is hauled up from the memory of the computer, the number is read and sent out, some amendments may be made, and the data is sent back to its quiet resting place.
Cloud transformation: don’t stop at the foundations
Over twenty years ago, I was working in Canary Wharf when the next set of towers after 1 Canada Square started to be built. I had the opportunity to watch the foundations of new buildings being laid, and to see the surprising contrast between the amount of time it took to lay those foundations, and the speed with which the new buildings climbed to the sky. For months it seemed that nothing was happening - but that ‘nothing’ was what made the rest of the building possible.
In Cloud transformation, we usually start by building foundations: basic concepts and constructs such as landing zones, tools and security policies, accompanied by essential training, and proven by pilot workloads. This first phase can be difficult, as it requires you to make some of your most important choices and do some of your most important work at the time when you have least experience and capacity. As with any profound change, you will experience setbacks and surprises as well as success, and you will need to adapt your plan. It is also wise to seek help.
From the data lake to the front page of data
How many times have you tried to build a data lake? Or, to put it another way, how many times have you tried to solve the analytics problem? I have to confess that I have tried more than once - and had varying success, until I learnt to think about the problem differently.
The problem is familiar: our enterprise has data which we believe to have value; that data is sitting in systems of record which are hard to access; those systems sit on infrastructure which is optimised for transactions rather than analytics.
We also have solutions which are familiar, even if they have taken different forms over the years: we pull the data out of our systems of record; we organise it into a form which is easier to analyse; and we place it on infrastructure which is optimised for analytics.
Thinking differently about . . . data
One of the first tools I used in my programming career was something that we would barely recognise as a tool today: it wasn’t a testing tool, or a deployment tool, or even a compiler. It was a physical rubber stamp used to create a variant of something called a Bachman diagram: a representation of an ICL IDMSX database structure. You used the stamp to create boxes that represented record types, and then filled in name and other characteristics in ink.
I share this story not just out of nostalgia (although I am sure that this will bring back memories for many people), but to illustrate just how differently we must think about data today than thirty years ago - and to remind us that, for many of us in senior technology leadership positions, we acquired skills, beliefs and habits in a world very different to that of today.