André Aulich — Writing

Security by Design for Analytics Platforms: What Changes When Your Users Face State-Level Threats

Mon, 13 Jul 2026 00:00:00 GMT

Picture the kickoff of a data project. An organization wants to understand how its offering is used: what reaches whom, what works, what doesn't, where to invest next. The plan is exactly right — consolidate usage data from a handful of source systems onto one analytics platform, build data products on top, give decision-makers numbers instead of assumptions. Somewhere in the architecture document there is a security chapter, and it says what security chapters usually say: encryption, backups, access control, GDPR.

For most companies that chapter is about the organization's risk. If the data leaks, there is a fine, a headline, an uncomfortable board meeting. Painful — and survivable.

Now change one assumption: your users can go to prison for using your product.

That is not a thought experiment. There are countries where reading independent journalism, or sharing it, is a criminal offense. For an organization whose mission is to reach exactly those people, a log line that connects a person to a piece of content is not a usage metric. It is potential evidence. And the moment you build a platform that aggregates those log lines, you have changed your own threat model — whether you noticed or not.

I thought I knew this problem. I knew half of it.

I have spent a large part of my career in and around newsrooms. In environments like Al Jazeera shortly after 9/11, the Guardian shortly after the Snowden publications, or the Frontline Club in London, source protection is simply part of the craft. Nobody debates whether the identity of a whistleblower deserves architectural attention; the systems, the processes, sometimes the building itself are designed around it.

Now imagine that, in addition to protecting your sources, protecting your audience becomes just as important. Not the few people who bring you information, but the many who consume it — who may need protection from their own governments. I'll be honest: the first time that thought lands — that an organization's own analytics could be the very thing that endangers the people it wants to reach — it is deeply unsettling. It is also, once you see it, obviously an architecture problem.

And it is not a media-only problem. The same class applies to NGOs, to health platforms, to any service where the usage data alone incriminates, exposes, or endangers the user. The public breaches that make this vivid are rarely the ones where the product database was cracked — they are the ones where an analytics environment leaked, and suddenly the most sensitive fact about millions of people was not a password but a usage history.

The question nobody at the table wants to ask

Here is the moment I think every architect of an aggregation platform should force: you are consolidating data from many source systems into one place, precisely because having it in one place is valuable. Then ask, out loud:

"Are we ourselves now the security risk?"

Because the answer is usually yes. An analytics platform is, by design, a concentration of exactly the information an adversary would otherwise have to collect system by system, breach by breach. Each source system holds a fragment; your platform holds the joined picture. For an attacker, it may be both more attractive and easier to take the aggregate than to take any single source. You built the platform because aggregated data is more valuable — you don't get to be surprised that adversaries agree.

This is why the work has to start with a threat model rather than a toolbox. And the single most consequential line in that threat model is who the adversary is. A commercial data thief wants data they can monetize, cheaply, and moves on when you are expensive to attack. A state is a different opponent: patient, well-resourced, with legal instruments as well as technical ones, and interested in specific people. When the adversary changes from "someone who wants data" to "someone who wants your users," the crown jewel changes too. It is not the product data, not the revenue numbers — it is the link between a person and their behavior. Every design decision that follows is about making that link scarce, coarse, or nonexistent.

Data minimization is an architecture decision

Every data organization says it practices data minimization, because the GDPR obliges it to. In most places that means a retention policy document and a yearly audit. Under a state-level threat model, minimization moves from the compliance annex into the architecture itself, as three design rules:

Collect only what current analyses need. Not what might be useful someday — that "someday" pile is precisely the asset an attacker wants and a court can compel. If no data product needs it today, it is not collected today. Collection follows demand, not hope.
Persist even less than you collect. Some questions can be answered in passing — aggregate at the edge, keep the count, drop the event. Everything that lands in storage should have to justify its persistence, not its deletion.
Avoid personally identifiable information by design. The most effective control is to make the dangerous join impossible: no user accounts in the analytics path where you can avoid them, aggregates instead of individual trails, cohorts instead of profiles.

The test I give every incoming analytics requirement is one question: "Can we answer this without knowing who?" In my experience the honest answer is almost always yes. Product owners and analysts want to know how many, where, how long, which parts of the offering — questions about populations, not persons. The individual-level data that accumulates in most platforms isn't there because anyone needs it. It is there because collecting it was the default. Security by design, at its core, is changing that default.

There is a satisfying corollary: the safest data is data you never collected. No breach can expose it, no insider can sell it, no legal order can compel it. Minimization is the one security control that cannot fail at 3 a.m.

Design access as if someone is already inside

Whatever you do collect still needs protecting, and here the principle is to assume partial failure. A few patterns carry most of the weight:

Authorization per data product, not per platform. Access is granted to this data product for this purpose — down to table and column granularity where the data warrants it. The analyst who needs aggregated metrics does not, by that fact, get raw events.
Global access for no one. Not the platform team, not the admins, not the CEO. If a single account can read everything, that account is the target, and eventually someone will hold it who shouldn't. "Who can see all of it?" should have the answer: nobody.
The unglamorous basics, actually done. Two-factor authentication everywhere, encryption at rest, joiner-mover-leaver processes that work. None of this is novel; all of it fails more often through absence than through sophistication.
Placement as a threat-model decision. Where the platform physically and legally lives — on-premises, in a cloud, in which cloud under which jurisdiction — is not a cost or convenience question when your adversary is a state with legal reach. It is part of the security design, decided with the threat model on the table, not after it.

None of these patterns is exotic. What changes under this threat model is that they stop being nice-to-haves you trade away for delivery speed, because the cost of failure is not measured in fines.

The residual risk is real — say so

And then there is the part that belongs in the architecture document even though nobody enjoys writing it: complete protection is not possible. Endpoints you don't control, networks you don't operate, platforms you don't run — parts of the path between you and your users are simply outside your reach, and a state-level adversary can work on all of them. A residual risk remains, no matter how good the design is.

Saying this out loud is not defeatism; it is the opposite. An architecture that claims full protection will be designed complacently. An architecture that assumes eventual partial failure gets the properties you actually want: a platform where a successful breach yields aggregates instead of identities, where no credential opens everything, and where the most dangerous data was never collected in the first place. You design for the residual risk, not in denial of it.

Security sits at the shared table

Last, the organizational point, because none of the above is a one-time review. Which data may be collected, how long it lives, who may access which data product, where the platform runs — these are exactly the questions I described in Meet Once, Not Twice as belonging at the single, shared governance table, answered once for data and AI together. Security under a serious threat model is not a gate at the end of that process. It is a standing seat at that table — because every new data product, every new analysis, every new AI use case on top of the platform reopens the same question: does this create a new way to link a person to their behavior?

If your users only risk embarrassment, you may get away with treating security as a chapter. If your users risk prison, security is a design partner from the first whiteboard. The good news, having sat through it: the resulting architecture is not slower or poorer. It is leaner — because it stopped collecting what it never needed — and it can answer the question every architect of an aggregation platform should be able to answer: we know we are a target, and here is why that is survivable — for us, and for the people who trust us.

Meet Once, Not Twice: Think Your Data and AI Organization Together

Thu, 09 Jul 2026 00:00:00 GMT

Most organizations arrive at data and AI the same way: as two projects. The data initiative starts first — a Data Mesh, a central platform, governance standards, an enabling team, a handful of decentralized domain teams. Some time later the AI initiative arrives on top, usually with its own budget, its own team, and its own operating model. Two initiatives, two roadmaps, two org charts.

And here is the part that quietly costs the most: both of them have to talk to the same cross-cutting teams. The data initiative sits down with Security, Legal & Compliance, Data Governance, Enterprise Architecture, and Portfolio Management to work out which data may be collected, how it must be classified, where it may be stored, and how the whole effort ranks against everything else the company could fund. Then the AI initiative sits down with exactly the same teams to work out which data may be processed with a model, where inference may run, which jurisdiction applies, and how its effort ranks. Same people, same questions, two calendars.

The result is familiar: duplicated meetings competing for the same scarce reviewers; standards that drift apart because they were decided in two rooms; and a time-to-market that grows precisely because every cross-cutting concern is negotiated twice. Yet for any given use case, the data flows and the AI on top of them are steps in one value stream. Splitting them into two governance tracks doesn't just add overhead — it pulls apart decisions that belong together.

Why they can share one organization

This isn't a coincidence of scheduling. The two disciplines are structurally the same shape, because they grew up the same way.

Data organizations spent two decades on a pendulum. Analysis started inside operational systems, then moved into a central Data Warehouse to get it off the transactional databases and into one place. Central was good for consistency and broke on knowledge — the central team never understood a domain's data as well as the domain did. So the pendulum swung back toward the domains and settled, with Data Mesh, on a structured hybrid: domains own their data products, a central platform team offers self-serve infrastructure, and a federated governance forum sets the rules everyone shares.

AI operating models walked the same road, faster. A central ML/AI Center of Excellence played the Data-Warehouse role — scarce specialists, decoupled from the domains, producing models that never fully absorbed the domain knowledge. Hub-and-spoke then embedded those specialists into the business. And when generative AI turned AI into something the business pulled rather than something IT pushed, the central hub stopped acting as a gatekeeper and became a platform-and-enablement function — the very same move the central data team made when it became a platform team.

Both fields, independently, converged on one answer: push execution out to the domains, keep the guardrails central as platform and policy, and settle the balance in a federated forum. That shared shape is exactly why one organization can carry both.

But same shape does not mean merge everything. The rule this article argues for is deliberately narrow: thinking together is mandatory; implementing together is a choice you make per use case. You think through the data organization and the AI operating model as one in order to find the synergies — and the biggest synergy, the one available on day one regardless of your maturity, is the shared table. (Table as in the wooden one you gather around and knock on for luck — not the one where you keep your rows and columns.)

The integrated model, in one paragraph

Concretely, a single decentralized organization carries both. Domain teams — your existing business domains — own their data products and their AI use cases; they are the spokes. A platform team runs the shared infrastructure, the data platform and the AI platform side by side. An enabling team lends scarce data and AI specialists to domains that need them, and works to make itself unnecessary. And a federated governance forum is where domains, platform, enabling, and the cross-cutting teams settle the rules together. The AI hub-and-spoke model maps onto these four layers almost one-to-one — which is the whole point: there is no second organization to build. This four-layer structure deserves its own deep-dive; here it is enough to see that one shared table carries both.

The payoff: one table

Now return to the two calendars from the opening. In the integrated organization there is one governance cadence, not two. Security, Legal & Compliance, Data Governance, Enterprise Architecture, and Portfolio Management sit at the same table as the domain, platform, and enabling teams — and the end-to-end question gets asked once: which data may I collect, which of it may I process with a model, and where must it stay? That is a data-governance question and an AI-governance question at the same time. Answered once, by one body, it comes out consistent. Answered in two rooms, it comes out contradictory — and someone spends the next quarter reconciling the two.

The benefits compound:

Decisions are made once and stay coherent — no more AI policy that quietly contradicts the data-classification standard.
The cross-cutting teams see the whole value stream, not half of it, so their review is grounded in what the use case actually does end to end.
Portfolio management can rank a data-plus-AI use case as one effort against everything else, instead of trying to add up two halves it can't compare.
Scarce reviewers are spent once, not booked twice — a good data-protection lawyer or a security architect is a bottleneck you don't want to double-book.
Time-to-market shrinks, because the slow part of most use cases isn't the engineering — it's the sequence of approvals.

None of this requires the data people and the AI people to become one team. It requires them to share one table.

And for some organizations, one seat at that table carries far more weight than the others: when the usage data itself can endanger the people it describes, security stops being a review step and becomes a design partner. I've written about that case — and what it does to an architecture — in Security by Design for Analytics Platforms.

The objections are real — and they set the limit

The integration is not free, and the honest objections are worth stating plainly. An integrated model is harder to explain than two tidy, separate initiatives. Data and AI often move to different rhythms — a solid data foundation is a governance marathon, while an AI win is frequently a quick sprint — and forcing them into lockstep can frustrate both. The two disciplines carry different cultures, skill sets, and speed expectations, and putting them in one room can create friction rather than remove it.

Every one of these is a real argument — against implementing everything jointly. Not one of them is an argument against thinking jointly, or against the shared table. So you keep one governance forum and one portfolio view, and you decide, use case by use case, whether a given piece of data-and-AI work is built by one team or two. Where the rhythms clash, you separate the delivery. Where they align, you reap the synergy. The table stays shared either way.

Keep checking

Because this is a balance and not a fixed state, put it on a cadence. Every few months, ask the same three questions:

Where is thinking together clearly paying off — and should we integrate more tightly?
Where is it creating friction — and should some delivery run on separate tracks?
Where have the preconditions changed — a new AI initiative, a domain that has matured — so that yesterday's split is today's synergy?

These are governance-forum questions, which is fitting: the same table that answers the use-case questions also answers the question of how integrated to be.

Conclusion

The expensive mistake is not choosing Data Mesh or hub-and-spoke. It's running them as two organizations that meet the rest of the company twice. Both grew from the same root and settle into the same shape; both answer to the same cross-cutting teams; both serve the same end-to-end value streams. Give them one organization — and, above all, one table — and let everyone answer the important questions once.

Beyond EBUCorePlus: Why Leaner Ontologies and Data Autonomy Win the Streaming War

Mon, 16 Feb 2026 00:00:00 GMT

In the current media landscape, the “Streaming War” isn’t just fought with content; it’s fought with speed. For traditional TV broadcasters, the ability to launch a new product feature or pivot a digital strategy in weeks—not years—is the only way to stay relevant against tech-native giants.

But there is a silent killer of speed in our industry: the quest for the perfect, universal data model.

The Need for Speed (and Real-Time Insights)

To compete, two things must happen:

Rapid Innovation: New product ideas must move from whiteboard to production without being suffocated by endless “alignment meetings.”
Instant Feedback: We need to analyze the success of these ideas in real-time. If a new recommendation algorithm or a UI change isn’t working, we need the data to tell us now, not in next quarter’s report.

Domain-Driven Design: Breaking the Alignment Marathon

Traditional Enterprise Data Models (EDM) aim for a single “source of truth” where every term is defined globally. In a complex TV station, this is a trap. A “program” means something different to the licensing department than it does to the playout team or the ad-sales department.

By adopting Strategic Domain-Driven Design (DDD), we recognize that a “Ubiquitous Language” only works within a specific domain boundary.

Autonomous Teams: When teams own their domain language, they gain high development speed.
Reduced Friction: Alignment only happens at the borders.
Analytical Power: By extending this autonomy into the analytical space through Data Products, teams can make data-driven decisions locally and quickly.

Govern the Joins, not the Attributes

Industry standards like EBUCore+ are impressive, but they are heavyweight. They define so many entities and attributes that implementing them across an entire organization feels like a marathon with no finish line.

My proposal? Radical reduction. Data Governance should focus on a minimal central ontology—identifying core entities (like a “Creation” or “Asset”) and their global Identifiers.

Keep it lean: Don’t mandate a hundred attributes.
Focus on connectivity: As long as every system can respond to a specific ID, the data can be linked.
The Golden Rule: Govern the joins, not the attributes. This allows small teams to innovate without waiting for a central “Data Pope” to approve their local schema.

Search is the New Archive

We need to stop obsessing over rigid, structured archive metadata formats for every single item. Instead, we should embrace a discovery-first approach:

Central Search Layer: Collect data in a central search index. It doesn’t matter which piece of information you bring to the table—if it’s in the index, you find the item.
Pointer Strategy: The search result simply points to the source system(s) or the archive where the physical asset resides. This turns the archive from a data silo into a searchable resource.

The Role of Enterprise Architecture (EA)

There is often a gap between Data Governance and the actual tech stack. Data Governance excels at stewardship and business alignment, but it often lacks the technical depth to shape operational systems.

This is where Enterprise Architecture (EA) comes in. Using frameworks like TOGAF, EA looks at the big picture:

Business Architecture: Does this data flow support the actual process?
Application & Infrastructure: Can the system handle the bandwidth and latency requirements? Is the API gateway scalable?

While Data Governance provides the “what” and the “why,” EA provides the “how.” An EA-driven approach ensures that data principles are not just decorative PDFs but are technically enforceable and aligned with the overall IT strategy.

Conclusion: From Control to Enablement

The era of the monolithic, slow-moving data department is over. To succeed in the streaming war, we must trade total central control for governed autonomy. By focusing on lean ontologies, unique identifiers, and a holistic Enterprise Architecture, we stop building data silos and start building a high-speed data highway.

We don’t need everyone to speak the exact same language; we just need to make sure they can talk to each other when it matters.

Web App “Lyrics to Morse Code and MIDI Generator”

Tue, 13 Jan 2026 00:00:00 GMT

When I am not working or spending time with my family, I spend lots of my time playing music.
As a bass guitar player, I mostly create instrumental music and think in terms of rhythm, harmony, and melody.
I like lyrics, but I can’t sing well, so years ago I thought it would be cool to have an app that takes text as input, translates it into Morse code, and exports this as MIDI file. I can then import that file into my Digital Audio Workstation (DAW). There, I can change the pitch of the notes to create melodies while preserving the rhythm to keep the lyrics hidden in Morse code. This allows me to include the text with my songs and tell listeners what the music is about.

I wrote the app in Python ten years ago and used it for my personal projects. As I’ve been testing AI assisted coding lately, I rewrote the app as a small web app in JavaScript, HTML and CSS.

Now you can enter text, get the real-time Morse code translation and at the same time see the musical notation of your lyrics. The result can be played as audio or downloaded as PDF or MIDI file.

You find the app here: https://aaulich.github.io/Lyrics-to-Morse-Code-and-MIDI-Generator/

I used PyCharm as my IDE and Junie as AI assistant. The developer experience was great, though I had to manually adapt some parts of the code. Debugging errors still seems to be a challenge for the tools, but when you read this things might already behave much better.

Digital Sovereignty for CIOs: From a Vague Fear to a Board-Ready Decision

Wed, 08 Oct 2025 00:00:00 GMT

Imagine you are the CIO. In the morning news there is another headline about data-protection frameworks, another about a cloud price increase, another about a service being discontinued. A board member forwards you one of them with a single line: “How exposed are we here?” And they want a founded assessment and a decision paper in four weeks.

This is a genuinely uncomfortable question, because the honest first answer is: it depends. And that is not evasion — it is the key to the whole problem. A dependency, on its own, is not a risk. Risk only arises in context. Depending on a US hyperscaler is not automatically dangerous; it becomes dangerous, or doesn’t, depending on what you use it for, how critical that is, and how easily you could do it another way. The job is to make that context explicit, quickly and defensibly. That is exactly the kind of translation Enterprise Architecture exists to do.

Why the question is on the table at all

The concern isn’t manufactured. Several things stack up:

Legal exposure. The CLOUD Act can oblige US providers to hand over data even when it is stored in the EU. The legal basis for EU–US data transfers has already been struck down once (Schrems II), and the framework that replaced it is not guaranteed to survive.
Market concentration. A small number of hyperscalers hold enormous power, which creates lock-in — the more you use their unique features, the harder and more expensive it is to leave.
Operational and strategic control. Outages, discontinued services, or a provider simply changing direction can put critical processes at the mercy of decisions made far outside your company.

The mistake is to treat this as an IT problem. It isn’t. It is a business problem that happens to be expressed in technical terms — which is precisely why leadership needs a translator.

Four scenarios, assessed on their own terms

Rather than argue about how worried to be in the abstract, I look at concrete scenarios and ask what each would mean for the business:

The data-transfer framework falls. Transatlantic data flows lose their legal basis.
Prices rise, exploiting lock-in. A provider raises the price of a feature you can’t easily replace.
A service is discontinued or withdrawn. Something you depend on operationally simply goes away.
Nothing changes at all. Even the status quo carries the standing CLOUD Act exposure for EU-stored data.

Each of these has a different probability and a different impact, and they deserve to be plotted as such rather than lumped into one anxious feeling.

The Enterprise Architecture approach

Here is the concrete method behind that picture.

Clarify the scope first. Four weeks is not long, so the first move is a scoping funnel. Which company goals are actually in play? Are we looking at infrastructure (IaaS/PaaS) or also at SaaS such as office and collaboration suites? Which providers? Which risk dimensions — technical, financial, legal, strategic? A sharp scope is what makes the deadline achievable.

Make the dependencies visible. You cannot assess what you cannot see. The raw material is usually already in the building: an EA-management tool (LeanIX, ardoq, or similar), the configuration/asset database, and — indispensably — conversations with the architects and developers who actually know how things hang together.

Assess each service on two axes. For every relevant service I ask two questions: how business-critical is it, and how replaceable is it? Those two axes are what turn a flat inventory into a judgement. A critical service with an easy alternative is a very different problem from a critical service with none.

Aggregate up to business capabilities. Individual services don’t mean much to a board. So I roll the assessment up to the level of business capabilities and present it as a heatmap. Now the conversation is about “our procurement capability has a critical, hard-to-replace dependency,” not about a line item called EC2.

Derive measures across three horizons, and tie them to goals. An analysis without recommendations is worthless. So the paper ends with concrete options, sorted by time horizon:

Short term: formally document and accept the risk on uncritical services; commission a deeper review for anything in the red zone.
Medium term: mandate multi-cloud for new projects; build an exit strategy or a proof-of-concept with an alternative for a specific critical application.
Long term: evaluate a sovereign or private-cloud option for core data; anchor “sovereignty by design” as an architecture principle so new systems don’t quietly recreate the same exposure.

Every one of these ties back to an official company goal, so the board is deciding about the business, not about infrastructure trivia.

What this really shows about Enterprise Architecture

Notice what happened. We started with a diffuse, slightly panicky question and ended with a two-axis assessment, a capability heatmap, and a sorted list of options with costs and horizons. Nothing about the underlying uncertainty changed — the frameworks are still fragile, the providers still powerful. What changed is that the organization can now act.

That is the heart of the job. Our task as architects is to be translators: we turn technical facts into business risks and strategic options. Enterprise Architecture turns uncertainty into the ability to act — and that is worth far more than any single answer about the cloud.

If you want to go deeper on the CIO’s questions around digital sovereignty, INNOQ has two openly available pieces I’d recommend: CIO-Fragestellungen zur digitalen Souveränität and the Digitale Souveränität briefing.

CIO-Fragestellungen zur digitalen Souveränität – Mit Enterprise Architektur geopolitische Risiken meistern

Fri, 04 Jul 2025 00:00:00 GMT

Im INNOQ-Blog habe ich einen Artikel mit dem Titel “CIO-Fragestellungen zur digitalen Souveränität – Mit Enterprise Architektur geopolitische Risiken meistern” veröffentlicht.

Ich versuche darzustellen, wie Sie die Enterprise Architektur dabei unterstützen kann, Ihr Risiko bezüglich der Nutzung von US-Cloud-Services strukturiert zu bewerten und daraus passende Aktionen abzuleiten.

Warum das Öffentlich-Rechtliche Fernsehen heute so wichtig ist

Fri, 31 Jan 2025 00:00:00 GMT

Der öffentlich-rechtliche Rundfunk als ausgleichendes Medium. Dieses Bild wurde mit Hilfe von ChatGPT erstellt.

TL;DR. Die meisten von uns nehmen über den Tag verteilt große Mengen vielfältiger Informationen auf, die uns über unterschiedliche Kanäle gezielt zugespielt werden. Provokante oder extreme Positionen werden in vielen Medien bevorzugt, da sie längere werbe-relevante Aufmerksamkeit binden. Dadurch gewinnen wir den Eindruck, dass die Positionen der Menschen immer weiter auseinander gehen, und nehmen außerdem selbst eher eine Position jenseits der Mitte ein.
Das öffentlich-rechtliche Fernsehen hat hingegen den staatlichen Auftrag unseren Horizont zu erweitern und außerdem keinen Auftrag unsere Aufmerksamkeit längstmöglich zwecks Werbeverkäufen zu binden, wodurch ein gemäßigteres Weltbild mit mehr Verständnis für Andersdenkende gefördert wird.
Dies ist demokratiefördernd und erfüllt damit eine höchstwichtige gesellschaftliche Funktion.

Das Ringen um Aufmerksamkeit

Im öffentlichen Raum hängen vielerorts Plakate, die uns Produkte nahebringen wollen oder uns auffordern eine bestimmte Partei zu wählen. Geschäfte werben an Gebäuden mit ihren Namen, um uns zum Einkaufen in ihren Räumen zu animieren. Auf dem Handy werden uns auf TikTok, Instagram, Facebook, YouTube und vielen anderen Social Media-Kanälen Videos und Fotos angezeigt, um unsere Aufmerksamkeit zu binden und uns zwischendurch Werbung anbieten zu können.

Über persönliche Nachrichten-Apps wie WhatsApp, Signal oder Telegram werden Bilder und Videos geteilt, die teils unterhalten, teils auch meinungsbildend wirken sollen.

In dieser Fülle an Informationen mit einer Botschaft wahrgenommen zu werden, ist eine Herausforderung.

Schauen wir uns zum Beispiel den aktuellen Wahlkampf an. Wir haben mehrere Parteien zur Auswahl, die um unsere Stimmen werben. All diese Parteien müssten sich im Falle des Wahlsiegs gleichermaßen um zentrale Infrastrukturfragen als Grundlage für Mobilität und Kommunikation kümmern, ebenso wie um Bildung, Gesundheit, Erhaltung des Lebensraumes und vieles mehr.
Wie sie das genau realisieren wollen, unterscheidet sich von Partei zu Partei, aber es gibt dennoch viele Aufgaben, die sehr ähnlich gelöst werden müssten. Darüber hinaus unterscheiden sie sich in einigen Punkten teilweise grundlegend. Die einen wollen die Situation für Arbeitgeber verbessern, andere sehen eher die Arbeitnehmer als Zielgruppe, weitere wollen die Natur schützen und andere wollen die Zuwanderung begrenzen.
Beim Buhlen um Wählerstimmen erreicht man keine große Aufmerksamkeit, wenn man Dinge fordert, die auch alle anderen bejahen. Stattdessen werden die Dinge, die eine Partei anders als alle anderen machen will, in den Vordergrund gestellt. So können die Mitbewerber darauf reagieren, um sich abzugrenzen, und es entsteht eine öffentliche Diskussion, in der alle Seiten mit ihrer Position wahrgenommen werden.
Wir nehmen daher überwiegend Diskussionen über die Unterschiede der Ideen war, obwohl die Chancen gut stehen, dass die meisten Parteien einen großen Teil der zukünftigen Entscheidungen mit ähnlichen Ergebnissen treffen würden.
Unterschiede werden in der Kommunikation also wichtiger als Gemeinsamkeiten. Auch dann, wenn die Gemeinsamkeiten insgesamt überwiegen.
Es gehört zu den Aufgaben der Medien, Gemeinsamkeiten und Unterschiede der Positionen herauszuarbeiten, sie gegenüber zu stellen und zu vergleichen sowie Machbarkeiten und zugrundegelegte Informationen auf den Wahrheitsgehalt hin zu überprüfen.

Die Interessen der Social Media-Anbieter

Ob politische Positionen medial geprüft und in Kontext gesetzt werden, und ob sie eine hohe Reichweite erhalten, hängt davon ab, über welche Kanäle sie verbreitet werden.

Ein Social Media-Anbieter, der sein Geld ausschließlich durch Werbeeinnahmen verdient, wird ein Interesse haben, den Benutzer möglichst lange an seinen Dienst zu binden. Je länger pro Tag ein Anwender vor dem Bildschirm sitzt, desto mehr Werbung kann der Anbieter einblenden, und desto mehr Geld verdient er. Eine unaufregende Nachricht über erwartbare Gemeinsamkeiten wird wenig Reaktionen hervorrufen. Eine provokante Aussage hingegen fordert eine Gegenreaktion oder Unterstützung ein, wodurch Diskussionen entstehen, die von vielen verfolgt werden und die Nutzer zeitlich binden. Dadurch wird mehr Werbung ausgespielt und die Einnahmen des Anbieters steigen.

X und Meta wollen die Inhalte ihrer Benutzer nicht mehr filtern, weil sie damit die Redefreiheit fördern wollen. Jedoch führt nicht allein die Veröffentlichung einer Meinung zu Reichweite, sondern vor allem die Verbreitung der Nachricht durch Empfehlungsalgorithmen. Diese zeigen den Benutzern gezielt Inhalte, die sie lange vor dem Bildschirm halten sollen, um Werbeeinnahmen zu generieren. Und das ist mit provokanten oder gar extremeren Inhalten leichter möglich als mit gemäßigten Inhalten.

Gilt es als Redefreiheit, wenn jeder auf einer Plattform alles veröffentlichen darf, aber nur bestimmte Inhalte vom Empfehlungsalgorithmus den Benutzern in großer Zahl zugespielt werden?

Zersplitterung der Gesellschaft

Wenn wir immer mehr die Unterschiede zwischen politischen Positionen wahrnehmen anstelle der Gemeinsamkeiten und auch kein Verständnis mehr für die Hintergründe anderer Meinungen entwickeln, wird ein Zusammenleben immer schwieriger werden.

Social Media-Inhalte haben heute eine sehr große Reichweite, und in der medialen Wahrnehmung insgesamt spielen extreme Positionen eine immer größere Rolle.

Wenn vor allem sich gegenüberstehende Positionen gezeigt werden und weniger die Gemeinsamkeiten, werden sich viele Menschen zwischen diesen Polen entscheiden und die Kluft zwischen den Meinungen kann sich dadurch vergrößern.

So wird das Zusammenleben von Menschen, die sich zwischen extremen Positionen entscheiden, immer schwerer. Und auch eine politische Koalition zwischen Parteien, die sich im Wahlkampf bekämpfen und die Zusammenarbeit ausschließen, wird nach der Wahl nicht leichter.

Was wir brauchen, ist eine gemeinsame Basis als Grundlage für unser Zusammenleben. Die Akzeptanz anderer Meinungen und das Bewusstsein, dass die Vielfalt an Ideen eine Stärke ist, die es uns erlaubt, besser mit der sich ändernden Welt umzugehen.

Was trägt das Öffentlich-Rechtliche Fernsehen bei?

Das öffentlich-rechtliche Fernsehen hat gemäß §26 Absatz 1 Medienstaatsvertrag einen klaren staatlichen Auftrag:

Auftrag der öffentlich-rechtlichen Rundfunkanstalten ist, durch die Herstellung und Verbreitung ihrer Angebote als Medium und Faktor des Prozesses freier individueller und öffentlicher Meinungsbildung zu wirken und dadurch die demokratischen, sozialen und kulturellen Bedürfnisse der Gesellschaft zu erfüllen. Die öffentlich-rechtlichen Rundfunkanstalten haben in ihren Angeboten einen umfassenden Überblick über das internationale, europäische, nationale und regionale Geschehen in allen wesentlichen Lebensbereichen zu geben. Sie sollen hierdurch die internationale Verständigung, die europäische Integration, den gesellschaftlichen Zusammenhalt sowie den gesamtgesellschaftlichen Diskurs in Bund und Ländern fördern. Die öffentlich-rechtlichen Rundfunkanstalten haben die Aufgabe, ein Gesamtangebot für alle zu unterbreiten. Bei der Angebotsgestaltung sollen sie dabei die Möglichkeiten nutzen, die ihnen aus der Beitragsfinanzierung erwachsen, und durch eigene Impulse und Perspektiven zur medialen Angebotsvielfalt beitragen. Allen Bevölkerungsgruppen soll die Teilhabe an der Informationsgesellschaft ermöglicht werden. Dabei erfolgt eine angemessene Berücksichtigung aller Altersgruppen, insbesondere von Kindern, Jugendlichen und jungen Erwachsenen, der Belange von Menschen mit Behinderungen und der Anliegen von Familien. Die öffentlich-rechtlichen Angebote haben der Kultur, Bildung, Information und Beratung zu dienen. Unterhaltung, die einem öffentlich-rechtlichen Profil entspricht, ist Teil des Auftrags. Der Auftrag im Sinne der Sätze 8 und 9 soll in seiner gesamten Breite auf der ersten Auswahlebene der eigenen Portale und über alle Tageszeiten hinweg in den Vollprogrammen wahrnehmbar sein.

Die Mediatheken der ARD und des ZDF haben ihre Empfehlungsalgorithmen bereits darauf ausgerichtet, die Informationsblase der Benutzer möglichst aufzuweichen: https://algorithmen.zdf.de/dashboard, https://www.ard-media.de/media-perspektiven/publikationsarchiv/2018/artikel/wie-koennen-empfehlungssysteme-zur-vielfalt-von-medieninhalten-beitragen/ und Teile des Empfehlungssystems sind als Open Source einsehbar: https://github.com/zdf-opensource/recommendations-pa-base.

Das bedeutet, dass die Öffentlich-Rechtlichen Sender bereits durch entsprechende Empfehlungsalgorithmen versuchen ihren Zuschauern eine große Bandbreite an Inhalten zuzuspielen, die ihre Filterblase vergrößern oder auflösen können.

Was könnten die Öffentlich-Rechtlichen noch tun?

Das Angebot zur Vielfalt funktioniert zumindest technisch über die eigenen Mediatheken, aber wird damit ein ausreichend großer Teil der Bevölkerung erreicht? Und nehmen genug Zuschauer das Angebot an ihren Horizont zu erweitern?
Die Otto Brenner Stiftung (gehört zur IG Metall), beschreibt dazu, wie sich die Öffentlich-Rechtlichen an die Gepflogenheiten der verschiedenen Social Media-Plattformen anpassen, um dort Reichweite zu erzielen: https://www.otto-brenner-stiftung.de/fileadmin/user_data/stiftung/02_Wissenschaftsportal/03_Publikationen/AH110_OERM_Soziale_Medien_Vierseiter.pdf.

Wenn Reichweite erzielt werden soll, müssen Inhalte dort ausgespielt werden, wo die Menschen Medien konsumieren. In einem Format, das zum jeweiligen Kanal passt. Gleichzeitig muss der öffentlich-rechtliche Auftrag erfüllt werden, was schwierig ist, wenn Empfehlungssysteme der gewählten Kanäle (Instagram, YouTube, Facebook, …) andere Ziele verfolgen.

Um herauszufinden, wie dieser Spagat geschafft werden kann, bedarf es Experimente, deren Erfolg gemessen wird, um weitere Handlungen daraus abzuleiten.
Dazu kann es nützlich sein, den öffentlich-rechtlichen Auftrag in konkrete Ziele zu übersetzen und für die Erreichung dieser Ziele Messdaten zu bestimmen, die erfasst und ausgewertet werden können.

Mich würden zum Beispiel folgende Versuche und Zahlen interessieren:

Wie viele Zuschauer erreiche ich mit einem Beitrag auf welcher Plattform?
Wie alt sind die Zuschauer?
An welcher Stelle des Clips steigen sie ein, wo steigen sie aus?
Was ist an diesen Stellen des Beitrags passiert?
Inwieweit unterscheiden sich die oben genannten Ergebnisse, wenn ich unterschiedliche Beitragsvarianten A/B teste?
Inwieweit kann ich den Horizont meines Zuschauers erweitern?
- Z.B.: konnte ich neue Rubriken empfehlen, die der Zuschauer auch genutzt hat?
- Konnte ich dem Nutzer zum selben Thema eines Beitrags, den er gesehen hat, einen Beitrag mit einer ganz anderen Position schmackhaft machen?
Kann ich die Zuschauer mit Inhalten, die ich auf anderen Kanälen oder Plattformen ausspiele, in die Mediatheken locken?
Falls ja: mit welchen Inhalten auf welchen Kanälen?

Wahrscheinlich gibt es viele weitere Fragen, die zu stellen und zu beantworten sich lohnt.

Fazit

Öffentlich-rechtliche Medien haben eine zentrale Rolle in der Demokratie: Sie können Polarisierung entgegenwirken und eine gemeinsame Diskussionsbasis schaffen. Doch sie müssen ihre Reichweite in den sozialen Medien weiter ausbauen, um möglichst viele Menschen zu erreichen. Dazu braucht es Experimente und datengestützte Strategien.

Die Herausforderung dabei: Wie bleibt man relevant, ohne sich den Logiken kommerzieller Plattformen zu unterwerfen?

Doing the Right Things — with Enterprise Architecture

Thu, 05 Dec 2024 00:00:00 GMT

When we want to sell something to a customer, a handful of things have to be true at the same time. The product has to do what the customer actually wants. It has to be good enough. The price must not exceed the value the customer gets from it. It has to be available quickly enough to matter. And there should be no comparable product that beats ours on any of these points.

Almost everything a company does is, in the end, in service of getting offers like that to market. So here is a fair question: how can Enterprise Architecture help make sure all of those conditions hold?

To answer it, I want to avoid the trap Enterprise Architects usually fall into. We love to talk in pictures. We ride the elevator between the top floor and the machine room. We are the city planners, while domain architects plan the districts and solution architects design the individual buildings. These images are nice, and because they are so abstract they are always a little bit true — which is exactly why they are useless when someone asks what we concretely do on a Tuesday morning. So let me walk through the concrete work instead.

Enterprise Architecture is not a role — it is the structure of the company

First, a definition that changes how you read everything below. Enterprise Architecture is not a person with "architect" in their title. It is the structure of the company: how business capabilities, processes, data, applications and technology fit together to pursue the company’s goals. That structure exists whether or not anyone tends to it. It is realised through many roles — product people, engineers, governance, security, and yes, sometimes a dedicated Enterprise Architect.

That means shaping the architecture is a shared task. The Enterprise Architect’s job is to take on the parts of that task that no other role is currently covering — connecting the goals at the top with the work in the machine room, so the two tell the same story.

The real problem: too many possible things to do

Here is where most initiatives quietly go wrong. It is rarely that a company has nothing to do. It is that it has far too much it could do, and no shared, explicit basis for choosing. Every department has a backlog. Every leader has a conviction. The list of possible activities is effectively infinite, and the budget is not.

So the job breaks down into four questions:

What are the company’s actual goals?
Out of everything we could do, which initiatives genuinely pay into those goals?
Which of those are feasible with what we have?
How do we implement the chosen few and know whether they worked?

A structured way to move through those questions already exists. In TOGAF it is called the Architecture Development Method, the ADM. I don’t apply it as a rigid ritual — a framework followed to the letter becomes a bottleneck, and the goal disappears behind the method. I use it as a checklist for thinking, and I keep an elevator pitch ready at every step for why the current work pays into the company’s goals.

Walking the cycle, with the goal always in sight

Imagine a company that has decided it wants to grow by wrapping a digital service around a product it already sells physically. That is the strategic intent. Now what?

Set the vision. We start by getting the mandate clear — who is sponsoring this, to what end — and by describing the target in a single picture leadership can recognise as theirs. If we cannot say in two sentences how this initiative supports a company goal, we stop here. That is a feature, not a delay.

Understand the business first. Before anyone talks about systems, we map the business capabilities the new service needs, and how they connect to the value the company delivers to its customers. This is where you find out that the exciting idea depends on a capability the company doesn’t actually have yet — much cheaper to learn now than after the build.

Then the information and application layer. What data has to flow, from where to where, and in what time? Which applications produce and consume it? Here we deliberately look for the smallest coherent slices — data products and services that teams can own — rather than one grand model everyone has to agree on before anything ships.

Then technology. Only now do we look at the technical foundation: platforms, infrastructure, the constraints that are real versus the ones that are merely habit.

Find the options and choose. With the gap between today and the target visible, we identify concrete initiatives to close it, and we prioritise them against each other — by contribution to the goal, by feasibility, by what unlocks what. The output is not a wish list; it is a sequenced set of the few things worth doing first.

Plan the migration, then govern the build. We turn the chosen initiatives into a roadmap and, crucially, stay involved while it is built — not as the people who overrule teams, but as enablers who keep the delivered thing pointed at the vision. An Enterprise Architect can be a requester, an enabler, or an overruler; enabler is the one that works.

Measure, and adapt. Finally we make the effect visible: did the initiative move the goal it promised to move? What we learn feeds straight back into the next turn of the cycle.

Why this is worth the effort

The payoff is simple, and it is the reason I do this work at all. When a company knows its goals and chooses its initiatives against them, it stops pouring time and money into directions that don’t matter. And it gets from an idea to a relevant offer in the market faster, because the energy isn’t spread across everything — it is focused on the things that count.

That is the whole point, and it is easy to state without any architecture vocabulary at all: figure out what is important, and make sure it happens.

How to Actually Land an AI Strategy

Fri, 11 Oct 2024 00:00:00 GMT

Most conversations about AI strategy start with models and tools. In my experience that is the wrong end. The initiatives that stall rarely stall because the technology couldn’t do the job. They stall because nobody had a clear mandate, because the work was never tied to a goal the company actually cares about, or because — six months in — no one could show what any of it was worth.

So the approach I use puts the organization first and the technology second. It has five steps, and although I’ll list them in order, in practice they interleave: you learn something about a use case that changes your view of the foundation, and you loop back.

1. Get your mandate

Before anything else, get an explicit mandate — and make sure it is the right mandate. Specifically, make sure it includes looking at organizational approaches, including how people collaborate, and not just at buying technology. An AI initiative that is only allowed to touch the tech stack, and not how the company is set up to use it, is missing most of the levers that decide success.

2. Identify the goals

Tie every AI initiative to a company goal. This is the single most useful discipline in the whole method, because it is what keeps the work visible and funded. If each project or product can point to the company goal it serves, the relevance of your AI portfolio stays obvious to the people holding the budget.

It helps to know the small set of goals AI initiatives usually serve. I work with six:

Efficiency — the same result with fewer resources, or a better result with the same resources.
Turnover — enabling or growing revenue.
Quality — better outcomes, fewer errors.
Agility — responding to change faster.
Innovation — making genuinely new things possible.
Employer branding — being a place skilled people want to work.

Naming the goal a use case serves sharpens it immediately, and it makes the later job of measuring impact far easier.

3. Build the organizational and technical foundation

This is the step that gets skipped, and it is the one that matters most.

On the organizational side:

Build a cross-functional core team — data and AI specialists, developers, domain representatives, and Enterprise Architects who understand how the company’s parts, its data, and its ideas actually connect. Add a strong sponsor.
Establish a decision-making body so the initiative has real authority and a clear path to yes.
Embed AI into the company’s existing project and product processes: how budget gets approved, how work is prioritised, how it is governed. AI that lives in a side process stays a side project.
Make progress visible, and invest in internal communication so staff and management understand what is happening and why.

On the technical side, the recurring theme is that data has to be able to flow through the company and be available in time. That means deciding how data is provided (centrally, decentrally, or a mix), making existing data structures discoverable, keeping data quality high, and giving teams both AI use cases and the technical foundations to build their own.

4. Identify and realise use cases

Now collect use cases — and be deliberate about sequencing them. Identify a few quick wins and lighthouse projects early. Their job is not only to deliver value but to keep management support high while the harder, slower work matures. One caveat I’d add from experience: aim your lighthouse projects at real, customer-facing value, not just at internal templates. A lighthouse that only impresses the people who built it doesn’t hold attention for long.

5. Measure the impact and make it transparent

Finally, make the value visible — including the honest, awkward parts.

A simple technique works well here. For each initiative, tag how much AI actually contributed:

Would not be possible without AI.
Would be noticeably less successful without AI.
AI’s contribution is irrelevant.

This is more useful than a single headline number, because it tells the truth in both directions. It shows where AI is genuinely decisive — and it stays credible by admitting where most of the value came from somewhere else. That honesty is what lets the numbers survive scrutiny, and surviving scrutiny is what keeps the next year funded.

The through-line

Read back over the five steps and you’ll notice the technology is only one of them. Mandate, goals, organization, sequencing, and honest measurement do most of the work. That is not an argument against taking the technology seriously — it is an argument for organizing data and AI around the value the business actually creates, rather than treating it as a clever silo off to the side. Get that right, and the models have something worth doing.

INNOQ Podcast “Enterprise Architektur”

Wed, 21 Aug 2024 00:00:00 GMT

We have just released our new INNOQ podcast episode “Enterprise Architektur – Vom Elfenbeinturm ins Clubhaus“.

Anja Kammer and I talk about how Enterprise Architecture can support companies to make sure IT supports their company goals and strategy. Again, this podcast is in german.

The main message of this podcast is that EAs need to understand the needs of all stakeholders and players affected by a change and find a solution that addresses most of these needs. Therefore being an EA means understanding the organization, the roles involved and -often forgotten- the individual persons fulfilling those roles.

EAs don’t take decisions alone and on their own and then enforce their implementation, but instead shall enable other architects, developers and other persons involved to take their own informed decisions.
In Team Topologies speech modern EA teams do their work as enabling teams.

In easy terms: be accessible, friendly, smile and help others grow.

A Company Is Organized Conflict

Fri, 23 Feb 2024 00:00:00 GMT

A company is organized conflict.

I don’t mean that cynically. I mean it structurally. Marketing wants reach and speed. Finance wants cost control and predictability. Legal wants risk kept small. The people function wants the organization to stay healthy and able to keep its staff. Each of these is a legitimate goal, and they routinely pull in opposite directions. That tension is not a malfunction of the company — it is the company. Organizing that conflict productively is a large part of what management, and enterprise architecture, is actually about.

And it gets one layer more complicated, because departments are made of people. On top of the departmental goals sit the individual goals of the people involved: someone wants to prove a point, someone wants a quieter quarter, someone wants the project they championed to succeed. If you only look at the org chart and the official department objectives, you are reading half the map.

The two weak ways out

When goals collide, most organizations reach for one of two moves.

The first is escalation to a decider. Push the conflict up until someone senior enough picks a side. The second is escalation to a committee. Convene the stakeholders, take a vote or a majority, and declare the matter settled.

Both produce a decision. Neither produces movement.

The problem is the same in both cases: the people who were overruled walk away with little or no commitment to the outcome. They comply, at best. They were not convinced; they were outvoted or overridden. And a plan that half the room is quietly unconvinced by is a plan that stalls in a hundred small ways nobody can quite point to. This is why you so often see the frustrating pattern where everything has been planned well — the organization and the technology alike — and still nothing moves.

Understanding enlarges the solution space

There is a better move, and it is slower up front and far faster over the life of the initiative: enlarge the space of possible solutions until there is one that everyone can genuinely stand behind.

You do that by understanding people — really understanding them, past the position they are defending to the need underneath it. Positions conflict. Needs often don’t. Two people arguing over the same narrow option can frequently both be satisfied by a third option neither had seen, once you understand what each of them actually needs it for.

Abraham Lincoln is supposed to have said, “I don’t like this man. I must get to know him better.” That is the whole discipline in one sentence.

Concretely, this is the work:

Spend time with people, ideally one to one. The real interests rarely surface in a room of twelve.
Question what was said in order to understand what was meant. People state positions, not needs. The stated demand is a clue, not the answer.
Look for the need beneath the department goal and beneath the personal goal. Both are real; both have to be in the solution.
Invest in empathy. The better you understand someone, the less time this whole process takes — understanding is not the soft part of the work, it is the accelerator.

As the overlaps between people’s real needs become visible, the solution space grows. Somewhere in that enlarged space there is usually a superordinate goal — one everyone recognises as worth more than the local fight — and an action that pays into it that each party can carry.

A recipe I keep coming back to

When I am in the middle of one of these situations, I try to hold on to four steps:

Understand the said, the meant, and the underlying needs of everyone involved.
Find options in the overlaps that emerge once those needs are on the table.
Choose one — a common action tied to a shared, superordinate goal.
Act.

It looks obvious written down. It is not what most organizations do under pressure, where the reflex is to jump straight to step three by vote or by decree and skip the understanding entirely.

Why an architect cares about this at all

You might expect an Enterprise Architect to be preoccupied with capabilities, data flows and target pictures — the boxes and lines. I am. But I have watched beautifully argued architectures die because the people who had to live with them never wanted them, and I have watched modest plans succeed because everyone involved had a real stake in them.

So I have come to treat this as part of the architecture, not separate from it. The structure of a company is not only its processes and its clearly assigned responsibilities. It is also the individuals inside those roles, with their own goals — and designing for the individuals, not just the roles, is very often the difference between a structure that holds and one that quietly falls apart. Understanding people is not a detour from the real work. On this kind of problem, it is the real work.

Migrate P5 Archive Server to the Cloud

Fri, 19 Jan 2024 00:00:00 GMT

One of my customers has been using Archiware’s P5 Archive server for years to move unused media data from expensive, on-premises, high-performance storage to cheaper second tier storage.

P5 Archive manages archived data very well and is able to preserve all kinds of file- and filesystem-related metadata across all kinds of storage.

Over the years, the customer’s production environment has changed a couple of times to adapt to the availability of new technology, a preference of remote work of employees, and so on.

This article explains what is required to migrate an on-premises P5 server to a new instance (cloud or new on-premises server) when it archives data to S3 storage like WASABI.

Original Setup

Originally we started with a setup like this one:

Employees were accessing files on local production storage, and once a project was finished and related data needed to be preserved, P5 Archive moved data to a local archive storage.

Moving Archive Storage to WASABI/S3

At some stage it became relevant to keep more secure data copies outside the primary production facility while at the same time higher-bandwidth Internet access became cheaper and high-performance and high-reliability cloud storage became available and more price-efficient.

We chose to use WASABI as cloud-based archive storage. Therefore we migrated all archive data to WASABI, while at the same time we kept the P5 Archive server and the production storage on-premises:

P5 handles several S3-compliant cloud storage providers out-of-the-box and WASABI is easy to integrate as archive storage target.

Moving the P5 Archive Server to the Cloud

At some stage we wanted to place the P5 Archive server in the cloud. This was our train of thought:

We wanted to move the US-based WASABI storage to WASABI storage based in the European Union. We needed lots of bandwidth and low-latency between the server and the storage locations.
The on-premises P5 Archive storage was sharing Internet bandwidth with other local services and therefore could only use very limited bandwidth for data operations. In addition the office location was in the southern hemisphere and latency was high when talking to storage servers in the northern hemisphere. This had the effect that copying data from source to target storage was calculated to take almost two years.
Having a P5 Archive server close to the new target storage reduces latency and we chose a hosting service with much more bandwidth than our original on-premises server was able to get. Therefore we hoped to move data from source to target within four weeks.

The target setup we wanted to build was this:

We chose a virtual machine hosted by Hetzner running in a US data center close to the source WASABI storage (CPX31 server, 1TB data storage, 8GB RAM, Ubuntu Linux).

I installed P5 Archive using the normal command-line installer, made sure it was running and that I could access the web interface.

IMPORTANT: Make sure to use P5 7.2 or later on both the on-premise and cloud-based P5 servers before you start the migration. If you work with older versions, the cloud-based server will not be able to restore data from the archive. (P5 7.2 stores some S3-specific info in /usr/local/aw/config/index/archive/Default-Archive/conts.db, and you need that info to make the new server work with your S3 storage).

Then I followed this instruction to copy over the configuration from the old to the new server. Though the source server was running macOS and the target server was running Ubuntu Linux, the migration process looks the same. File paths are identical on both OSes.

Once these things have been done, P5 can access the original storage and restore data to any accessible target storage.

Final Thoughts

The main purpose of this post is to make sure you can migrate a P5 Archive server with S3 storage access to a new instance running anywhere. I hope this has been explained in enough detail.

In the project mentioned here, we used custom code controlling the migration process from a source to a target storage. I have not described how we did this, as this might not be relevant to you. I guess that in most cases it will be more relevant to only migrate the server, not the storage.

If you have any questions or need help with any P5 migrations, please get in touch.

INNOQ Podcast “Alles zu kompliziert”

Thu, 09 Nov 2023 00:00:00 GMT

We have just released our new INNOQ podcast episode “Alles zu kompliziert – Warum unbeabsichtigte Komplexität oft normal ist.” As the title suggests, this is in german.

Sven Johann, Jörg Müller and I talk about why technical solutions become overly complex in certain phases of their lifecycle. We discuss when this kind of complexity starts to hurt and how you can address the challenges that come with it.

Taking Decisions

Thu, 07 Jul 2022 00:00:00 GMT

I guess that most of us know situations, in which we wonder why our partners, colleagues, friends, family, etc. take decisions which we consider really bad choices.
In this post I’d like to examine if those decisions are really that bad or if it’s possible we simply use different measures when judging them.

As a side effect this post shall support you in taking better decisions by making sure you answer all relevant questions.

Definition of Decision-Taking

Before we check a decision for its quality, we need to make sure we have a common understanding of what a decision is and how we can make sure our decisions are good ones.

When you have more than one option of doing something, you have to select one option. I would say that many people think selecting an option is the whole decision-taking process.
I think, though, that taking a decision comprises many additional steps, which take place before you select one of your options:

Identify that you can take a decision.
Find out when the decision is needed.
Identify the purpose of the decision.
Figure out who your decision’s stakeholders are, what their interests are and who can take the decision.
List, prioritize and weigh your requirements.
Identify your options.
Assess the collected options.
Select the option which best matches your requirements.

The order of the steps above might vary slightly, but all points need to be considered, so I would say that the decision-taking process is described by the list above and a decision is the result of this process.

The Decision-Taking Process

Let’s look at the process in more detail and see what the individual steps actually mean.

Room for Choice

It sounds simple: before you consider taking a decision, you must be aware that you can take a decision.
Without knowing that you can choose, you would simply act without deciding.

Let’s look at an example. You ride your bicycle down the street and watch the birds fly around some trees. You don’t see the parking car in front of you and bump right into it.

You have not decided to bump into the car.
If you had seen the car early enough, you would probably have considered other options –like driving around the car– but you have not seen any option, therefore you have not willingly decided to crash into the car.

Another example would be that you have seen the car a few seconds before you crashed into it, but you’ve been so fast, that you could see the crash coming, but could not prevent it anymore. Still no room for choice, and therefore no decision.

In both situations you could argue though, that you have decided to accept risks when you drove too fast or watched the birds in the sky while riding a bike. But you have not decided to crash into that car.

As trivial as it sounds: you need to be aware that you can now take a decision, so that you can start the decision-taking process.

Timing

Sometimes you have to take an immediate decision. Sometimes though, it‘s better to postpone a decision until you have more information. Many people adhere to the saying „A good decision now is better than a perfect decision tomorrow.“ That can be right, but sometimes the opposite is true, too.

Let‘s say your company has built two new product prototypes, but you can only produce one of them, so you have to decide which product you will produce and sell.
You have no idea, yet, which product your customers would prefer over the other. If you choose the wrong product, this might be the end of your company.

Taking a decision now without any relevant information would mean a high risk of 50% if you can only guess.

If you spend another week to do some customer research, you can get much more information and reduce the risk of taking the wrong decision to maybe 20% (it can be very impressive how much you can find out about your business ideas within a single week: https://www.thesprintbook.com/). Depending on your market situation postponing the decision by one week to reduce the risk from 50 to 20% can be very reasonable.

On the other hand, if you have to either sign or not sign a contract, there might be a deadline which simply requires you to take a decision immediately.

Purpose

For which purpose do you take your decision? The quality of a decision can be measured by its effect on its purpose. Let‘s say you want to go home quickly and and have to choose one of three buses. You talk to the drivers to figure out where they go.

If the first bus does not bring you home at all, choosing bus number one would be a bad decision. Buses number two and three bring you home. Number two takes 20 minutes, number three 80 minutes. So both option two and three address the purpose “going home“, while option two addresses the second criteria “quickly“, too, and therefore is the best decision in regards to the defined purpose.

If the purpose was “I want to have a long bus ride without knowing where I‘m going“, the same decision could actually be the worst option.

Therefore knowing the purpose of your decision is an important starting point as it sets the stage for the evaluation of your decision.

Decision-Takers and Stakeholders

To find the best option you need to know who‘s interest a decision shall serve, which interest each affected person has and if it’s you or someone else who can take the actual decision.

Let‘s say you plan your next family vacation. Maybe you can plan the trip alone, but your partner and your kids want to be involved and actually have certain wishes. Your son wants to spend time at the beach, your daughter wants to meet other kids, and your partner controls the budget.
You need to consider their wishes and find a solution that addresses your stakeholders‘ interests if you want everyone to enjoy their vacation.

You also need to find out who can take the decision and who needs to be involved. Maybe you need a decision at work, which can only be taken by your boss or a certain committee. Or you can formally take a decision on your own, but the decision will affect other people‘s work, and if you want them to commit to the decision, you might want to involve them early into the decision-taking process.

Making sure you know your decision‘s stakeholders and involving them as much as needed, but not more, is a crucial aspect of any good decision.

Requirements

Knowing your stakeholders’ interests and wishes is a good starting point. Transforming them into requirements is a discipline of its own, called requirements engineering (there‘s a great book available in german at https://www.hanser-elibrary.com/doi/10.3139/9783446438620.fm).

Basically, when someone tells you e.g. how she wants her new car to be like, she might tell you about an electric engine, the speed, or anything that makes it different from other cars. She might not tell you about the number of wheels, that she wants to lock the car when she‘s not using it, and other features everybody considers standard features. In addition, some features might be standard in the near future, but no-one knows them today. You need to think of these things, too.

Long story short: figure out what your stakeholders need.

In many cases you will find out that with multiple stakeholders some requirements are contradictive and you need to weigh their importance and find a solution which addresses the interests of all your stakeholders. That was a complicated way to say you need to find a compromise if not all requirements can be fulfilled.

Options

Once you know what you and your stakeholders are looking for, search for solutions.

Let‘s say you want to manage a list of your company’s applications and their license states. You can build a solution on your own, purchase a standard application or buy a service provided by a third party. List all options which are candidates to serve the purpose of your decision.

Assessment

Once you have collected a list of options, take a close look at each option and compare it to your requirements. You can use a spreadsheet with all requirements listed in one column on the left and all potential solutions listed in the following columns, where for each requirement you enter if an option fulfills it.

For some requirements you will not be able to say if an option will be able to fulfill it. This is true if a software vendor tells you a feature is on the roadmap or if you don‘t know, yet, if a technical challenge can really be solved or if you need to work around it. In these cases, guess the chance of success and figure out a plan B.

If multiple solutions look like candidates to serve your decision‘s purpose and address your requirements, think about what would happen if you find out you want to change your decision later on.

If switching from plan A to plan B is easy and switching from B to A is hard, plan A gives you more options and would be the better choice if otherwise both options are comparably good.

Selection

The assessment of your options has shown which options support your decision‘s purpose and meet your requirements.

As already mentioned: if you can not predict how an option is going to develop over time, the risk assessment shall be weighed in. If two or more options seem to be equally good, consider how easy it would be to change the decision if you find out that your initial decision was not that good. The question here would be how much flexibility your option provides.

Conclusion

As you see, taking good decision can be a very structured process which is easy to follow.

Yet, answering the questions can take some time, which sometimes you don‘t have. If you have little time and therefore lack good information, risk of being wrong can increase. Or you pick the solution which gives you lots of flexibility so that you can still navigate through the unknown.

As an Enterprise Architect I would add that all decisions in a company shall be aligned with the goals and the strategy of the company. Requirements need to be collected reasonably and all solutions shall be designed with a 360 degree view on the problem. Think well, plan, fail fast, learn and adapt.

What is a Domain and Why Should I Care?

Thu, 21 Apr 2022 00:00:00 GMT

When you work in a company which transforms into an agile organization, sooner or later people start talking about designing teams and technology according to domain boundaries.
Yet, if you ask your colleagues what a domain is, you’ll find out that obviously there is no common understanding of what a domain is.
This article tries to explain how to deal with domains – with a focus on team organization.

Let’s look at Wikipedia first. You’ll find that the term “domain” can mean many different things in different contexts.
In a product organization, you are probably using Scrum as a framework, and Domain-driven Design (DDD) to identify domains which you map to your teams.
So let’s check DDD’s definition of a domain:

“Domain” in Domain-Driven Design officially refers to a “sphere of knowledge and activity around which the application logic revolves”. In other words, the “Domain” is what is commonly referred to as “business logic” in the software world.

taken from https://medium.com/inato/an-introduction-to-domain-driven-design-386754392465

I don’t know if this helps a lot, to be honest. It seems we shall find a department where everyone has the same understanding of terms and processes and everyone more or less works on the same things. If this is our domain, we can build software for the department and dedicate a single team to the development work for this department.

I think this sounds right –somehow–, but it’s still a little bit abstract.
Let’s take a step back.

Lego

Imagine you have a box full of Lego blocks of all colors and sizes and you want to build a car.
Before you begin building, you might want to sort your Lego blocks so that you’ll find what you need quickly while building your car, so that you can focus on the build process instead of searching for matching blocks.
How do you sort your Lego blocks, though?

You can put all blue Lego blocks together, all red ones in another area, and sort all your Lego blocks by color.
Instead you could organize your blocks by form and size. Stack all the 4×2 blocks up in piles, put 2×2 together, and so forth.
You can combine the ordering approaches described above and put all red 4×2 blocks together, next to it the blue 4×2 blocks, etc.
Or you leave all blocks in the box, spend more time searching during the build process but don’t have to spend your time sorting the blocks beforehand.

By sorting your Lego blocks, you actually create domains, and it seems you can create domains based on several criteria.

Sorting Criteria and Purpose

If you can define your own sorting criteria do identify domains, the question is “how do you find the right criteria for your domain separation?”.
Let’s get back to our Lego example.

If you don’t care for the color of your car, you can use Lego blocks of any color. Form and size of the blocks will still be relevant, though. In this case sorting your blocks by color would create extra effort during domain creation, but it would not help you while building your car.
Therefore, in this case sorting your blocks by form and size would help you with your build process later on.
If the car you are going to build shall be of a specific color scheme, finding blocks of the right color will be as helpful as finding the right form and size quickly. It would not be useful to only find blocks of the same color, you will still need to search for the right form and size.
Yet, if you only sort by color, finding the required form and size within that heap might still be easy enough and you would save the time spent for sorting by color, form and size beforehand.
In this case you can either sort by color, form and size or only by color.
To figure out what is best, try out what makes your end-to-end process more efficient. An easy way to figure this out would be to measure the time for sorting by color only and then building the car, and then measure the time for sorting by color, form and size and then building the car. Whatever is quicker is more efficient.
You might consider other factors, too, like “What is more fun? Searching during the build process or searching and sorting beforehand?” Having fun might increase your creativity, so it’s not a given that efficiency is the winning criteria in every situation.

What can we learn from this little example? It shows us that sorting criteria depend on purpose.
This means we first need to understand for which purpose we want to put structure into parts of our organization, and then we can define the criteria which serve that purpose best.
I’ve seen some domain design processes, where the purpose of the design was not clear. If it’s not clear, it’s not useful, so think about purpose before you start designing.

Domain Design for Product Teams

In Domain-driven Design and Scrum-based product organizations our goal is to design teams, which can work on encapsulated business domains, which have all the complexity within their domain and little dependencies on the outside world.
Domains can have subdomains, e.g. an e-commerce domain can have subdomains like product listings, order process, delivery, etc. as subdomains, for which solutions can be developed by dedicated teams.

If our goal is to have autonomous teams, we try to design domains, where most communication can happen within that domain to take decisions, describe processes, etc. The foundation of domain-driven design therefore are business domains.

When designing domains, in many environments a conflict arises: if the teams want to be as autonomous as possible, they have to build the whole solution themselves. This means, that teams end up building redundant solutions for login mechanisms, logging, monitoring, etc.
This costs time and money, so teams decide to share some resources like identity and access management, runtime environments, gateways, CI/CD pipelines, etc. As long as these resources have stable and well-documented APIs and are reliable, available and adaptable, this kind of dependency does not hurt much.
But what happens if the shared resource requires lots of complex inter-team communication, lets the teams only test and deploy all solutions as a whole? That would slow down development instead of accelerating it.

Here the key is to balance autonomy with efficiency in a way that works best for your company.

Overlapping Domains

As mentioned above, in a product-oriented organization with strong customer-focus and agile development approaches the purpose of domain design is creating autonomous teams.
This allows scaling your development by adding as many teams as you like without losing much speed, and with the ability to scale individual solutions independent from other solutions. And it allows shortening times-to-market.

Other domains in your company could be designed to serve other purposes. The challenge here lies in the fact, that within a domain complex communication takes place, in between domains less communication is required.
If domains overlap, complex communication is everywhere and slows down your company.

So let’s say you have five relatively autonomous Scrum teams working on five different applications.
Each team works on a separate business domain and mainly communicates with its business counterpart and within the development team.
Now the Enterprise Architecture team shows up and says all five teams belong to the domain “Product Development Architecture” and the EA team wants to install quality gates, architecture guidelines and principles and hard-wired processes for architecture development.
This would create lots of communication overhead between the Scrum teams and Enterprise Architecture.

At the same time your Security department wants to establish better processes to make your solutions more secure, and again they come with quality gates, processes and people.

Governance might want to do the same, and sooner or later all these overlapping business, security and governance domains create so much communication overhead, that your next release would take place in such a far future that you start thinking becoming an agile company is slowing you down so much that you want to go back to good old waterfall planning…

To reduce the risk of too much communication overhead, you need to find an organizational approach for your company, which balances all the various domain purposes of your various stakeholders.
Company-wide structuring departments like Enterprise Architecture, Governance, Security, etc. can define non-functional requirements for products or set up communities or guilds to establish common goals, standards and principles, so that the teams can preserve their autonomy as much as possible and still provide the quality required by EA, governance, etc.
Of course this depends on many factors like compliance requirements in your business segment, etc.

Conclusion

Yes, I know, I have not explained how to design a domain in detail.
Yet, I hope it became clear that different departments have different interests and therefore might design overlapping domains, which can be an organizational challenge for your company.

Finding a good organizational structure balancing all the conflicting requirements of different departments is a matter of collecting, evaluating and assessing their requirements first, so that you can come up with a solution which best matches your company’s strategy.

Remember that domain design depends on the purpose of your domains. Define your goal first, then the criteria to create the domains which help you reach your goals.

What does an Enterprise Architect do?

Mon, 18 Apr 2022 00:00:00 GMT

Ask a couple of people what they think Enterprise Architects do and you will get greatly varying answers.
If you want to better understand the scope of Enterprise Architecture and if one or more Enterprise Architects can help you and your company in any way, please keep on reading.

Enterprise Architects Help Navigate Through Change

If you look at your company‘s organization, its processes, customers, employees, partners, market opportunities and so forth and see no requirements for any change as your world looks good as it is and no change seems to be coming up, then what would you expect an architect to do? Probably nothing. (Yet, in all my life I have not seen a single company, which has not been faced with changing circumstances at some stage, so this scenario is probably a bit unrealistic.)

If you plan no change, Enterprise Architecture is not required and would only cause costs.

Reduce Costs

Talking about costs: if they are too high and you want to reduce them, you would need someone to make transparent, where and how you can reduce costs. This would probably need an architect to first create an overall picture of your processes, the organization, technology and the relationship between all these things.
Someone would need to identify or even develop the company‘s strategy, so that you can cut off costs, which don‘t support your company‘s strategy and focus more on relevant changes which enable growth following your strategy. This can be done by Enterprise Architecture or other departments like Portfolio/Program Management, Governance, etc., but Enterprise Architects need to know these things at least.
In many organizations lots of energy is wasted on projects which don‘t support the company‘s strategy, and EA creates the transparency, which initiatives are going into the wrong direction, so that you can steer your company in a better way based on facts.
This way you can either adapt the direction or organization of an initiative or even stop some or start new initiatives.

Optimize the Organization

Other changes where EA can help are organizational changes. Let‘s say you want your company to be data-driven, manage IT in a better way, build up an Enterprise Architecture team and build up a product organization which puts the customer in focus and drives innovation.
You hire the first smart people to build up all these things and then they develop their own strategies to build up their departments and try to apply industry-accepted frameworks. COBIT might be used as a framework for IT management, TOGAF for Enterprise Architecture Management, any data-related framework to become data-driven, and Scrum for your product organization (maybe even LeSS or SAFe if you plan big).
If you let all these initiatives develop their own paths and apply the frameworks without adapting them to your company and without merging them into one common organizational approach, your organization will become overly complex and slow with far too many people blocking each other‘s work.
EA‘s task in this scenario would be to prioritize the different initiatives and their tasks against each other and reduce them to an organizational and technical model which serves the company‘s strategy best.
E.g. if you make approval by Enterprise Architecture, Security and Data Governance a requirement for your Scrum team before any new feature can be used in production, this would create complex and long-running processes which would delay your feature development. This is no major problem if these things are a regulatory requirement and apply to all your competitors as well, but they are a serious problem if you are the only company in your market segment which becomes slow due to all the organizational complexity.
EA can align the initiatives with the company‘s strategy and make sure that the relevant parts of these frameworks will be integrated with your company‘s roles and collaboration approaches, while the not so relevant parts of the frameworks will be ignored.

Define Future Technical Structure

In many companies EA is supposed to be responsible for the IT architecture, which for most people is the technical structure, not so much the organizational structure of IT.
Again, as mentioned above, it‘s not about the current state. If nothing needs to change, you don‘t need an architect. It‘s more about “What should our technology landscape look like, and how do we get there going which steps? Where will we be when?“.
Enterprise Architecture develops a target technical landscape as well as a roadmap how to get there. This implies that at some stage you need to understand where you start from, so you will need to collect how your technology landscape looks like today.
As Enterprise Architects collect technical information, too, in many environments EA is seen as a pure IT thing. Yet, EA aligns all IT things with the company‘s strategy, its organization and processes, so I would say, EA is about 50% IT and 50% business (if you can separate the two at all).
Still, some general technical architecture patterns can be developed by the EA team, but in most cases this means close collaboration with solution architects and developers who work in the areas we want to design.

What‘s the Difference between Enterprise, Domain and Solution Architects?

Thanks a lot for asking, this is one of the common questions I get.

Let‘s say your organization develops a handful of software applications, which enable other employees to do their job. Each application is being developed by a dedicated product team, which has all the team members it needs to develop the product.

A Solution Architect would develop the architecture of a single product. This includes defining non-functional requirements as well as balancing all the incoming requirements when developing the architecture of the solution. The Solution Architect needs to be very-well educated regarding decision-taking, so that the proposed solution aligns with the company‘s strategy as much as possible.
The Solution Architect communicates with POs, Business Analysts, Requirement Engineers, UX Designers, Data Governance, Enterprise Architecture, etc. to understand requirements and with the development team to discuss what the proposed solution shall look like.

While the Solution Architect is responsible for a single product, a Domain Architect is responsible for a collection of products. E.g. a domain architect might know everything regarding media management and therefore define solutions for multiple product teams which deal with this topic. The domain architect might have the role of a Solution Architect in multiple teams, or – when each team already comes with a dedicated Solution Architect – the Domain Architect connects the dots and makes sure the overarching structure across the teams in his domain supports the company‘s strategy, while the Solution Architects define the individual products in more detail. Domain and Solution Architects need to be aligned.

While not every organization has domain architects, it‘s common to have Enterprise Architects to align all Solution Architects. Enterprise Architects are responsible for the overall architecture, which means, they need to create an environment which builds the right architecture.
They set up a central EA repository and processes to let the Solution Architects populate the central repository with information about all products, connect these to processes and business capabilities, etc. so that for each product or project you can draw a line from strategy across business capabilities and processes, people, etc. so that for any major change in one of these areas you can easily identify affected segments. This allows you to find out what happens when you fade out an application or modify some important processes.
Enterprise Architects are responsible for Enterprise Architecture Management (EAM). This means they develop processes to improve the architecture of your company. They can follow mature methods like TOGAF‘s ADM (Architecture Development Method) or define their own approaches. Whatever fits best into your company‘s environment. In conjunction with portfolio or program management they define roadmaps and processes to keep them up-to-date.
One important aspect of the EA‘s work is to build up common knowledge regarding decision-taking, architectural methods and architecture guidelines and principles across all architects within the company. One way to do this is by building and managing a community or guild which shares knowledge and takes decisions whenever more than a single initiative is affected.
A more conservative approach would be to govern the domain and solution architects by introducing EA quality gates. Yet, this doesn‘t scale as much as common ideas, so in larger environments with little regulations this approach might be a bit outdated. In environments with much regulation having EA quality gates still makes sense.

Enterprise Architecture and other Departments

If Enterprise Architecture is responsible for the architecture of a company, this can easily overlap with the responsibility of other departments.

To develop products with Scrum, you would take a domain-driven design approach to identify a business domain and build a product team which builds the appropriate solution. Designing the organization is the task of a dedicated department in many companies. Identifying the technical domains is usually a task for the Enterprise Architecture team.
If multiple product teams share a technical platform, the technical dependency has an impact on the organization above. You need to consider both technical and business domains to build a great organization.

At the same time an EA team can have specialist members like infrastructure architects, which might raise discussions with your security department.

In all these cases you can either negotiate and define RACI matrixes (who‘s doing what), or you simply accept that you all serve the same purpose to improve your company. Then we just need to make sure that we all understand the strategy of the company, the methods how to take great decisions, and then we decide who takes over a task, depending on availability and skills.

When it comes to distributing work across your company, it‘s not about “Who gets the power to take decisions and over-rule other stakeholders?“ It‘s about “Who has the skills and the time to drive a topic?“

Responsibility means you need to make sure that all relevant interests have been collected and considered and that you find a solution which trades off all the interests into an action everyone commits to.

Typical Questions

My company is quite small. We‘ve been growing a lot lately and plan to continue so. But aren‘t we too small to hire an Enterprise Architect?
Good question. Enterprise Architecture as a department usually exists in larger companies with thousands of employees. Aligning architecture with the company‘s strategy can be done by a single person, if it‘s possible to understand the strategy easily and you run a handful of applications only.
If you have so many applications, processes and business domains that you need more architects, usually at some stage they specialize into Solution, Domain and Enterprise Architects.
To understand at which stage hiring an Enterprise Architect makes sense, more aspects than your company‘s size need to be considered.
Is the company‘s strategy clear? Do you need help with aligning strategies spread across your company? Is it clear which parts of the company support your strategy? Are the processes across the departments defined and effective? How do you want to organize your company to deal with expected growth? How can you move decisions into the future? How can you secure data?
Once you grow and need to employ more developers and architects, how do you find appropriate employees? Is the technology you are considering future-proof? Are you working on the right things?
A good Enterprise Architect can help you with all these things, so getting an Enterprise Architect onboard can be helpful at a much earlier stage than you might think.

Do Enterprise Architects Configure Servers or Develop Software?
The quick answer is no. The longer answer is: most probably your Enterprise Architect at some stage has developed software and/or configured servers, but has not done that in production for quite some time. Enterprise Architect is a role most people take over at a later stage in their professional life. Before that lots of us have had experiences as developers, systems administrators, business analysts, requirements engineers, product owners, product managers, technical writers, speakers, process designers, project managers and so on. This means EAs are able to do a lot of things, but don‘t expect that they are world-class in everything they have done.
People say EAs are T-shaped, meaning they have very broad knowledge (the horizontal bar of the T), but can go very deep whenever necessary (the vertical line of the T). Most EAs have gone very deep in certain areas and might have been world-class at the time, and have collected very broad knowledge over the years. When you ask them to configure a server or develop some code, they might be able to do so, but they probably won‘t be as quick as dedicated systems administrators or developers. (Or they might be much faster, depending on the EA :-))

Conclusion

Enterprise Architects know a lot about business and technology and can provide you with context and methods whenever you need to take great decisions to develop your company to the better.