Yes, there is a life beyond DDD. In the best sense of pattern languages, domain-driven design gives clear names to things that many developers and designers know how to do, but cannot reliably and compatibly communicate about. But like other very popular approaches, it is sometimes treated as if it were the only viable design strategy. In this session we’ll look at DDD’s contributions as well as some of the misunderstandings and misuses that come with the hype surrounding it. We’ll try to derive some useful guidelines for treating domain-driven design in particular, and software design hypes in general.

Many years ago, as a young architect, Matthias used to have debates with colleagues about what whether a particular architecture was "good" or "bad". It was mostly a matter of taste and personal preferences, and it went until sunset without any real result. You can spend hours debating about architectural taste, but: Do we have time for that? Nope. Matthias thinks that every architect needs a clear way to deduce their software architecture from a system's goals, its context, and the qualities(pl.) required. In this session, we'll find the shortest path from what is known to what is yet unknown: our desired target architecture. Prerequisites: - The session will have a mixture of teaching and short exercises on a Miro board. Please make sure you use Miro's stand-alone client and an already existing Miro account to get up to speed quickly.

The legacy monolith (AKA Big Ball of Mud) is a challenge to startups and even more to large and established companies, built when paradigms and tooling followed different patterns. As the tech ecosystem has evolved, new patterns, tools, APIs and possibilities tend to overtake them, tightly coupled apps become a source of increasing technical debt and diminishing competitiveness and business value. But the alternatives are fraught with risks, challenges and complications. I will review 6 state-of-the-art patterns: maintaining the legacy (Wikipedia); decomposing into a modular monolith (Etsy); decomposing into microservices (About You); Serverless monoliths (Phantom); Serverless microservices (Liberty Mutual), and microservices as a service (Moonpig/CommerceTools). In the process I will offer principles, roadmaps, risks and tools to make the jump, touching on the issue of language migration/complementation.

Over the last 16 years, I've been fortunate enough to launch two successful businesses as a hands-on CTO/co-founder & developer/architect. The first, Flexischools, provides online services to schools & parent communities, and has supported millions of Australians over the years. When we launched Flexischools, I was relatively inexperienced - I did my best to follow the guidance I could find online, but I frequently found myself struggling to incorporate the burgeoning growth in complexity of its feature-set into an increasingly tightly coupled code-base with a very small team of developers. In 2015, I discovered DDD, and when reading the Blue Book, I felt a light bulb going off on every page. When we launched our second product, LanternPay, I vowed not to make the same mistakes. LanternPay is a healthcare & disability claiming & payments platform supporting hundreds of thousands of Australian care providers and recipients to ensure prompt and equitable access to care. In this talk, I'll reflect on the comparative experience of launching, operating & scaling both products and the impact DDD had on the technology & the business. Some key questions we'll explore: * How to use DDD when you're launching a new product into a new market and there are no domain experts to consult? * Why it's not a good idea to use the same object/table to store both the size of a school uniform t-shirt and the presence of a slice of cheese on a sandwich * How to make the business case for a major multi-service refactor when your DDD-inspired domain understanding evolves mid-project.

ISO 25010 has been proven to be a suitable and successful model to define the quality goals of a software system. Based on them you are able to develop a suitable architecture. However we need quality goals first - and neither product owners nor architects are keen on developing them and formulating them according to SMART criteria. In our day-to-day project work, we often come across statements such as 'we don't need quality now, we'll do that later' or 'everyone knows: security and a good user experience is essential and of course our cloud services have to run 24/7.' That is not enough - we'll tell you about some projects for which the architectures were initially developed without taking quality goals into account, what consequences this had and how the architecture changed after the definition of quality goals. Afterwards we want to discuss whether this is only a phenomenon at our company and what we as architects can do to avoid it.

Artificial intelligence is on the rise, without a doubt. Whether it's quality assurance in production, returns management in online retailing, or customer support via chatbot: AI opens up unprecedented opportunities to significantly improve your own processes and business models - provided you have enough qualified data. But how can AI be integrated into your own software architecture? Who decides on the right model and the right algorithm? And how is the sufficient quantity / quality of data decided? The role of the AI architect seems born. The session illustrates the various challenges that can arise from the integration of AI for one's own software development and shows suitable, pragmatic approaches to solving them.

In only a few years, the number of options available to run containers in the Cloud has literally exploded. Each provider now offers tens of “slightly different” services, each with its own minor trade-offs. Furthermore, running your applications in 2022 is definitely not like doing it in 2019: some of the new serverless options offer unique value propositions that shouldn’t be missed. It’s easy to get overwhelmed! This talk will categorize the various options available on AWS, Azure & GCP, focusing on what is state-of-the-art in 2022. We’ll look at Kubernetes and its evolution. Finally, we’ll explain the trade-offs between different categories from a technical and organizational standpoint. We’ll then do a deep dive with a demo on some of the new services that have been recently launched and that are quickly evolving to change the game: GCP Cloud Run, Azure Container Instances, and AWS Fargate.

What is maintainability? Most developers and product owners can't answer this question even after reading official definitions because they are too abstract. Do you wonder why the sprint goal hasn't been met over and over again? Do developers experience being less productive? Congratulations, your system is probably not maintainable. If you know this all too well and are wondering what can be done to improve the situation, Domain-driven Rearchitecting could be a suitable approach for you. On the basis of real-life examples, I will demonstrate how you could improve your architecture by following principles and patterns of Domain-driven Design. We are focusing on using the “Domain-from-Legacy” canvas. This is a collaborative and incremental method for software architecture modernization. We will start with analyzing existing code to find potential independent functional units. Lastly, we investigate these units according to DDD principles. In the end, we finalize the socio-technical architecture of the future based on bounded contexts. Get inspired by an agile and collaborative way to modernize your architecture and make your development team productive again.

Security is of paramount importance when building web APIs or Apps running in the cloud. In this session, long-time Microsoft MVP Rainer Stropek introduces you to the top five technologies in Microsoft Azure that will make your PaaS-based solutions in this cloud environment significantly more secure. You will hear about Managed Identities, Private Endpoints, Key Vaults, logging/monitoring/telemetry, and Azure Policies. The knowledge gathered in this session can help you to create cloud architectures that have a high level of security built-in.

Ever found yourself admiring a beautiful and elegant design, wondering how the person who created it came up with such an idea? In this session I will discuss some tips and tricks from my experience, that will teach you how to create a design others will admire and wonder how you thought about it. I will use some real life examples, will present some good design decisions and some decisions you better keep your distance from.

Functional-programming acolytes usually advocate an FP-first approach to doing software projects. However, the reality on the ground is often different: Many projects want to benefit from functional programming, but have an existing OO codebase with paradigms and conventions that are at odds with "FP purity". This talk describes an ongoing cooperation between Blume2000 (firmly OO) and Active Group (pure FP) to get the most beneficial bits from functional programming into an existing hexagonal/DDD architecture written in Kotlin with Spring Boot. The project has produced some successes: - applicative-based validation - free monads for better domain/port separation - functional dependency injection, also in conjunction with the free monads The project also has produced some areas of friction - notably the strict domain/technology separation of the hexagonal model helps developers find their way around, vs. the more fine-grained approach to abstraction taken in the functional core/imperative shell architecture preferred by the FP folks. Moreover, the annotation-based approach to system assembly implemented by Spring Boot clashes with the more object-oriented approach favored by functional programmers. We'll dive right in, get our hands dirty, and report on how it's done.

Kubernetes is the de-facto standard when it comes to container orchestration. But why is there is no established, standard and uniform way to spin-up and manage a single or even a whole farm of Kubernetes clusters yet? Instead, a whole bunch of different and mostly incompatible ways towards Kubernetes exist today. Each with its own pros and cons in regards to ease of use, flexibility and many other requirements. In this session we will have a closer look at the different available options to create, manage and operate Kubernetes clusters at scale.

Software Architecture and Software Project Management both areas are very close to my heart. Both have equivalent importance for the success of a software project and product and they both have interconnecting goals too. As an integral part of Software Architecture, goal would be to have a successful design, it’s proper implementation and sustainability for a longer period of time. As an integral part of Software Project Management, though the area of operation would differ, goal would always be a successful completion and delivery of the project / product. Scope, Time and Quality remains a common factor to both of them. However, Software Architecture goes beyond to just the completion of software development. In ideal situation, Software Architect and Project Manager are 2 different roles which are good to have in a software firm. However often these roles are merged with a new role namely Technical Manager / Solution Architect / Tech Consultant. With my personal experience of being a Manager and wearing a hat of Architect (as and when required), writing design documents for the product and also managing the team schedule, considering both the managerial as well as technical aspects, I would like to share: • How indirectly various important attributes of Software Architecture were implemented. • Challenges that come up when you play both roles. • How important it is for an organization to have both as different roles? Benefits and challenges associated with it. In addition, with this session I will also talk about: What are the aspects of both the areas which would jointly bring out what I would like to call S3 - A Successful and Sustainable Software?

Years ago, when all software projects were doing big up front design, it made perfect sense to have full time architects work on an architecture a couple of months before development would start. The impact of making a wrong choice could have a disastrous impact on the project’s success, after all. But nowadays, most projects are using agile approaches to software development with quick feedback loops where we can recalibrate our architecture every sprint. Therefore, wrong choices have only limited impact and we don’t need architects anymore - right? In this keynote, we’ll look back at what changed in software development in the past 10-15 years: from waterfall, monoliths and your own servers in your own datacenter to agile, microservices, cloud and DevOps. We’ll look at the impact these changes had on how we approach software architecture and will ask ourselves: do we still need architects?

In this session we will look at the importance of quality requirements in the architectural design process and how to ensure that we are as close as possible to focusing on the most important ones since they trade off against each other. Further more we will visit a few tools and techniques such as conducting quality attribute workshops (QAWs) writing Quality attribute scenarios. Both QAWs and quality attribute scenarios are techniques created by the Software Engineering Institute (SEI) at Carnegie Mellon University.

WebAssembly (Wasm) is without question one of the most exciting technological trends in software development nowadays. It gets a lot of attention because it ends JavaScript's monopoly on browser development. However, Wasm and connected technologies can do much more than just browser development. Wasm can be used on the server, as a scripting environment for business apps, as an efficient runtime environment for serverless cloud functions, etc. It can even replace container technology in some application scenarios. In this session, Rainer Stropek introduces the current state of Wasm and related technologies. Based on that, he describes application scenarios where Wasm might be a game-changer in the future.

We live in the time of mobile-first development, where many developers keep facing the same problem over and over again: How do we synchronize users’ data across their multitude of devices? Phones can be temporarily offline, tablets only work with WiFi, and browsers may crash. Under no circumstances should users have to resolve merge conflicts, but they do expect history and rollbacks. Can we satisfy all these constraints? “Conflict-free replicated datatypes” are the solution. A rather young technology, poised to solve synchronisation issues once and for all. Come along to a stroll through research & practice of this emerging ecosystem.

Continuous Software Architecture is a philosophy and approach to software architecture that embraces the fact that doing most of the design before the implementation does not work very well, and perhaps never did. The approach tries to move architecture from a set of up-front blueprints to a continually developed set of architectural knowledge and decisions, stressing collective ownership of the resulting architecture. While a simple idea, actually putting it into practice can be difficult. In this talk we will briefly recap the idea of Continuous Software Architecture and then explore the key practices that are usually needed to achieve it, as well as the common problems and how to address them.

Microservice is a buzzword, and it has been around for more than one decade. Some companies tried with success while others did not get much benefit from it and then went back to monolith. Are microservices the ultimate goals for application development? In this session, Emily will take you through the history of microservices, look at microservices from different angles and discuss what modern application development and deployment should be.

Modern technology and SAAS systems easily support piecing together multiple "best-of-breed" applications, each specializing in a part of the business process. You can impower those systems even more by exchanging bits of pieces of information. However, doing so can lead to a series of unfortunate events as these data points either slowly drift apart or lead to more and more complex integrations. In this session we will go over an approach to manage this and help control the complexities of multi-party integrations.

Our software projects are getting bigger and more complex. Technologically, a lot has been done in recent years to get this complexity under control. But communication between all project stakeholders has become even more important. A prerequisite for this is documentation of the software architecture. It should be as up-to-date, pragmatic and goal-oriented as possible. But unfortunately, documentation often has a low priority in our projects. In some cases, those responsible lack the motivation. Or suboptimal tools like word processing, heavyweight UML tools or wikis nip all efforts in the bud. We want to end prejudices and show with concrete examples how documenting can not only be fun, but also easy. We will talk about our experiences and focus on lightweight tools and lean text and graphic formats. They facilitate the automated creation of effective, comprehensive and, above all, redundancy-free documentation that can be delivered in various formats with little effort and optimized for different target groups. Embedding this documentation as code in the development and review processes also enables good traceability, continuous improvement and further development.

Conway’s Law teaches us we can’t think about software and organizational structure separately. Team Topologies defines a set of team patterns that complement architectural strategies such as microservices and cloud platforms. Together, they enable flow and resilience. The question remains, though: once you’ve adopted Team Topologies patterns, how do your teams behave? Maximizing flow at scale depends on the ability to balance autonomy and alignment. This balancing act requires more than just breaking systems and organizations into small, self-contained units. Those units need a socio-technical architecture for how they relate to one another. This talk will describe the missing piece in the structure-and-behavior equation needed to achieve large-scale agility.

Today’s successful systems architects forge a connection between an organization’s strategy, its technology choices, and its operational capabilities. Building executive awareness and securing buy-in requires you to communicate technical decisions and trade-offs clearly without confusing or lecturing your audience. This session prepares architects to “ride the elevator” between the IT engine room, where software is built, and the boardroom, where executive decisions are made.

Data almost always outlifes their applications and databases are still at the heart of most applications. While Microservice patterns such as polyglot persistence recommend to choose the right database for the job, the number of options and therefore decisions increased significantly. Fully managed SaaS offerings allow an actual choice for development since operational complexity becomes manageable. A lot of jargon, theorems and abbreviations like ACID, BASE, PIE, CAP, OLTP, OLAP, SQL, noSQL, serverless, columnar, analytical, big data are used, which makes it hard to make an informed decision. This session provides an architects perspective on choosing the right database technology based on quality attributes, access and query patterns.

Many projects require a high degree of configurability by its users. While this can include setting mere configuration options, application domains may also use complex, user-defined rules, flows or entities. In such cases, devising a custom configuration language helps manage complexity. The resulting language is a domain-specific language (or DSL for short). Well-designed DSLs - contribute to separation of concerns by decoupling configuration from implementation, - improve usability of the software by providing a consistent view of the domain rules, and - lay the foundations for some architectural quality goals, such as configurability and malleability. In this talk, we explain what roles DSLs can play in architecture design, and give an overview of the methods and tools that are available for designing and implementing them.

Hardly any talk about software architecture nowadays gets by without mentioning Conway's Law. But as is so often the case, few people have actually read the original paper. And people who work on software are rarely experts in organization or communication, which they now understand to be an important element of architectural work. This talk discusses misconceptions about Conway's Law and shows what impact but also opportunities Conway's Law actually provides.

When Eric Evans wrote the Blue Book, he could hardly have foreseen the advance of cloud computing, infrastructure as code, and managed services. Many of the original and well-established DDD patterns nowadays seem inadequate, unhelpful, and strangely misplaced in cloud native environments. Even the success of micro services, and their strong connection to bounded contexts, is waning, as the industry standard shifts to serverless functions, and low code development tools. How much of DDD is still relevant? Can the same mechanics and heuristics help to guide us through a vastly different landscape? An attempt at finding familiarities in a strange world.

For a microservices architecture to be succesful it is crucial to have the right boundaries between the microservices. But where are the right boundaries? I would like to present a tool that helps us answer this question. Domain Storytelling means that we let our users tell us stories about their work. While listening, we record the stories using a pictographic language. The experts can immediately see if we understand their story. After very few stories, we understand the language of our users and find different areas of the domain. Each of these areas (called a subdomain) is a good candicate to become a microservice in our architecture. In this talk I show how to find subdomains and which heuristics can help us.

Educating a group of smart people on how to develop a good software architecture – how hard can it be? Depending on your definition of "hard" and given enough time and resources at your disposal, at least not terribly hard. However, packing this into training sessions with a tight schedule that are targeted at people with different backgrounds while providing an insightful and enjoyable experience with practical value is not that straightforward either. From a trainer’s perspective we are going to look at the challenges of conveying operationalizable knowledge concerning an evolving engineering science that contains a fair amount of "it depends". What are some frequently encountered obstacles to knowledge transfer and how can they be mitigated or even leveraged? As a result, the audience will be able to take away a better understanding of common challenges in delivering iSAQB Foundation Level trainings and best practices to address them.

Java is fast, productive, comes with excellent tooling, and runs well on next-generation cloud-native runtimes. I would like to discuss unconventional and pragmatic serverless Java architectures with lots of code, live deployments, and measurements in this interactive session. Your questions are, as always, highly welcome and will be answered in real-time.

Micro services are ubiquitous. However, most companies that implement micro services do not reap their full benefits - at best. At worst, it’s an epic failure. There are reasons for micro services: independent deployment of business capabilities. However, the unspoken assumption is that you need to deploy all capabilities all the time. My experience has shown me that it’s plain wrong. Some capabilities need frequent deployment, while some are much more stable. In “the past”, we used Rule Engines to allow updating business rules without deployment. While it solved the problem, this approach had issues. Between introducing a Rule Engine and migrating your complete system to micro services, I believe that there’s a middle path, and that this path is Function-as-a-Service. In this talk, I’ll detail every point I’ve made above, and show how one can use Serverless to pragmatically design a system that allows deploying as often as you need.

The landing on the moon was about 50 years ago and mankind plans again big space programs. IT played a major role at the first moon landing and many important fundaments of software engineering were established. The term itself was coined by Margaret Hamilton during the design of the Apollo Guidance Computer (AGC), the control software of the Apollo lunar lander. I want to practice a bit of software archaeology in contrast to current technology hypes with a retrospection of the groundbreaking achievements of the AGC. Priority scheduling, multitasking and a realtime operating system were implemented for one of the first embedded systems. A virtual machine - a new concept as well - provided mathematical functions and abstracted from the hardware. One of the main success factors was the robustness of the software, which was characterized by excellent error handling and prevented human user errors - an important learning after Hamiltons daughter crashed the AGC while playing with it. This quality kicked in minutes before the landing and prevented the failure of the mission. Let us take a look back to the future!

In this session, Matt will look at Istio, a Service Mesh, but no prior knowledge of Istio or the space is needed. Istio is a "smart network" comprising traffic switches and controllers. It's had about four different architectures over time, and we'll look at what problem each solved, and the challenges that eventually led to it being changed. We'll talk about how the different approaches each optimised performance, scalability, and redundancy. We'll explore analogies between the shapes of Istio and common patterns - three-tier web apps, big network routers, etc - and how Istio's lessons are broadly applicable.

Big enterprises have accumulated many large monoliths over the years. These are key for daily business - in short: Mission Critical. But pressure to modernize and transform into modern architectures is increasing. Reasons are manifold: From better time-to-market to replacement of outdated languages, where developers and tools are aging. For major transformations, there aren’t many published success stories. Such an endeavor remains a big challenge. We have accumulated knowledge about conception and implementation of these Mission Critical Backbone modernizations over different archetype of systems from mainframes in Cobol to the “younger” JEE ecosystem. In our talk we will share lessons learned garnished with stories from real project life.

The term "platform" has been around for a very long time and is currently used in an extremely wide and diverse range of ways; unfortunately, it has to be said that it is "overused”. Due to the popularity of large platforms, the success of platform companies and the promises of the platform economy, the term is now used inflationarily. This creates a lot of confusion and even experts in the IT industry continuously talk past each other. Time to bring some order and give an overview of different types of platforms and uses of the term platform. This talk aims to present a map through the platform jungle that allows to identify different types of platforms and, most importantly, to understand their different characteristics and justifications. This also makes it clear how big differences exist and that sometimes the only commonality is that software is involved ... The pain of unresolved terminology discussions will become clear and the map will help everyone attending to leave such useless discussions behind. Every type of platform or platform company can be characterized on the map and all our experiences show that people love to see the clearer picture. In the talk, the audience is given the map to stop getting lost between platform terms. The talk is not technically motivated or oriented, but is intended to facilitate better communication and discussion between all professions in the digital world.

The technique of evolutionary architecture utilizes the notion of a fitness function to characterize the desired architectural characteristics for a system. This talk briefly introduces evolutionary architecture and its principles, and then delves into how we use fitness functions to provide architectural governance, much of it automated, allowing teams autonomy while maintaining the required architectural characteristics.

Integration architectures are the key to modern software systems. We don’t create software on a green field. We always create software in certain already existing environments. The talk discusses the process of architecture design and typical integration pattern in hybrid cloud environments. 1. How to create an architecture vision with domain storytelling and event storming? 2. How to apply the vision to a real world? 3. General architecture pattern for integration scenarios 4. West-East-Integration with events 5. North-South-Integration with BFF and BFI 6. Take Aways

Resilient software design is a topic that became popular in the recent years. But it is much older than most people think and it is a much bigger topic than most people think. In this session, we will first look at the past, from the origins of resilient software design to today. Then we will look at resilience today: What it means and how it affects us in our professional lives way beyond just software design. How the tool landscape changed. What we can delegate to the infrastructure level and why we cannot delegate everything to the infrastructure level. How our functional design decisions affect how resilient our applications can be. Finally, we will look at the unsolved challenges of resilient software design. We will look at emerging concepts that will become more relevant in the future and explore the resilience road ahead of us.

Embedded systems are computer systems that are integrated in a larger cyber-physical system, via which they interact with the physical environment through sensors and actuators. As the requirements concerning the functionality and the quality characteristics of these systems are increasing, the size and the complexity of embedded systems software grows considerably. In domains such as automotive systems, automation, rail, or medical devices for treatment or diagnostics, particular quality characteristics need to be achieved. This talk will give in insight into these important topics of embedded software architecture development.

Being the missing link for Micro-Frontends, the brand-new Module Federation has been greatly discussed in recent months. However, once the basics have been mastered, the truly interesting questions arise: How to deal with version mismatches? How to load remotes dynamically when you do not know them or even their number upfront? How to use Module Federation in a monorepo? How to use Module Federation together with Web Components for multi-version and/or multi-framework scenarios? This session answers all these questions with a case study and explores the trade-offs. By the end, you will know how to apply this to your projects.

To further improve time-to-market and adaptability in delivering their services, e-commerce company iBOOD (well-known for its daily deals) is reshaping its software landscape, which largely consists of a number of mobile applications (in Flutter), web applications (in TypeScript, React) and back-end services (TypeScript, nodejs, Python, Kotlin, MongoDB). While the current landscape must continue to run and evolve (the shop must remain open), we started working on a new microservices platform called Ibex, which leverages state-of-the-art technology, such as Typescript, node.js, and additional frameworks (such as @thisisagile.easy), continuous delivery, fully automated pipelines and running on the Google Cloud Platform. Unfortunately, with microservices, there is no well-described recipe that will take you directly to your desired end state. So, together with the tech team, Sander Hoogendoorn, CTO at iBOOD, ventured off to navigate through the many big and small decisions you need to make when moving towards a microservices technology on a daily basis. During this interactive talk, Sander will take you through the many, many small steps iBOOD is making, illustrating many of these architectural, design, and frameworks decisions made, along the way, with real code examples in Typescript, slowly arriving at a happy state and a set of patterns and coding techniques that evolved along the way. Sander not only talks the talk but walks the walk as well. The effort his teams have put in building microservices has resulted in a nice open source framework called @thisisagile.easy. If your company or organization is also underway toward a microservices architecture, and continuous delivery, be sure to visit this talk, as you too will have to answer many of the questions Sander and his team are facing, and have faced in earlier successful implementations.

16 years ago, my teammates and I built software for big internet properties. We spun up a single instance of open-source software, then added a lot of custom code. Now, we build information systems – data platforms, decoupled frontends, event streams, lots of interdependent software and services with many types of consumers. In the world of “digital transformation”, software is becoming systems. While organizations keep hitting the same iceberg … we don’t think in systems. Systems are nonlinear. They reorganize our mental models and communication structures. Yes, we need to learn cloud-native architectures, Kafka, Kubernetes, GoLang, Terraforming, etc. But we also need to transform how we think, alone and together, or we will build the same old things with fancy new tools. In this talk, we’ll explore essential nonlinear skills and practices for IT professionals. Skills we might not think of as “IT”. Yet these essential practices help us navigate from software to systems.

Breuninger‘s online shop is growing rapidly. That means we need to evolve our systems and organization continuously. What did we learn from growing from 5 to 15 teams in the past 3 years? How do we ensure that the system is stable and resilient and each team can work as independently as possible? We are already planning our next evolution steps and will share how we approach these challenges and how the idea of p53 is helping us to keep our DNA safe.

How do we best deal with time-series data in an efficient and scalable manner nowadays? With the increasing rate and amount of time sequence data generated today, existing approaches dealing with time-series workloads have challenges in operating, scaling, and performing efficiently. In this session we will dive deep on modern solutions for ingesting, storing and querying time-series data. We will look at the most common scenarios, like IoT data, clickstream, high volume events or devops monitoring. Moreover, we will see the benefits and trade-offs that we need to consider when designing for modern time-series workloads.

Working with a client some years ago, after a few weeks I finally managed to get the VP of Product into a session with software developers to learn from his business mental model. The time was beyond ripe for this discussion, but the situation wasn't helped when the chief architect uttered the words of this talk's title: "Why are we wasting time on this. It's just naming things." As it turned out, it wasn't at all "just naming things." The VP exclaimed that he'd always hated the terminology used in the software because it didn't properly reflect what the product actually does; not even close. So he endured the pain for years because the software developers were "just naming things." This VP endured even though he knew that investors and users alike didn't understand the software, which required extra sales effort to get potential consumers over the hump and train them after a deal was finally inked. It's said that naming things is hard. Actually, naming things is sort of hard. The hardest part about naming is communicating the concept being named in a way that makes sense to listeners and readers. In fact, it's not just naming at all. Communicating accurately with comprehensive language is about far more than names, which makes effective communication hard. It's the really, really hard part of software development, as has been proven time and again throughout the past decades. This keynote digs into why communication is hard and why software project/product efforts fail often due to inferior communication and striving for ordinary outcomes. It uncovers the keys to effective communication and provides great incentive for achieving it. You probably don't understand how fundamentally messed up our communication is. But you will learn why, and grasp how you can improve your software outcomes when you make efforts to communicate comprehensively and refuse to settle for the ordinary.