This is the first DevOps post on make10louder. DevOps is a way to develop and run software that removes organisational boundaries and shares tools and culture.
DevOps is similar to a marketing and sales department working closely with factory operations to make sure the factory can build and deliver what the customer wants.
This post looks at the different types of work in building and running software. I’ll suggest organisational metaphors reveal useful insight into DevOps; removing the boundaries between development and operations, and delivering value to customers. We can work better from understanding all the perspectives these metaphors give us.
Gareth Morgan’s Organisational Metaphors
The organisational metaphors I’m using are from Gareth Morgan’s Images of Organisation. (This book referenced by Microservices Architecture , coaches, Open University MSc courses, and ribbonfarm.com).
There are eight metaphors; Machine, Organism, Brain, Culture, Political System, Psychic Prison, Change and Flux and Instrument of Domination. All the metaphors can be true at the same time. People are likely to favour a dominant metaphor in their understanding of the organisation. This means the organisation will be working in ways they cannot see.
The metaphors that I think Devs Ops uses are:
- Organisations as Machines
- with known input they should produce identical output
- ideally ‘well oiled’
- People as interchangeable cogs, once trained or certified
- Input, process, output.
- reducing variation
- A leads to B leads to C.
- Organisations as Brains
- Who knows what
- How information spreads
- Constant learning through feedback, and learning to learn
- Viable Systems and management cybernetics
- Organisations as Organisms
- Adapting to the variety of a changing environment
- Evolving an organisational DNA
- Having a survival strategy
- the best fit with the environment survives
- Organisations as Cultures
- The way we do things here
- Value Systems
- Norms and Patterns of Behaviour
- Dominant cultures and sub-cultures
I don’t see DevOps best practices covering:
- Organisations as Political Systems
- Organisations as Psychic Prisons
- Organisations as Instruments of Domination
There are some useful lessons looking at real world problems through these lenses, that I will leave to another post.
Metaphors in a DevOps World
#1 Computers are actually Machines
This is not even metaphorical. Don’t configure computers by hand. Person A should not configure a computer better than person B. Computers are often still treated like they need configuration by a wizard.
DevOps insists we treat computers like machines, configured accurately by other computers by running code.
This gives us to easily replicate systems, and have reassurances that if something is wrong it’s not because the wrong wizard configured them.
We treat monitoring metrics in the same way. Automate and get data on all the things.
#2 Processes are machine-like, but controlled by Brains influenced by Culture, in a complex unknowable future environment.
We design our process to run smoothly and they’re automated where possible. We have a strong culture of doing the right thing when things go wrong and we learn from our mistakes. With double loop learning we also ask ‘is this still the right thing to do?’
#3 People are not Machines
People are a complex combination of all eight metaphors.
In a DevOps people are give time to learn and apply their knowledge safely. They are given the tools they need and trust to know how to best use them without involving centralised experts. We encourage a culture of experimentation, honesty, shared ownership of problems and customer focus. Machines cannot do these things.
#4 The value created by software can be seen as the output of a machine
The output as seen by the customer is the number one priority. Customers don’t care how parts of the value stream are working. They care about the output of the entire system, and internal optimizations can have negative consequences. Systems Thinking 101.
#5 Working Software is a machine, used by People, in a changing environment
Software, like the computers it runs on is literally a complicated machine. Although software may behave in ways we don’t understand, without AI, it’s knowable and predictable. It may still be incredibly complicated, but it’s theoretically understandable in advance if the starting point, context and inputs are known.
Problems arise when people use the software. We can start to understood people using the metaphors of brains, culture, organisms and a healthy dose of biases via psychic prisons.
We should automate as much of the machine part of software as we can, in the knowledge that the needs of the people using it will take all of our attention.
We can’t automate software development, but using Agile methodologies to move bits of functionality from customers heads into predictable code, we’re riding a flux and change metaphor.
DevOps Metaphors in a Nutshell
Computers are machines. Build them with code, don’t craft them by hand.
Processes are designed and improved like machines, but in the knowledge that bad stuff will happen. Culture will help you do the right thing when it does, and brains will help your organisation improve. As an organism you need to adapt to a changing environment. Today’s solutions are tomorrows problems.
People and Teams can learn and adapt, but can also follow anti patterns. All the Organisation Metaphors help here. Metaphors of Political Systems and Psychic Prisons (think Cognitive biases) may also help diagnose issues where you’re following good practice, but things still are not working.
Software works like a machine in a complex environment including people, and all of their metaphorical ways of seeing and acting. Crossing this chasm is the work of developers often aligned to the agile manifesto. The use a dominant metaphor of flux and change, but produce software that has a repeatable output.
Conclusion, and So What?
Organisation metaphors reassure us we’re looking at the right things and show us how we can more fully understand situations.
DevOps is a mixture of theory and sound practical experience. Metaphorical insight can help us.