If you want teams to own architectural decisions responsibly, start by creating coherency around what architecture means in your organisation. Don't copy a definition from a textbook. Work together to define it for your teams, your systems, your context. Make it empirical.
Because you can't take ownership of something nobody can agree on the meaning of.
But we copy-pasted the structure without the part that makes engineering engineering: the empirical rigour. Where's our hypothesis-driven approach? We adopted the frameworks but skipped the scientific thinking underneath them. So it's not that we're doing too much engineering. It's that we're not doing enough of the right kind.
>>>
This connects to something broader. We've borrowed a lot from mechanical engineering as a discipline: the job titles, the frameworks, the processes. And that's fine. Borrowing from established disciplines is normal. Software is relatively new compared to mechanical engineering (the pyramids still stand!).
>>>
Right now, many organisations want teams to take ownership of their own architectural decisions. That's a good ambition. But if we haven't created a shared understanding of what architecture means in our context, we're setting teams up to fail. They might think they're making architectural decisions when they're really just making technology choices without considering the trade-offs that actually make it architecture.
>>>
Architecture is what we call in Dutch a "container word." Everyone fills it with their own meaning. And that's not just a semantic problem. It has real consequences.
>>>
38 answers. Almost all different. "Keep it simple stupid." "The foundation we lay to ensure our building doesn't crumble." "Intelligent design." "A system that works and make things work." "The inside of the black box." "Structure." "Everything in IT that is not hard wired."
That's when it gets interesting. Because if we can't agree on what architecture is, what does it mean when room full of people say they're highly involved in architectural decision making?
>>>
I recently asked a room of practitioners: "How much are you involved in architectural decision making?" The average was 7 out of 10.
Sounds good right?
Then I asked the same group: "What is software architecture?"
>>>
But before you worry about AI agents taking over your architecture decisions, maybe first ask: are the teams in your organisation actually allowed to make them?
#SoftwareArchitecture #OpenSystemsTheory #SociotechnicalSystems #AI
So if you want teams to make intentional architecture decisions, either centralise those decisions fully (DP1) so everyone knows where they stand, or do the actual work to move towards DP2 with clear boundaries. That second path takes time, safety, and behavioural change. The ghosts of systems past don't disappear overnight.
>>>
That's exactly what I see in my own work. A team takes a decision they believed was theirs to make, management overrules it without conversation, and trust erodes. The boundaries were never real.
>>>
