Architecture between Being, Change, and Ethics
Architecture is not exclusively a technical process. It is an act of design – with consequences for people, organizations, and society. This applies to the developer who designs a single system as well as to the enterprise architect who translates a company’s self-image into structures. Anyone who designs at one of these levels must be aware of three basic conditions: the nature of the system, continuous change, and the ethical dimension of every decision. These three pillars are interdependent – and they require an attitude, not a method. A plea for architecture that knows what it is doing.
This article is based on a talk I gave at IT-Tage 2024 and an article based on it in Informatik Aktuell. This version here is more focussed on being, change, and ethics.
The article deliberately emphasizes the feminine form of the professional groups addressed. I would like to take this opportunity to pay tribute to my female colleagues in my professional life.
Three pillars, one attitude
An architect who designs a system makes decisions with a long half-life. She chooses structures that open up possibilities – and close others. This effect extends far beyond the project horizon: beyond releases, team changes, and original requirements.
But architecture does not only take place at the level of individual systems. It spans a spectrum that ranges from the design of individual software solutions to system architecture – including technical infrastructures and their dependencies – to enterprise architecture. At this highest level, the architect translates the wishes of senior management into viable structures. Due to her proximity to corporate management, her role goes even further: she shapes the institutional self-image – what the company is, how it positions itself in society, what values it embodies in its systems. With each level, the scope of decisions grows – and with it the weight of the three basic conditions that shape all architectural work.
These three conditions cannot be separated from one another:
The being of a system describes what it is: not a neutral artifact, but a structure with social reality that enables, limits, and generates action. The principle of change describes that no system remains static and that the architect is not responsible for a state, but for a movement. Finally, ethics asks what consequences this movement has for people – directly and indirectly, intentionally and unintentionally.
Those who only consider one of these three conditions create incompletely. Those who take all three seriously understand that architecture is responsibility in motion.
Knowledge of being
Before an architect designs, she must answer a question that is rarely asked: What is this system actually?
The obvious answer is: a technical artifact – code, data structures, processes. However, this answer is insufficient. A software system is also a social process: it structures communication, regulates access, distributes power, and defines what is visible and what is not. It does not arise in a vacuum and does not operate in a vacuum.
Aristotle distinguished between the question of what and the question of how. For him, the what – the definition of the object – is the starting point on which everything depends. Applied to software architecture, this means that those who do not know what a system is and what it stands for in the world cannot make responsible decisions about how it should be designed.
This awareness is not a philosophical game. It is practical. An architect who understands that a recruiting system not only filters applications but also distributes access opportunities to employment asks different questions:
What criteria are used to sort applications – and who defined these criteria? What patterns from the past are encoded in algorithms? Who benefits from automation, and who is systematically disadvantaged by it?
These questions cannot be delegated. And they cannot be answered without the ontological foundation: the knowledge of what is actually being built here.
Awareness of the nature of a system can also be communicated. An architect must be able to convey it to the team, in stakeholder discussions, in requirements workshops. Not as a lecture, but as an invitation to clarify together: What do we actually want to create here – and what do we explicitly not want?
But this awareness does not arise on its own. It requires active work – before the first decision and during all subsequent ones. If you really want to understand what a system is, you have to ask questions that don’t come up in the briefing: Who are the actual users? What happens to the data generated by the system? Who benefits – and who bears the costs without knowing it? This is not a matter of fulfilling obligations in a bureaucratic sense, but rather epistemic diligence: actively seeking the knowledge that makes responsible action possible in the first place.
This also includes a willingness to look ahead. A system that is considered a harmless process optimizer today may serve as a surveillance tool tomorrow. Anyone who fails to consider this possibility has not fully assumed their responsibility – even if the original intention was honest. Identified risks and open questions belong in the dialogue: with clients, with the team, with one’s own organization. Remaining silent when you are aware of something is not a neutral stance. It is a decision.
Continuous change
Heraclitus taught that everything flows – panta rhei. Change is not an exception, but the fundamental principle of all existence. This applies to IT architecture in particular – and in several dimensions at once. The travel from mainframes via client/server, application servers and SOA to micro server applications on hyperscaler cloud providers or Kubernetes. And today AI even goes further.
The system itself changes: requirements grow, libraries age, infrastructures migrate. What seems stable today is technical debt tomorrow. The organization around the system changes: teams are restructured, responsibilities shift, knowledge is lost. And the ethical responsibility changes: what seemed acceptable during the design phase may prove problematic in operation – due to new contexts of use, changed social evaluations, or unforeseen consequences.
Change is therefore not a requirement that can be noted in the backlog. It is the condition of existence for every living system.
An architect who has internalized this designs differently. She does not create monolithic structures that demand permanence. She creates systems with adaptability at their core: modular, decoupled, with clear interfaces and explicit extension points. Not because it is methodologically correct, but because she knows that the system will live on after her – in other hands, in other contexts, under other requirements.
Plato asked how a thing remains the same when it changes. The technical answer is: through stability at the core and variability at the edges, through semantic contracts, through decoupling. The ethical answer is: by documenting the decisions that shaped the system. Those who know the reasons can continue to develop responsibly. Those who do not know them repeat the mistakes – or make new ones.
Change therefore affects all three pillars: the identity of the system, the structures of the organization, and the framework of ethical responsibility. The architect does not navigate against this change. She lives and works within it.
The ethical landscape
Ethics in software architecture does not begin with extreme cases. It begins with the realization that every decision has consequences – for users, for organizations, for third parties who will never touch the system. These consequences unfold in several layers.
Layer 1 – The direct dilemma: weapons systems
Until a few years ago, the question of whether software architects should work on weapons systems was theoretical for many professionals. That has changed. The war in Ukraine, the rearmament of European armed forces, and the growing need for digital defense infrastructures have brought the issue to the forefront of everyday professional life. More and more companies are accepting such contracts – and more and more employees are having to take a stand.
The issue is also coming to a head at the institutional level. Anthropic, the company behind the AI system Claude, has long had a clear stance on military applications. Now it is under considerable pressure from the US government to abandon this line. This is not a marginal phenomenon – it is a lesson in how quickly ethical positions can shift under political and economic pressures.
Hans Jonas formulated the ethical imperative: Act in such a way that the consequences of your actions are compatible with the continuation of human life. This principle is not abstract in the context of armaments. It poses a direct question: Can I take responsibility for the consequences of my work – even if I am only designing a small, technical part of a system whose overall purpose is to harm people?
There is no universal answer. But there is a duty to ask the question. And there is a right to refuse – even if it has consequences.
Layer 2 – The indirect dilemma: ecological and economic consequences
The more difficult questions lie not in extreme cases, but in everyday life. A project that makes air travel cheaper optimizes efficiency and increases CO₂ emissions. A system that automates operational processes increases productivity and makes jobs redundant. An algorithm that optimizes supply chains reduces costs and redistributes market power, not necessarily in favor of the weaker parties.
Peter Singer extended the concept of moral responsibility to all those affected by an action – regardless of whether they are sitting at the table or not. For the architect, this means that the stakeholders in a system are not only the clients. They are also the employees whose jobs are being rationalized away by the system. The residents who have to put up with the noise of air traffic. Society, which pays the ecological costs.
These affected parties usually have no voice in the requirements process. This makes it all the more important for architects to know their own voice – and to use it.
Layer 3 – The personal spectrum
What seems clear in theory is rarely clear in practice. Most people do not move between approval and rejection, but rather within a spectrum shaped by individual circumstances, power structures, and fears:
Approval with conviction: The architect supports the project, sees no ethical conflict, or has resolved it for herself.
Rejection with consequence: She refuses to cooperate, accepts the conflict with her employer, and looks for another way.
Fulfilling her duty with reservations: She goes along with it even though she has doubts. She tells herself: Others would do it anyway. My contribution is small. I may be able to exert influence internally.
Silence out of fear: She has concerns but does not express them. The fear of consequences – of losing the project, her job, her reputation – prevails.
Retreating into the role of victim: Those who remain silent for a long time risk further displacement: silence becomes a habit, and habit becomes an internal narrative. The person affected increasingly sees themselves not as an actor, but as someone who is driven – as a victim of structures against which they can do nothing. This attitude reduces personal commitment: those who see themselves as victims no longer bear any responsibility. But at the same time, it increases the risk of a final break. The inner distance grows until the only remaining way out is to disappear or leave – a silent resignation in thought before the formal one follows or fails to materialize. For the team, this means a person who is physically present but has long since left inwardly.
This spectrum is human. No one should judge it moralistically. But the architect must be aware of it – in herself and in her team. Because these thoughts are not only going through her mind. They also affect developers, project managers, and testers. Teams working on ethically challenging projects bear this burden together – even if they rarely talk about it.
The spectrum does not run the same across all levels of architecture. The software architect implements decisions that are largely predetermined – her scope for action is real, but limited. The system architect designs infrastructures that connect multiple systems and organizational units – her decisions have a deeper impact and are more difficult to reverse. Finally, the enterprise architect sits at a different table: she is close to the company management, knows the strategic intentions before they become public, and can actively shape the company’s self-image through her design proposals. This proximity to power is a resource – but also a responsibility that cannot be separated from the personal spectrum. On the contrary: those who have more influence bear the burden of silence more heavily. The victim role is less plausible at this level – and therefore all the more revealing when it is assumed nonetheless.
This is where the architect has a special task: not to be a judge, but a moderator. Sensitive to the attitudes of others, even if one’s own view is different. Able to open up spaces for conversations that would not normally take place. And able to know the way out – or to search for it together.
Philosophy is not a luxury here. It is a tool. Habermas’ discourse ethics remind us that decisions are only legitimate if all those affected have actually been heard. Jonas’ responsibility for the future requires us to consider the long-term consequences. Kant’s categorical imperative asks the simple question: Would it be reasonable if everyone acted this way?
These questions do not resolve dilemmas. But they help to identify them, think them through, and make conscious decisions – instead of bearing them in silence.
The epistemic duty
Virtues of the architect
The following attitudes distill the above. They are not a checklist, but an expression of a practice a work that understands being, change, and ethics as inseparable dimensions.
Clarity about being: Know what you are building: not only technically, but socially and societally. Communicate this knowledge – to the team, to stakeholders, in dialogue.
Change as a principle: Don’t design for stability, but for controlled changeability. This applies to systems as well as to your own ethical positioning, which can and must evolve with the world.
Ethical awareness as a basic attitude: Ask about the consequences before you design. Name dilemmas instead of ignoring them. Make decisions with all stakeholders in mind, not just the visible ones.
Sensitivity within the team: Recognize that ethical conflicts are not just on your mind, but on everyone’s. Create spaces where they can be discussed.
Epistemic diligence: Actively seek the knowledge you need to act responsibly. Those who don’t ask have already decided.
Empowerment instead of control: Design systems in such a way that others can use them responsibly: today, tomorrow, in other hands. Quality is reflected in how little you are needed when others take over.
Maintainability as a duty: A system that can only be mastered with specialist knowledge creates dependency – not quality. Transferability is an ethical imperative, not an optional feature.
Conclusion
Architecture is a cultural act. It creates spaces in which people act – and defines what is possible within them. Those who are aware of this effect do not just design systems. They create the conditions for meaningful, responsible action in a digital world.
This requires more than technical skill. It requires knowledge of the essence of what is being created. It requires a willingness to navigate change – not fight it. And it requires an ethical attitude that does not stop at the project boundary: keeping an eye on the consequences of one’s own actions, even if they only become apparent later.
Philosophy does not provide answers for this. But it does provide tools – for clarification, for discussion, for understanding. In a world where IT systems are penetrating ever deeper areas of life, these are not academic tools. They are necessary skills.
