What learning the saxophone taught me about business architecture

Six years ago, with no musical training of any kind, I bought a saxophone.

I had always been drawn to the sound of it - the warmth, the expressiveness, the way it sits somewhere between a human voice and something entirely its own. I decided, at a point in my life when most people consider themselves too old to start something genuinely new, that I wanted to learn how to play.

Nobody warned me about the embouchure.

The embouchure is the position and tension of your lips, jaw, and facial muscles around the mouthpiece. Get it wrong and the note does not come out. Or it comes out as a squeak. Or as something that technically qualifies as a sound but bears no resemblance to music. The embouchure interacts with the reed - which must be the right strength for your lung capacity and technique - and with the intensity and control of your air release. All three must work together before a single note sounds the way a saxophone note is supposed to sound.

I spent a long time producing sounds that were not music.

What I did not understand at the beginning was that this was not a problem to be solved. It was a stage to be passed through. The embouchure, the reed, the breath: these had to become instinct before they could become invisible. There is no shortcut through that stage, no technique that bypasses it. You practise until the mechanics stop demanding your conscious attention. And then, eventually, you can start to play.

Six years in, I have moved through that stage. I have progressed from alto to tenor to soprano saxophone. I understand music theory, scales, and how to read a piece of music I have not heard before. I have learned from several teachers, each of whom showed me something the previous one had not.

And I am still not satisfied with my tonal quality.

That dissatisfaction is not failure. It is, I have come to understand, what genuine engagement with a craft looks like. You do not arrive. You develop a more refined sense of what better sounds like, and you keep moving toward it.

The foundations of business architecture - capability models, value streams, information models, operating model design - are the embouchure of the discipline. They must be learned. There is no way around them, and no honest shortcut through them. A practitioner who has not internalised these tools cannot do the work that requires them.

But internalising them is not the same as deploying them correctly. And this is where things get interesting.

For much of my early practice, I approached a business problem the way a beginner approaches a saxophone: I thought about the instrument first. A capability model here. A value stream there. The tools were what I had, so the tools were what I reached for. The Business Architecture Guild has long emphasised the capability model as central to the discipline’s practice, and I had absorbed that view completely. It was what a business architect did. So I did it.

There are contexts where that is exactly right. A new team with no shared language, an organisation that has never mapped its capabilities, a programme with no baseline to reason from - in those situations, starting with the model is not a reflex, it is a considered response to a genuine gap. The tool belongs at the front.

What I had not yet developed was the judgement to tell the difference. I was leading with the model not because the situation called for it, but because the methodology said to. That is a different thing entirely.

The moment it changed was not a single event. It was a gradual reorientation, accumulated across engagements and conversations and the slow accumulation of experience.

What changed was the sequence.

I stopped beginning with the architectural element and began with the business issue. I would listen - carefully, and for longer than felt comfortable - to how the problem was being described. Then I would sit with it. Ruminate on what the core issue actually was, beneath the language being used to describe it. Build an approach that addressed that issue, independent of any business architecture model.

And then - only then -I would consider which of the existing models would help me execute the approach.

The tools did not disappear. They became more useful, because they were now in service of a problem rather than in search of one. The capability model, when it appeared, was there because the situation called for it, not because the methodology required it.

That is the equivalent of the moment when you listen to a piece of music, pick up the saxophone, and it comes out. Not perfectly. But naturally. The mechanics have become sufficiently instinctive that the music can come through them.

I am still not a good enough saxophonist. I hear the gap between what I produce and what I am reaching for, and the gap is instructive — it tells me where the next work is.

I am a better business architect than I was ten years ago, and I expect to be a better one in ten years than I am now. The foundations are solid enough that I rarely think about them. What I think about is the problem in front of me, and which of my tools will serve it best.

That is not a destination. It is a way of working.

I am curious whether this resonates — whether you have had a similar moment in your own practice, in architecture or in any other discipline, where the tools stopped being the point and started being the means.