Most people go their whole lives without encountering a Target Operating Model (TOM). If you are one of the unlucky few who have to work on a TOM this post provides some hints and tips. I hope it will help you survive the experience and even get something useful out of it. Enormous amounts of money and energy go into TOMs so we should get more value out than we put in.
I gave a presentation at the recent British Computer Society (BCS) Enterprise Architecture Conference. A replay of the talk is available and this post is an outline of the main points. Over the last few years I have worked with many architects and quite a few are unhappy. Executives might appreciate the efforts that go into models and designs but things move on so quickly that, often, the architect’s work does not keep pace with events or arrives too late to be useful. The architect might sadly slope away, loaded down with copies of densely packed designs which are now only good for the recycling bin, or they might become angry at being ignored. Either way, it is not a pleasant situation. I shared with the conference some ideas about why this is happening and offered some suggestions of how to respond.
I recently read a really nice post by Drew Firment (thanks go to Chis Swan for sharing it). Drew’s article reminded me of some patterns I have seen in big transformations - most recently in my digital transformation work but also in the earlier rounds of change we called internet- or electronic-business transformation. This post is a first attempt at making these patterns explicit, initially so I can use them in my own work. It would be great to get your feedback if you think they will help you too. Lots of other people have already been trying to make sense of this area through frameworks, maturity models, life-cycles and other models. I have started to collect a list of some of these at the end of this post and they are worth reviewing as well.
I recently noticed that I have been using @CIOPortfolio for 5 years now and that got me thinking about what has changed for CIOs over that time. Although digital technology is renowned for its frenetic pace of innovation (here we go again!) you could argue that not much has changed. Surprisingly, that is a terrifically useful insight for CIOs.
You could be forgiven for thinking that the agile movement is taking over the world. For example, Amazon is famously agile and because it can make changes to its software every second it can maintain its lead in existing markets whilst conquering new ones. But look more carefully and, of course, things are more complicated than that. In many respects, leading digital businesses are not as agile as they seem.
Despite being pronounced dead a few times the Chief Digital Officer (CDO) role still seems to be going strong. Unfortunately, it is quite hard to tell if this resilience is down to the merits of the role or just mislabelling. These days, people have a tendency to add “digital” to quite ordinary things to make them sound more exciting and special - the letter “e” used to have the same magical effect, as in E-Business. For example, a recent poll by @marthaheller asked CIO’s where they thought the digital department should reside - the results are above. It seems unlikely that Martha’s followers had a common idea about what a digital department was for. In order to help, here is my digital department field guide. Are there any species of digital that I have missed?
I am often amused by the heated debates about the future, or not, of the CIO. The fun comes from the combination of intense emotions, arguments heroically generalised from limited data and the dismissal of evidence which does not fit preconceived ideas. Before I attempt to set out my views on the role of the CIO let me try to eliminate some of the noise and confusion. Is the CIO really that unique?
Bluesky
