By late afternoon, the wall at the end of the room was covered in cards. Green meant the group had agreed on a principle. Red meant it had rejected one. Blue meant: needs more detail. It was the end of a one-day architecture workshop for Kyveris, the first of two days in Brixen, and the people who normally build the individual parts of the system had spent it working on the whole.
This post is about who was in the room, how we ran the first day, what we deliberately did not do, and what came the day after.
One room, two days.
Kyveris is in beta with its first customers in the Graphics segment, and the conversations there keep returning to the same point: nobody asks for a new dashboard. People describe functions that do something.
A system that does something has to work as one across all its parts, and those parts come from several teams, locations and countries. So in early October we brought them to Brixen for two days: an architecture workshop on the first, an AI workshop on the second.
Engineers from Brixen and Lienz, who know how ink, substrate and machine behave together. The callas software team from Berlin, whose PDF technology runs inside prepress systems across the industry. Triple C Labs, whose CoCoCo connects any equipment and shop-floor software across manufacturers. The teams from PrePress Digital and LIFT Software, behind Durst Workflow and LIFT ERP, who take a job from order intake all the way to the press and finally to the invoice.
All of them are Durst companies, and each has built something that works. Together they are the building blocks of Kyveris. What we needed was one shared picture of the whole, and an honest one. A picture like that takes people in one room, looking at the same wall.
Scenarios first.
We started with situations a production team would recognise and treated each one as a test case for the architecture. Boxes and arrows came later.
A salesperson sits with a customer and asks, by voice, for the campaign printed eighteen months ago, this time with a blue background and twice the volume. No order number, no file. Since then, the machine, the ink batch and the substrate may all have changed.
On the night shift, the planned substrate is not available. The alternative is in the warehouse, but nobody on shift has printed it, and whoever builds the colour profiles is not reachable until morning.
A machine component starts to drift. Failure is not certain, but it is coming. Wait, and risk a standstill in the middle of a time-critical run. Or service it on the fixed calendar date, and lose production time to maintenance that was not yet needed.
These are not features we ship today. They are situations we want the architecture to be able to carry.
We broke each scenario into process steps and asked the same question at every step: what must the system be able to do here? In capability language, not product names. We held to that rule on purpose. Once a product name enters the discussion, the conversation is about the product rather than about what the process needs.
Mapping what exists.
Next, for each capability we asked which of our current products provides it today. Coverage was marked as full, partial, a gap or unclear, and wherever several solutions provide the same capability, we noted the overlap. One ground rule applied: describe the current state and leave the target for later. We did not solve gaps on the spot. First the whole map, then the design, then the execution plan.
A map like this shows three things: overlaps, gaps and open questions of ownership. It will not surprise anyone who has built software over many years that all three showed up.
Architecture principles as hypotheses.
After lunch we turned to architecture principles. Groups worked through discussion cards with possible principles and could keep, rewrite, combine or reject them. What came out is a set of six guiding principles. Two of them: open standards, so that systems stay portable, and design for failure. Components, connections and sites will fail, so we decide in advance what the system does then.
They give clear direction, and they are still hypotheses. Each principle gets an owner who writes down the rationale, the implications and a way to measure designs against it. A principle you cannot hold a design against is a slogan.
A first draft, to be challenged.
The last working session produced a first architecture, version 0.1. It describes what sits in the cloud and in the factory, how data flows from machines and software into the system, how decisions flow back, and where a person has to approve.
Architecture v0.1 is our first working draft, and we build on it. It still has open questions, and answering them is the work that follows.
The day after.
The next day had a different format: an AI workshop. No architecture drawings this time. The teams shared best practices from their own work with AI, along with ideas and the principles they follow when building with it. Then we looked together at where development is heading.
An architecture says where things sit. How we build with AI inside it is a question of how we work, and that spreads faster when people compare notes face to face. Some of these practices are already part of our daily work. Others we are still developing.
What happens next.
The open points now sit with a few small teams, each with a named owner and a regular rhythm. Their questions are practical: how our products overlap, what a common data model looks like, and how the architecture should be shaped. I will write about the architecture itself in a later post, once there is more than a first draft to show.
What stays with me from these two days is the team more than any diagram: people from different places and disciplines, sharing ideas about what we are building. The cards on the wall will be rewritten many times. What makes rewriting them possible is that we now understand each other’s thinking. We also shared one long table, without slides. A workshop aligns the thinking. The human side matters just as much: the joy of building something together, good conversations, some fun along the way. That is what makes a team stronger.
— Michael Deflorian, October 2026
