Case study
From two systems to one vision:
How we redesigned a bus manufacturer's future
.jpg)
We proved that architectural transformation doesn't require months of analysis - it requires two days of the right conversation. By compressing discovery, alignment, and design into an intensive workshop, we turned fragmented legacy systems into a unified SDV platform vision.
Starting point
The modern mobility sector has moved beyond mechanical engineering into data engineering. Fleet optimization, predictive maintenance, and real-time vehicle management now define competitive advantage as much as engine performance or fuel efficiency. The concept of Software-Defined Vehicle (SDV)represents this shift - vehicles become platforms where software determines capability, and data determines value.
For our client, a leading bus manufacturer, this transition revealed a costly infrastructure problem. Two separate legacy applications handled vehicle communication, maintenance, and reporting - each operating in isolation, each requiring dedicated teams, each representing years of accumulated technical debt. The systems worked, but they couldn't evolve. New regulations demanded integrated data flows. The market was moving toward SDV capabilities that their fragmented architecture simply couldn't deliver.
The two-day architecture sprint
Approach
Event Storming asSystem Autopsy
We conducted event-storming sessions that deconstructed both legacy applications simultaneously. Technical teams mapped workflows, business owners identified pain points, and the process revealed where the two systems duplicated effort, where they contradicted each other, and where critical functionality existed only in undocumented tribal knowledge.
The workshop created shared understanding across stakeholders who had previously operated in separate domains. Everyones aw the same system map, the same inefficiencies, the same opportunities.
Three Architectures, MultipleFutures
Rather than proposing a single solution, we developed three conceptual architectures during the workshop - a target state for immediate needs, an interim migration path to get there safely, and a future-proof design for long-term market evolution. Each version addressed regulatory requirements while optimizing for different business priorities:speed to market, risk minimization, or maximum flexibility.
This options-based approach gave leadership real choices backed by technical analysis, not just vendor recommendations.
Proof of Concept as Risk Reduction
We designed a focused Proof of Concept scope targeting the most critical SDV functionalities. The PoC would validate that a unified platform could handle real vehicle data volumes, support required analytics, meet regulatory standards, and integrate digital twin concepts - all before committing to full-scale development.
The workshop didn't just produce documentation - it produced a validated roadmap with measurable milestones.
Breaking The Linear
We compressed discovery and design into two intensive workshop days where all stakeholders worked through problems together in real time - turning what's typically a sequential process into a collaborative sprint that produced three validated architectures and a concrete PoC plan.
When workshops replace months of planning
Summary
Most architectural transformations begin with extensive discovery phases that consume months before real design work happens. We showed this bus manufacturer that architectural transformation can start with shared understanding built in days, not months.
The two-day workshop changed the quality of output by having all stakeholders work through system challenges together, avoiding the misalignment that emerges when technical teams and business owners operate separately. The client moved from operating two costly legacy systems to having three strategic architectural options, a validated PoC plan, and an organization aligned on what they're building and why. The workshop compressed what typically takes quarters into two days, proving that architectural clarity comes from collaboration intensity, not timeline length.
.webp)