[Sticky] Link to the YouTube video of the 'fundamentals' part of my 2024 talks on insights into the digital revolution. About how the IT revolution provides reliable performance, but the price paid is less agility (IT is brittle and thus ever more It becomes ever more difficult to change). About how we humans react/have reacted to this and why 'Complexity Crunch' and not a 'Singularity Point' is coming. Also contains links to related posts on the site for those that rather read than watch..
Category: Management and Organisation
Can we break through the inertia that plagues IT-change?
You’re on the Titanic. The engineers are shouting: “The bulkheads are too low! The rudder is too small! There aren’t enough life boats!”. The sailors mumble: “It has been cold, there will be many more icebergs than usual and further south”. The owners are pressing the captain: “You should be in New York in six days, we desperately need a record!”. And the captain thinks: “I have execution power. I can break through. I will be successful.” and orders: “Northerly course and full steam ahead!”. Move fast and break things…
Like we don’t see air, we don’t see the Digital Revolution
Fundamental properties of digital IT have set ons on a road not to a Singularity Point, but towards Complexity Crunch. That has consequences for our strategic (IT) choices and landscapes. A ‘long read’ (sorry) about lessons we can learn by now after half a century of Digital Revolution so far. Written as I have been giving talks about the subject this pas half year.
No-IT. Really. No. I. T.
What happens when your organisation suddenly loses all of its IT? There are enough realistic ways for that to happen. Think: a really successful ransomware attack. As it turns out, first turning ourselves into 'digital organisations', and then requiring a speedy recovery from 'digital armageddon' creates a weapons grade challenge. A story about 'Out-of-Systems', 'Out-of-Sync', and your 'Minimal Viable Organisation' (MVO), and a 'fix' that may only make matters worse.
Don’t forget all the things that a core team performs to a tee, but that you never see
The third 'fragmentation wave' of the IT-revolution is upon us, it seems. Fragmentation/encapsulation is a repeated pattern in the IT-revolution for managing complexity. First as object oriented programming (for code) and later as agile (for IT landscape change). Now, it is the organisation’s turn to fragment. How strong is your mission, your ‘why’? You might soon find out, thanks to IT.
Eyes that glaze over. Eyes like saucers. Eyes that narrow.
When (new) technology is concerned, I observe that there are three types of people involved. Those whose eyes 'glaze over'. Those whose eyes become like saucers. Those whose eyes narrow. Who should be the advisor of the decision makers?
The Other Side of Requirements
We tend to think of requirements as 'incoming' elements for our designs. But what we not always explicitly notice is that we also create many 'outgoing' requirements in our designs, often in the form of 'constraints' of the 'users' of the products that come from those designs. These requirements lead a hidden existence most of the time, and that invisibility makes our decision making sometimes less efficient. What if we would make our outgoing requirements explicit? And how could we manage this? For that I created an actual small demo solution to manage solution designs in a library that links them and the requirements they give to each other, built as a plugin for Confluence.
Definition of Ready, Done? What about a ‘Definition of Broken’?
As the IT world has been largely taken over by Agile methods, the concepts of Definition of Ready and Definition of Done have become mainstream. While these concepts were introduced at the story/sprint level in Scrum, they have taken on a wide role and are generally used at all levels these days, not just on stories, but also on features and epics, the larger items in the agile-tree. There is, however, a new concept that maybe very helpful at the higher levels that we might use: a Definition of Broken.
The lack of use cases for blockchain should teach organisations a valuable lesson about handling hypes
If someone tries to get you to invest in some shiny new technology — like blockchain 5-8 years ago — beware. How do you judge these proposals? A realistic use case is key.
Follow-Up: The missing element of ‘Sunshine’ Life Cycle Management
A useful addition to the original concept of Sunshine-Life Cycle Management to help managing it all.
R&A IT Strategy & Architecture 