- 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
- partnership
- philosophy
- physics
- platforms
- prediction
- process
- procurement
- programming
- quantum
- reliability
- resilience
- risk
- science
- science fiction
- security
- shadow IT
- space
- standards
- strategy
- teaching
- teams
- technical debt
- technology advocacy
- testing
- thinking
- transformation
- TV
- virtues
- vision
- writing
Keeping the lights on
Do you have a line in your IT budget which says something like ‘keep the lights on’ or ‘keep the show on the road’, or ‘maintenance’ or ‘support’ - or even just ‘run?.
Over the years, I have put together IT budgets with at least one of these lines in. They’re a convenient way of signalling to finance people, hovering over their printouts and spreadsheets, ready to wield the red pen or press the delete key, that they’d better not strike out this item. They don’t have to understand technology to understand that, without this money, something will break. They’ll probably ask us to swallow inflation, or to trim around the edges, but they’re unlikely to cancel it altogether.
While this arrangement can be convenient (the IT department gets its money; the finance department does not have to understand technology), I do not believe that it is healthy or helpful. I believe that we would do a better job if we explained exactly what we spend this money on, why it matters, and why it gets more complex and more difficult every year.
Conway’s law: power, money, capability and the duty to explain
Conway’s law is one of those, ‘Of course!’ concepts: a concept where, the first time you hear it, you say, ‘Of course!’ It reveals something which you always suspected about the world, but couldn’t quite put into words.
Conway’s law answers the question, ‘why are so many computer systems so strangely organised?’, with the idea that the structure of systems follows the structure of the teams that build them. Melvin Conway didn’t quite put it like that in 1967: he said, ‘Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure.’ (If you haven’t heard of Conway’s law before, but have encountered many strangely designed computer systems, you may be experiencing your own, ‘Of course!’ moment.)
The human path to legacy modernisation
‘We just need to change the funding model.’
I heard that phrase many times when leading architecture teams, and it always made my heart sink.
It was normally said with good intent by architects who were working on a problem which required long term, multi-year investment to build shared assets. Unfortunately, resources (money, people, leadership attention) were allocated to meet the focused needs of business divisions, rather than to create enterprise capabilities. Hence the lament that, if only we could change the funding model, we could give the enterprise the architecture that it really needed.
From design conflict to design harmony on cloud
The dome of St Paul’s is an iconic part of the London skyline: it’s instantly recognisable, and can be seen from far away.
What’s harder to see, though, is that the famous building is also a famous architectural compromise. Sir Christopher Wren’s original plan was for a floorplan shaped like a symmetrical cross, in line with the classical inspiration for his design. The clergy disagreed, though, and insisted on the more traditional layout for an English church, with an extended nave. As a result, we have a classical dome on top of a medieval floorplan.
Most design involves compromises like this: we have design goals (build a beautiful structure following classical ideals; demonstrate visual continuity with church tradition) which cannot be satisfied simultaneously, and we have to figure out which goals we will give priority to.
One of the things that attracts me to Cloud, though, is that design goals which have traditionally conflicted can be brought into harmony.