Tom Graves from Tetradian has just posted a wonderfully elegant thought on LinkedIn, which I include below. He is a leading thinker in the fields of business and enterprise architecture – fields that overlap a good deal with operating models.

“What is architecture? What do we do in architecture? And how do we do it?

Turns out that it’s essentially the same for every kind of architecture: enterprise-architecture, solutions-architecture, software-architecture, building-architecture, naval-architecture, brand-architecture, whatever.

Right down at the root, in principle, architecture is incredibly simple. It all comes down to just one idea, one aim: that things work better when everything works together, on purpose.”

I love simplicity. But, I don’t think that the sentence in italics is quite complete. Building on Tom’s insight, I have added a thought: Things work better when everything works together for a purpose, on purpose.

“On purpose” means that we have made design choices with the intention of ensuring that “everything works together”. The reason why the sentence also needs the phrase “for a purpose” is because we only need everything to work together if we are trying to get something done efficiently. So the start point of all architecture and all operating model work is clarity about what we are trying to do – the purpose.

In my approach to operating model work this clarity involves defining three things: for whom are you trying to do something (the customer), what is it that you are trying to do for the customer (the product or service) and what activity do you believe you need to do particularly well in order to create value for the customer. These three elements are written in the singular: customer, product and activity. But in most cases operating model design work involves multiple customer types, multiple products or services and multiple special areas of needed competence.

Hold onto the “working together… for a purpose, on purpose” thought, and you will not go far wrong. Start with clarity about who the customers are (not always obvious, especially with internal functional design) and what the organization is trying to do for these customers (often not clearly defined). Then lay out the work steps that need to be done to create the beneficial outcomes for the customers (the value chain or chains). Then identify which work steps it is most important to do brilliantly well. Then design everything towards this end, recognizing that it all needs to “work together”.

Of course, operating model design work is easy to describe, but difficult in practice. As Tom adds:

“What we end up with should be simple – or as simple as possible and practicable, anyway. But we often have to go through a lot of complexity before we arrive at that simplicity. People, processes, politics and petty feuds, technology, temper-tantrums, structure, story, hopes, fears, wishful-thinking, delusions, disasters, doubts, debt-collectors, nightmares of logic and logistics, lost-in-translation tangles, things that just don’t work, things that do work in surprising ways, and maybe a little bit of magic, too: successful architecture covers and copes with all of that, and more.”

If you keep the simplicity of what you are trying to do front of mind, and recognize that you will often be wrestling with dilemmas and constraints and difficult people and seemingly impossible contradictions, you will do great work.