personal<IT>y: "Architecture is the silent design of invisible things," says a software architect about systems modeling, system boundaries, and the beauty of hidden decisions

Where invisible cities are born

How would you explain your role as a software architect to someone who doesn’t work in IT at all?

That’s an excellent question. I think the easiest way to explain it is by comparing it to an architect in the real world. Imagine a person who comes to an empty plot of land and says: here we will build a residential complex. Here will be apartment buildings, here a children’s playground, there will be a fountain, downstairs services, little shops, maybe a parking lot, possibly a smaller bar or café.

And in fact, exactly this happens in the world of software as well. At the beginning, there is a concept. Someone comes with a vision of what should be where. And then, similarly to physical construction, you go into the details. An architect in the real world will eventually draw even the last door in every apartment. In software it’s no different—the architect goes into such depth of design that developers can implement it precisely.

So a software architect doesn’t stay only at the concept level, but their work also includes detailed designs, selecting suitable technologies and standards, taking various constraints and expectations into account. In the end, they hand over a detailed specification to the developers, who then code according to it. And although sometimes it happens that someone “improves” things in their own way, it doesn’t always turn out well—like when you find out that the doors open only to the edge of the stairs.

When a system stops being just software

I also spoke with an analyst, and they told me that their role is to find out requirements from the client, translate them into technical language, and hand them over to developers. Where in this cycle is the architect’s place?

In practice, it is often a bit more complicated. Besides the analyst and the developer, the role of a designer also comes into play. Ideally, the designer is somewhere between the analyst and the developer, but their work is very close to the architect’s work. Basically, it is just a different level of abstraction.

An experienced designer could, over time, have the ambition to become an architect—similar to how an architect in the real world first copies other people’s projects, then designs their own family house, and over time, when they are really good, they are entrusted with an entire residential district. The difference between a designer and an architect is that the architect conceives the solution from the top—they have a vision and think about the overall concept of the system. The developer then deals with the specific implementation. So design is a bridge between them.

So who do you collaborate with the most?

That depends a lot on the size of the company. In smaller companies, roles often overlap; people have to perform multiple functions at once. In larger companies, there is more specialization. I, as a person, collaborate with a wide spectrum of people, also because in our company I hold multiple roles—not all of them are written on my business card, but I do them.

From an architect’s point of view, collaboration with the analyst is key—the analyst brings inputs from the customer. Then certainly with the project manager, who manages the organization of the project. And depending on the size of the team, either directly with developers, or there is also a design layer between us. Testers are also important, not only because developers tune test scenarios with them, but also because testers need to understand the architecture and concept of the system in order to effectively cover the whole system with tests.

The hardest decisions are the ones no one sees

At which stages of development does the architect most often step in?

Theoretically, the architect should step into the cycle as early as possible, already during analysis. Because architectural decisions fundamentally influence the entire outcome. But as in the real world, proven templates and stereotypes are often used—those “socialist housing estates.” Once it is invented and then it is just copied. In that case, the architect steps in only at the moment when something “deviates from the norm,” for example when a requirement appears that our existing solutions do not cover.

Then it is necessary either to extend the existing architecture or to design a new solution. And yes—in smaller companies it means that later I also transition into other roles: designer, developer, or even consultant. Not because it would be, in principle, the architect’s job, but because the company is not large enough for me to focus only on architecture.

So the architect designs, approves the solution, and then oversees its adherence during development?

Exactly. The architecture should be as clear as possible before development starts—at least in broad outlines, ideally already thought through in detail to a large extent. Because development is then done within this architecture. And the architect’s role is to oversee that the design and implementation do not deviate from the architecture. It’s like when someone says: here there is supposed to be a residential district, and you can’t just build a warehouse or a hangar there because it suits you at the moment.

You mentioned collaboration with testers—what does it look like specifically?

To a large extent, it is consultations. Because it often happens that conceptual information fades in the team over time. The more someone focuses on details, the more they can lose the wider perspective. And not everyone feels a need to understand the context—why something is designed the way it is. That then causes that when such a person hands their work on, the concept gets completely lost. And someone else on the team no longer sees the bigger picture. That is why it is important that there is someone—typically the architect—who repeatedly brings that picture back into the team.

Chaos that needs to be untangled to take shape

And what about customers? To what extent do you meet with them as well?

It depends on the type of customer and the type of project. Mostly yes—software has to work in the customer’s specific environment, with specific requirements for security, integration, and so on. Sometimes the customer states these requirements very precisely; other times they only hint at something and you have to find out: why do they actually want it? What are they aiming for? What will it bring them? And sometimes even a well-meant “small change” from the customer’s point of view—like one new field in a form—can break the entire concept of the system. And then it is my role to explain that this “small thing” is in fact an intervention into the foundations. Sometimes feasible, sometimes not.

Does that mean you also go directly to meetings with customers?

Yes, quite often. Especially when it turns out that it is no longer about business requirements, but about a problem in the concept of the solution itself. Then I often step into the game—I explain, consult, argue.

And do you manage to explain it so that the customer understands and accepts it?

I hope so. The customer just stacks up a multitude of not always consistent requirements, and you start untangling those conditions, trying to understand what they actually mean. And now it is up to you—in this role—to start looking for how to assemble them into a consistent solution. And sometimes it is precisely in this phase that something appears that I really enjoy: that out of the chaos, out of that set of requirements which outwardly may not even make sense, something is born that has shape, structure, and makes sense.

And when you untangle it, formulate the concept, create the design, and then watch how the software begins to be assembled according to it—like building a house according to plans—that is the “wow moment.” Because then you know that you made decisions that really influenced the direction of the entire project. And when it goes according to that design, when the developers can lean on that architecture, when it makes sense to the testers, when the customer starts to get it... then that is satisfaction. And although it is delayed, it is all the deeper.

And yet paradoxically, often the biggest work happens long before the first line of code is written. And nobody really knows about it. Because when it works, nobody recognizes that anything could have gone wrong. You know, it’s like good infrastructure—when it is well designed, nobody pays attention to it. But when it isn’t, everyone complains.

And this “invisible” part of architectural work, where many decisions are made about how things will talk to each other, where the boundaries will be, how things will behave under load, what should be flexible and what shouldn’t... that is exactly what keeps me in this work the most. Because it is not about just designing something technical. It is about understanding the system as a whole—technology, people, process, requirements, and real constraints. And when you put it together like this, that beauty appears in it. Architecture is, for me, a kind of quiet design of invisible things that, in the end, decide everything.

And you know what else? Sometimes even when something goes wrong—and that does happen sometimes—even then you can have a feeling of success. Because when you can retrospectively analyze where it didn’t work and find a way to avoid it next time, you are one step further again. That is the endless process of learning. And in my opinion, if you lose interest in learning in this process, then you’re done. Then you are just the caretaker of some old decisions.

So I actually also enjoy those moments when something doesn’t work out. Not the failure itself, but the fact that I have the opportunity to understand why it happened. For me personally, that is just as important as the moments when everything clicks and works. And that may be the trait that separates an architect from a developer or a tester. The architect also has to care about what happens “after”—when it breaks, when something changes, when the system will need to be extended, fixed, connected.

Because a system is not born once—it lives. And architecture is about not killing it.
So yes, I’m an enthusiast. And I still feel that I am in that learning process. That it hasn’t ended, that it is moving. And when I feel that I am moving with it, that it is growing, that it is changing and I can understand it or influence it, then I know that it still makes sense.

So when you look back, do you think you have somehow come closer to that ideal image of a software architect?

It probably can’t really be said like that. You know, it’s more about what helps you along the way. And often it’s simply about being lucky enough to meet the right people. People who move you forward so you don’t have to bang your head against the wall all the time. You know, you don’t have to learn everything only from your own mistakes—sometimes it’s nice when someone tells you something in advance.

I was lucky that I worked with several really skilled people, whether they were coders, analysts, designers, architects… people who knew things and, more importantly, had already seen something. And they showed me how to do things better, more efficiently. What to look at, what to pay attention to. And they were great people. I certainly owe a lot to them.

You mentioned that there is also a certain creativity in the job, that abstraction is always present, along with some mathematics. What do you enjoy most about it?

You know what, I think everyone probably has it a bit differently. But for me, the most encouraging, the most pleasant thing is when what we do actually works in the end. When the result succeeds, when the implementation—the system we designed—really fulfills what we intended. Yeah, sometimes the customer doesn’t fully see everything they gained from it, but we see it. We see that it works, that it behaves the way it was supposed to. And that is a really good feeling. A strong one.

But at the same time, that “success,” that encouragement, doesn’t come immediately. Very often it only becomes visible later. For example, you get a list of requirements from the customer through the analyst. Something that some algorithm or process is supposed to fulfill. And now it’s up to you to untangle it all and design data structures and implementation approaches that will meet all of that.

And when you succeed, when you see that it runs like clockwork, then you’re satisfied. It’s very encouraging. But of course, the path to that point is often quite frustrating. Because sometimes you just can’t find it. Sometimes you feel like you have to explain to everyone over and over again that “this won’t work like this, because it conflicts with this and that.” And the customer often doesn’t realize it, because it’s not visible at first glance.

You know, they tell you: “I want you to always pick the oldest goods from the warehouse.” OK. And then they say: “And it has to be as fast as possible.” Well fine, but those things may not go together. Because if I want to go straight for the oldest goods, I might have to wait for them, dig them out from under others, or walk across half the warehouse. So then I can’t expect the fastest dispatch. Simply put, not all requirements are compatible—there’s a balance.

It’s like in programming, when you have a task of a certain complexity, you basically have only two options. Either you have a huge amount of space, memory, and you do it quickly, or you have little memory, and then it costs you a lot of processing power. Somewhere you have to invest—either in computational capacity or in memory. But if you do neither, then it simply won’t be fast. And it’s the same in reality: if you want a warehouse to work faster, then buy a bigger warehouse. But that will be expensive.

And that’s the moment where the software architect comes in—because during the design, they have to think about all the processes that are happening there. About the complex picture of what is happening, what will happen, and what compromises are acceptable. And sometimes it’s just about the customer wanting a “button for everything,” and you have to explain to them that such software doesn’t exist. Or rather, that it does exist—but it will cost a million.

So in that design process, you basically have to understand the entire system, what’s going on there—not just the software, but the whole world around it?

Well… yes. But it’s not possible to keep the entire system in your head in complete detail. That’s not possible. The warehouse, even though it may seem simple at first glance, is a very complex organism on the inside. And you know, it’s like having a bag of water. Your brain has a certain capacity, a certain volume it can process at once. And around you there is a heap of data, information, processes.

Some of them are close to the problem you’re currently solving—you need to understand those in depth. Others are further away—you just kind of “sense” them, you know they exist, but you’re not dealing with them in detail right now. And as you dive deeper into one part, other parts get “pushed out” of your head. So you have to make a selection of what you need to keep in your head at that moment.

And when you look at those processes, there are different types of interactions. You have two processes that do the same thing, but in a different part of the warehouse. You have two processes where the output of one is the input for the other. And then you have human will, stochastic interventions. Something happens, someone changes a priority, something gets blocked… And in your design, you have to take these possibilities into account. You don’t always have to solve them, but you at least have to have them in mind.

Maybe we are also just a well-designed model

And when you think it all through, create a design that covers the main processes… Do you feel that the world can be fully understood?

Hardly. For example, it took us about ten years before we really started to understand it. Those first attempts weren’t completely accurate. They were more like simulations, experiments. And I don’t even know whether “simulation” is the right word.

But basically, you have to see the real world, observe what’s happening in it. And then think about what you want to bring into your model from it. What is important, and what isn’t. Yeah, I have a warehouse worker there—is it important whether he’s blond or not? No. But it is important how quickly he can react, what he can do, how he handles system outages… And that is important for the model.

Because a model is not a description of reality in every detail—it’s just a slice. It’s about the fact that the “picking” workstation can do this, reacts to such stimuli like this. Whether it all makes sense when it’s put together, you only find out later. And sometimes it still only makes sense on paper.

So… when you describe it like this—that as an architect you create models of the real world that function in a digital environment, you design rules, structures, and observe how those entities behave—it brings me to the question of whether you think it’s possible that we are also living in a simulation?

Well… I’m thinking about how to answer that properly. The short answer is: certainly yes. It could be. For example, The Matrix. Yeah, that’s the simple cultural example, but… it hides that infinitely old philosophical question of what free will is, and whether we are actually free. Because if we were a simulation, it would mean that we are not free. We only do what we were programmed to do. Yeah, like when someone in “production” set our genes and our decisions are really just computationally predetermined reactions to certain inputs.

But that’s the philosophical level—whether we feel that we act freely, or whether we’re just playing a role in some scenario. And we can neither prove nor disprove it. Because even when you look at how the brain works, we don’t know whether our reactions are purely biological, or something more. And again, at first glance, it doesn’t seem completely deterministic. We do many things differently, even when circumstances are similar. Sometimes we react to the same situation one way, other times completely differently. So the question is whether that system—if it is a system—contains randomness, or just chaos that we can’t yet explain.

So it’s a difficult question, but… yes, I can imagine that we could be part of something like that. That what I do—creating a system in which entities behave according to rules and sometimes surprise me—is exactly what someone is doing with us. And we are just those entities who think they have free will. Or to put it differently, maybe we are doing the same thing that that “someone” is doing with us. Just on a smaller scale. And through what we do, maybe we are also learning to understand it.

And no, that doesn’t yet mean that I think everything here is controlled by some otherworldly programmer. But the idea that our world could be a model seems completely realistic to me. And maybe not exactly as sci-fi shows it, but in principle… why not? In the end, when you look at how we build software, it also starts abstractly. Design, rules, models… and then it runs. And sometimes it behaves the way we wanted, and sometimes the system itself surprises us. Because new relationships and new situations emerge in it. And maybe we ourselves are just such a complex output of some other model. And somewhere, maybe, someone is tuning our architecture.

But that’s probably more metaphysics than software.