A Framework for Reasoning with Technology

Architecture. The first image that comes to mind is probably a building. But pieces of code — the instructions that make up software — are also called "builds." Developers, routes, storage, architects, stacks. The more you understand the glossary of the digital world, the more you realise that despite being so abstract, it is a mirror of the physical one.

Modern physics has revealed that underneath the quantum level lies another level — a level from which space and time both emerge. That level is information. Perhaps this is why the dawn of the information age propelled our world to exponential heights. The question is: what made it so transformational?

The clue lies in what happened when humans began to not just collect information, but arrange and organise it effectively towards a single goal — to transform the environment that surrounded them and bend it to their will.

There is a pattern that manifests itself throughout human history as we sought to transform our environment. It is called Model-View-Controller. A horse-drawn cart is replaced by a diesel engine because humans began to think of information related to the model (transportation systems) as separate from the view (horse or engine) and the controller (coachman or driver).

This is a very effective way to reason about and articulate problems that address specific concerns, without having to dream up a completely new idea. Incremental improvements can be achieved by improving the Controller. Innovation can be achieved by changing the View. And radical rethinking can be achieved by changing the Model.

Better transportation time can be achieved by getting a better coachman — that's a controller improvement. Unthinkably better times can be achieved by replacing the horse with an engine — that's a view change. And entire societies are transformed when you can make a car appear by pressing two buttons in the palm of your hand — that's a model change.

This framework is not limited to technology. Consider it through the lens of what we do at Design Execution — consumer products and category strategy:

This is precisely the framework that explains the story we explored in our founding thesis. A global consumer goods organisation spent decades improving the controller — better testing protocols, tighter Descriptive Analysis, more efficient experimental design. What they failed to do was change the model. They never asked whether the consumer they were optimising for was the right consumer to begin with.

For those who build in the digital world, the MVC pattern is structural. The View is what renders on your screen — HTML for layout, CSS for styling, JavaScript for interactivity. Front-end developers work here. User Interface Designers architect here.

The Model is structured data — records arranged in databases, whether relational (tables, rows, columns — MySQL, PostgreSQL) or non-relational (documents, key-value stores — MongoDB, Redis). The model represents the data. It does nothing else. It does not depend on the controller or the view.

The Controller ties the model to the view. It contains the logic — the routes, the queries, the business rules that determine what data gets fetched and how it gets presented. Information architects and UX designers provide the inputs that shape these routes.

Consider a physical analogy. A clerk at an auto parts warehouse looks up brake pads for a 1992 Honda Civic. The view is the physical part. The model is the part as a component of the warehouse inventory. The controller is the clerk — the logic that connects a customer query to a data source and returns a result. A second clerk at the cash register is a different controller: given the same model, they render a different view — the price.

In the digital world, this translates directly. A search field is a view. Clicking "Search" passes the query to a controller, which finds the matching model, ties it to a new view — the results page — and returns it. The user selects a result, and a different controller renders yet another view: price, shipping, tax. Many controllers tying models to different views. Each view arising from a need identified in the physical world.

Most technologists look at Model-View-Controller as a mere pattern or an architecture. But it has a more powerful purpose. It provides a fundamental way to reason about technology — and about any system where information, experience, and logic intersect.

At Design Execution, we work across all three layers. We improve controllers — better experimental protocols, tighter statistical design. We innovate views — new formats, new product experiences, new ways of presenting data to decision-makers. And when the opportunity calls for it, we change the model — redefining who the consumer is, what they want, and why the current approach to finding out is fundamentally insufficient.

The boring work is controller improvement. The exciting work is view innovation. The transformational work is model change. Knowing which layer you're operating on is the difference between incremental gains and category creation.