When I introduce myself as a software architect, many people nod politely, and their eyes say: "an expensive techie who draws boxes". That is an understandable reaction. A programmer's work is visible: he wrote code, a button appeared. A designer's work is visible: a beautiful screen appeared. An architect's work looks like conversations, diagrams and strange questions like "what happens if we get ten times more clients".
And yet I am convinced that a good architect is one of the most profitable people on a technical team. It is just that his contribution to profit shows not in a weekly report but in a report over years. And, worse still for his reputation, an architect's best work consists of problems that never happened.
A city built without a plan
Take two cities. The first grew on its own: people built wherever it was convenient, roads followed footpaths, sewers were added when things got really bad. The second was built from the start according to a master plan: main roads, districts, utilities with room for growth.
Twenty years later the first city has traffic jams, burst pipes, endless repairs and huge expenses for laying a new road through already built-up blocks. The second city has problems too, but they are solved an order of magnitude cheaper, because there is room planned for them.
A company's software system is its digital city. Orders, money and client data travel through it. If the city was built without an architect, every new change costs more than the last, and every failure hits neighbouring districts. Money leaks through cracks in the roads, and nobody can point to exactly where.
Where architecture turns into money
Speed of building new features. In a well-designed system a new feature can be added without touching half of the existing code. This is called modularity, and its economic meaning is simple: the team does more in the same time. I have seen systems where adding a new payment method took two days, and systems where the same task took two months because payment logic was smeared across forty files. The difference in development cost here is not in percent but in multiples.
Infrastructure costs. Cloud servers are paid for every month, and bills tend to grow quietly. A badly designed system wastes resources: unnecessary database queries, no caching, heavy operations running where light ones would do. An architect who sorts this out once can cut the monthly bill several times over, and that saving repeats every month.
Preventing downtime. An hour of an online store being down in peak season costs lost sales, an ad budget that kept being spent for nothing, and reputation. An architect thinks about redundancy, monitoring and recovery in advance, not at the moment everything has already crashed.
Reducing operational risks. A leak of client data, losing a database without a backup, dependence on a single service that suddenly shuts down. Each of these risks costs big money at best and the company itself at worst. Architecture is, among other things, a system of insurance.
Freedom to hire. A system built on clear, widespread technologies with a readable structure lets you bring in new programmers quickly. A system built on exotic tools or one genius's personal inventions makes the company hostage to that genius.
What an architect should not do
Let's be honest: architects can destroy money too. The most common way is overengineering. Microservices for a system used by twenty people. Three layers of abstraction where one function would do. Preparing for a million users in a product that has not yet found its first hundred.
A good architect thinks not about which architecture is the most beautiful but about which is the most profitable for a specific business at a specific stage. Sometimes that means consciously choosing a simple solution and writing down in the plan when it will have to be redone. That is not laziness, that is economics.
And one more trap: an architect who does not talk to the business. He designs a perfect system for problems that do not exist and misses the tasks that actually make money. My principle: before drawing a diagram, I have to understand how the company earns, where it loses time and what keeps it from growing. Without that, any architecture will be a beautiful city in the desert.
How to measure an architect's contribution
If you are a manager and want to know whether architecture pays off, watch a few indicators over time:
- how long it takes to ship a typical new feature, and whether that time is growing;
- how much infrastructure costs per client or per transaction;
- how many hours per quarter the system was unavailable;
- how long a new developer needs before he starts being useful.
In a system without architecture all these indicators get worse over time. Each new feature comes harder than the last, bills grow, failures multiply. In a system with good architecture they stay stable or improve. The gap between those two curves is the architect's contribution to profit.
What we do
At Ingello Systems architecture starts not with technology but with the business model: what entities exist in the company, which processes bring money, where the bottlenecks are. Then we describe the system formally and use Fractal to generate the foundation of the code, database and interfaces by uniform rules. This removes a whole class of architectural mistakes that appear when every programmer builds his part of the city by his own ideas.
If you are unsure whether your company needs an architect, ask yourself: does every new change in your system cost more than the previous one? If yes, money is already leaking. The only question is how much longer you are willing to pay for it.
