How to explain to children a profession that helps organisations understand themselves
What does an enterprise architect actually do?
When my children ask me that, I sometimes say:
“I draw pictures and talk to people.”
They look at me as if I have just described a surprinsingly simple job. They can draw pictures too. Taltking to people is not exactly difficult either. For a moment, enterprise architecture sounds like something one could do between breakfast, school bags, and the walk to school.
“That doenst’t sound hard,” the say. “I can do that too.”
Most oft the time, I do not contradict them. Perhaps because they are closer to the truth than it seems at first. Perhaps because any more precise explanation would immediately become awkward. I could takt about target architectures, capabilities, systems, data flows, resposibilities, and stratefic alignment. I could explain that organisations develop their own strcutures, their own languages, their own blind spots. But at the kitchen table, between the jam jar and the math notebook, that would be too much.
So the sentence remmains.
I draw pictures and talk to people.
It only becomes difficult when I would have to explain why these pictures do not remain mere pictures. Why a few lines, boxes, arrows, and terms can lead a projekt to make different decisions. Why a conversation is work when it helps an organisation see itself more clearly.
For me, that is where enterprise architecture begins.
In short: What does an enterprise architect do?
An enterprise architect helps an organisation connect its strategy, capabilities, processes, data, systems and responsabilities into a shared context.
They develop pictures, models and conversations so that decisions become clearer and change becomes more sustainable. Their work often takes place before visible implementation begins. Where terms need to be clarified, dependencies recognized, target pictures sharpened and different perspectives connected.
A good enterprise architect does not make decisions on behalf of the organisation. They help make it clearer what is being decided, which consequences are visible and which connections would otherwise remain in the shadows.
A profession with hard-to-see results
Many profession can be explained through visible things. A doctor treats people. A craftsperson builds something you can touch. A teacher teaches children. In IT, too, many roles have results that quickly feel tangible, i.e. an application, a ticket, a release, a bug fix or an interface.
Enterprise architecutre is harder to grasp.
At the end of a good architecture conversation, there is often no new product on the table. Sometimes there is only a different picture in the room. A process map where a gap suddenly becomes visible. A capability map showing that three projects are working on the same organisational ability without knowing about each other. A system context revealing that a small decision in one place creates follow-up costs in five others. Or a single clarified term that prevents two departements from talking past each other for weeks.
The result is real, but rarely load. It shows up in decisions that become clearer. In conversations that evade less. In initiatives that recognize earlier what they depend on. In leaders who understand what an apparently technical decision triggers organisationally. In teams that notice their problem begins somewhere other than where they first assumed.
Enterprise architecture works on prerequisites such as context, orientation, language and the ability to decide. This is precisely why it often reamins invisible while it works.
You usually feel it when it is missing.
When everyone nods and still means different things
In organisation, there are moments that look harmless from the outsie. A meeting begins. Everyone is prepared. On the agenda is a familiar-sounding term. For example: customer process.
The business department speaks about professional steps, responsibilities, exceptions and service promise. IT thinks about applications, data objects, interfaces and system boundaries. Management hears thoughput times, efficiency, standardization and scalability. Operations wonders that will later be stable, maintainable and supportable.
Everyone is talking about the same customer process. At least that is how it seems.
After a few minutes, it becomes clear that different inner pictures are present in the room. Nobody has said anything wrong. Nobody is trying to block progress. And still, the conversation moves i several directions at once. Some discuss process logic, others a system solution. Others are actually talking about a capability the organisation shoudl be able to perform more reliably in the future.
In such moments, architecture work often begins with a simple question:
Are we talking about a process, a capability, a system or a responsibility?
The question is small. It does not solve the problem by itself. But it changes the room. Suddenly it becomes visible that agreement existed only on surface. The conversation loses some of its apparent clarity. It becomes more precise. Distinctions become possible. And only when an organisation can distinguish can it make decisions that hold.
That is one reason why enterprise architecture is so difficult to explain. It often intervenes before something visibly gos wrong. It works at the point where terms, pictures and decisions are still malleable.
What enterprise architecture means
Enterprise architecture describes the work of understanding and shaping the context of an organization. It makes visible how strategy, capabilities, processes, data, applications, technologies, and responsibilities interact.
Its goal is not to describe the organization completely. That would be an illusion. Organizations are too alive, too contradictory, and too mobile to be fully captured in models. The value of enterprise architecture lies elsewhere: it creates orientation for decisions and change.
Enterprise Architecture, often abbreviated as EA, is sometimes confused with methods, frameworks, or modeling tools. These things can help. They form part of the craft. The actual core lies in a different question:
How do strategy, capabilities, processes, data, systems, organization, and responsibility connect in a way that enables actionable change?
This question sounds large. In everyday work, it often begins very small. With a term that carries too many meanings. With a system that has taken on tasks it was never meant to perform. With a process that only works because experienced people know the gaps. With a target picture that looks plausible on slides, yet lacks a sufficient connection to implementation.
Enterprise architecture makes these places visible. It shows where an organization describes itself differently from how it actually works. It reveals where capabilities are missing, where responsibilities blur, where data is created multiple times, where technical dependencies are underestimated, and where local solutions burden the larger context.
This sounds less spectacular than major transformation. Yet this is where it becomes clear whether change can hold.
An organization can invest a great deal of energy in projects, programs, and initiatives. When the context is missing, movement arises without direction. Implementation begins before it is sufficiently clear what should actually become possible. The IT landscape then grows along individual needs while the strategic line becomes weaker. Complexity is shifted until it reappears somewhere else.
Enterprise architecture helps recognize these shifts earlier.
Pictures in which organisations recognize themselves
When I say that I draw pictures, I do not mean presentation decoration. An architecture picture is not an ornament for a steering committee and not proof that someone knows how to use a modeling tool.
A good architecture picture is a surface for thinking.
It shows what belongs together. It reveals dependencies. It makes visible where different logics meet. It shows fractures, overlaps, gaps, and sometimes things no one wanted to see for a long time.
A capability map, for example, asks: Which capabilities does this organization need in order to truly implement its strategy? It organizes by what an organization must be able to do. In practice, this can be very clarifying. Suddenly it becomes visible that a strategic goal does not need a technical solution before the capability to be strengthened has been clarified. Or that a supposedly new topic is already being worked on in several areas, just under different names.
A process map shows how work flows, where value is created, where handovers occur, and where responsibility becomes unclear. A system context shows which applications are involved, where data is created, where it is changed, and which dependencies exist in operations. A target picture helps describe a direction before individual measures replace it. A roadmap makes visible which steps build on one another and where an organization overwhelms itself by starting everything at once.
Such pictures rarely answer all questions. They do not need to. Their value lies in allowing the right questions to be asked about the same object.
An architecture picture is successful when people discover contradictions in it before they become expensive in implementation, operations, or customer contact. When someone says: “I have never seen it that way before.” Or: “If this is true, then we are solving the wrong problem.” Or even: “Now I understand why this discussion has been stuck for weeks.”
Then the picture has done its work.
Conversations in which meaning emerges
The second part of my answer to my children sounds even simpler: I talk to people.
That is true as well. A large part of architecture work consists of conversations. But these conversations are not an accompaniment to the actual work. They are part of the work itself.
Many misunderstandings in organizations arise because familiar words carry different meanings in different rooms.
A word like “customer” may mean the insured person in one area, the service provider in another, the internal client in the next, or an abstract market role. A “case” can be a request, a process instance, a medical context, a bundle of documents, a work object, or a responsibility over time. A “service” can be a professional offering, an IT service, a communication channel, or a promise to the customer. A “platform” can mean a technical foundation, a product strategy, an integration space, or simply the hope that future complexity will be better contained somewhere else.
As long as these meanings are unclear, people build on unstable ground. They agree and mean different things. They appear to decide together and then carry different pictures into implementation. Later, everyone wonders why coordination becomes difficult, requirements grow, interfaces shift, and responsibilities have to be discussed again.
Architecture conversations try to make these meanings strong enough to carry decisions. Not through instruction. More through patient uncovering.
What do you mean when you say customer?
Which capability should be strengthened?
Which decision is actually still open?
Who carries responsibility when the process crosses the system boundary?
Which dependency arises if this solution goes live?
What would need to become visible for the next step to be responsible?
Such questions can seem simple. In good moments, they change the quality of the conversation. Opinions become perspectives. Perspectives reveal differences. From differences, decisions can emerge.
Perhaps this is the quietest form of architecture work: keeping a room open long enough for the organization to recognize which question it actually needs to answer.
What an enterprise architect contributes in everyday work
Of course, enterprise architecture does not consist solely of pictures and conversations. It uses methods, models, principles, standards, and tools. It works with strategies, capabilities, processes, data, applications, technologies, and organizational structures. It touches IT architecture, business architecture, information security, data protection, operations, project portfolio management, product development, and corporate steering.
Yet in everyday work, many contributions can be traced back to four movements.
Enterprise architects make connections visible
They look at individual projects, systems, and requirements within a larger structure. Which capability supports which strategic goal? Which systems support which business tasks? Where is data created? Who uses it? Which change creates consequences elsewhere? Where is an organizational decision disguised as a technical requirement?
Enterprise architects translate between perspectives
They speak with business departments, IT, management, and operations without declaring one of these logics the only truth. Each perspective sees something. Each overlooks something. Architecture work tries to bring these views into relation so that a more resilient picture can emerge.
Enterprise architects create decision-making ability
They rarely decide alone. Nor should they. Their task lies more in making decision spaces easier to read. Which options exist? What are their consequences? Which dependencies are known? Which risks remain open? Which decision is being avoided although it has long been necessary?
Enterprise architects keep sight of the whole
They pay attention to context. A local solution can be professionally reasonable, technically elegant, and efficient in the short term. It can still burden the larger structure if it duplicates data, shifts responsibilities, increases operational complexity, or undermines strategic target pictures.
This work is rarely spectacular. It consists of questions, pictures, distinctions, and sometimes disagreement. It protects organizations from the illusion that a well-described individual problem automatically leads to a good overall solution.
Where enterprise architecture becomes uncomfortable
Understanding sounds pleasant. In practice, it is not always pleasant.
An architecture picture can calm things down because it creates order. It can also do the opposite. Sometimes it shows that the lack of clarity has been useful. It has hidden a conflict. It has kept responsibilities suspended. It has allowed several areas to work with the same term without revealing their different interests.
Then architecture work becomes uncomfortable.
A diagram may show that two systems do the same thing because two organizational units built their own solutions. A process map may show that a handover has worked for years through personal experience, yet is not truly owned anywhere. A capability map may show that a strategically important capability is not really led by any area. A target picture may show that a project is already building a solution before the organization has clarified which future state it wants to reach.
Such insights are not always welcome. They touch budgets, responsibilities, priorities, and interpretive authority. They show that architecture is practical ordering work and at the same time takes place in the shadow of interests, habits, and power.
That is why enterprise architecture requires sensitivity. A picture can come too early. A question can be asked too sharply. A distinction can be professionally correct and politically unwise. Anyone who takes architecture work seriously must be able to read structures and understand situations at the same time. Sometimes the next viable step matters more than the complete truth on a slide.
This makes the role demanding. It moves between clarity and connection. Between what needs to become visible and what an organization can bear at that moment.
Why enterprise architecture is often noticed only when it is missing
Missing enterprise architecture rarely makes a loud noise. It shows itself in friction, repetition, detours, and conversations that start from the beginning again and again.
A project solves a local problem and creates a new dependency in operations. Another initiative builds a similar function because nobody saw the overlap. A strategic initiative loses direction on the way to implementation because nobody translated which capabilities actually need to change. A term remains unclear and travels through concepts, requirements, and tickets until its ambiguity becomes expensive.
Sometimes missing architecture also shows up in the customer experience. Individual parts work, but the connection breaks. The customer is passed on, has to explain things again, receives contradictory information, or experiences digital and personal channels as separate worlds. From the organization’s point of view, every element was justifiable. From the customer’s point of view, the transition matters.
That is where architecture becomes practical. It asks about the connection between strategy, organization, process, data, system, and experience. It examines whether individual building blocks form a structure that can carry.
When architecture is missing, complexity does not become smaller. It only moves. Into manual exceptions. Into operations teams. Into interfaces. Into project coordination. Into customer contacts. Into steering committees that have to make the same decisions again because the context was not sufficiently visible earlier.
Good architecture work does not prevent every friction. Organizations remain alive, contradictory, political, limited. But it can help recognize friction earlier and decide more consciously which complexity to accept and which to avoid.
Between strategy and implementation
Perhaps the true place of enterprise architecture lies between things.
Between strategy and implementation.
Between business expertise and technology.
Between the present and the target picture.
Between project and operations.
Between what is said and what is meant.
Between local solution and organizational context.
Many misunderstandings arise at these transitions. This is where strategy loses direction. This is where business needs become narrowed into technical requirements. This is where solutions emerge whose follow-up costs only become visible later. This is where people are needed who can read transitions.
That requires professional knowledge, as well as patience. It requires structure, as well as a feeling for language. It requires the ability to endure uncertainty without smoothing it over too quickly. And it requires a willingness to sit between chairs at times, because that is precisely where the connections become visible.
Enterprise architects rarely work alone. Their effectiveness depends on whether others are willing to think with them. An architecture model that no one uses remains paper. A principle that influences no decision remains a claim. A roadmap that clarifies no responsibility remains planning language.
Architecture only becomes alive when it changes conversations.
Back to the kitchen table
Perhaps it is not that hard to explain this profession to children. It is harder to show adults in organizations that pictures and conversations are not by-products of the work. Sometimes they are the place where work first becomes decidable.
So when my children say that drawing pictures and talking to people does not sound difficult, I still do not contradict them. Perhaps they have seen something essential.
I draw pictures in which organizations can recognize themselves. I talk to people so that different perspectives can become a shared view. And I try to make connections visible before they return as problems.
It sounds simple.
Perhaps it has to sound simple so that the first step can be understood. The difficulty comes later: in careful observation, in patient questioning, in enduring ambiguity, in drawing a picture that does not calm things down before it has clarified something.
This series therefore does not begin with a framework. It begins with a question at the kitchen table. Perhaps that is the best place from which to tell what enterprise architecture does in everyday work.
It helps organizations see themselves.
And sometimes that begins with a picture.
FAQ: About enterprise architecture
What does an enterprise architect do?
An enterprise architect makes connections visible. They connect strategy, capabilities, processes, data, systems, and responsibilities so that decisions become clearer and change becomes more sustainable.
Why is enterprise architecture important?
Enterprise architecture helps recognize friction, duplicate work, unclear terms, and technical follow-up costs earlier. It creates orientation between strategy and implementation.
Is enterprise architecture an IT topic?
Enterprise architecture touches IT, yet it extends beyond it. It also looks at business capabilities, processes, organization, data, responsibility, and strategic target pictures.
Why does an enterprise architect work with pictures?
Architecture pictures make complex connections discussable. They show dependencies, fractures, overlaps, and open decisions.
What is the difference between enterprise architecture and IT architecture?
IT architecture focuses more strongly on technical structures and solutions. Enterprise architecture looks at the broader connection between strategy, organization, business capabilities, data, applications, and change.
What is a capability map?
A capability map shows which capabilities an organization needs or possesses. It helps connect strategic goals with business and technical change.
What is a target picture in enterprise architecture?
A target picture describes an intended direction for organization, capabilities, processes, systems, or data. It helps align individual measures with a shared understanding.