How to design architecture for a product that already has a successful production environment, but where you still want to launch startup-like initiatives inside it? How do you avoid breaking a stable system, keep user trust, and at the same time give the business room for experiments? - Painful cases of “heavy features” that didn’t stick - How we turned the business desire for “more and faster” into architecture - A successful case of fast features: Secret Boxes in Expirenza - Problems that came after the success of a “temporary” feature - Shifting the development team’s mindset

Nowadays, there is a wide variety of tools for documenting software architecture. However, over time the question arises: is there a tool that not only allows you to represent architectural blocks as interconnected services or components, but also includes comprehensive information about business processes, information systems, and IT infrastructure in a unified view? Such a tool is ArchiMate. ArchiMate is a modeling language for describing, visualizing, and analyzing enterprise architecture, which, together with TOGAF, becomes a powerful instrument in the hands of an architect. During his talk, Alexander will share examples of the Archimate modeling language, show how Archimate can speed up architecture documentation and analysis, and talk about how they use the modeling language at their company.

For many years, our corporate banking platform ran on a large, reliable monolith. Over time, however, technical debt, long release cycles, and module dependencies slowed us down. It was time to rethink. This is the story of an evolution for 150,000 clients: from running monolith and microservices in parallel to Domain-Driven Development with over 20 platform and product teams, from JSP to microfrontends and design systems, from IBM to Open Source. Key Takeaways: Why a stable monolith is no longer enough for modern banking Transition patterns that don’t disrupt business or harm clients Lessons from running monoliths and microservices in parallel Domain-Driven Development at scale: 20+ platform and product teams Microfrontends and design systems for faster delivery When Open Source is the right choice vs. when to buy

Imagine one day your team inherits a system that was built over 4 years by six different teams — just to test hypotheses. No documentation. Just a massive monorepo and Jenkins for deployment. That’s exactly what we were handed, and that’s when we decided to take full inventory — starting with Architecture as Code. In this talk, I’ll share how we approached architectural documentation systematically: from building C4 diagrams to creating Service Documentation, ERDs, and Sequence Diagrams. You’ll learn how we practically restored our understanding of the system, brought architectural clarity, and which tools (PlantUML, Mermaid) and methods worked best. This talk isn't just about diagrams — it's about surviving chaos, synchronizing a team, and driving architectural evolution through transparency.

What can go wrong if you allow each service to access the database directly? In a startup, this seems like a quick and easy solution, but as the system scales, problems appear that no one could have guessed. In my talk, I'll share Solidgate's experience in transforming its architecture: from the chaos of direct connections to a service-based data access model. I will talk about the transition stages, bottlenecks, and how isolation affected infrastructure support. I will honestly show what worked and what didn't. In short, we will analyze the controversy of this talk.

When human safety is at stake, technical reliability is not just a requirement. In this talk, we'll look at architecture, workloads, WebSocket solutions, Kubernetes scaling, and other technical aspects of creating an airborne alarm map. This is a story not only about code, but also about responsibility.

Let's talk about our history. How we started the project with a small vector database of less than 2 million records. Later, we received a request for +100 million records, then another +100... And so gradually we reached almost 1 billion. Standard tools were quickly running out of steam - we were running into performance, index size, and very limited resources. After a long series of trials and errors, we built our own low-cost cluster, which today stably processes thousands of queries to more than 1B vectors.