Our brains have been finely tuned by evolution over hundreds of generations for one primary purpose: survival. This evolutionary legacy has endowed us with certain cognitive traits that, while once life-saving, can now inadvertently create significant challenges in the realm of software development and architecture.In this keynote, we will explore some of these quirky brain phenomena and draw parallels to typical scenarios in software development.Understanding these brain traits has earned some researchers Nobel Prizes—and offers us, in software development, valuable insights into systematically improving our own work habits and architectural decisions.Join us for a journey through the fascinating quirks of our minds and discover how a better understanding of our cognitive biases can lead to smarter, more effective software architecture. Plus, you'll get some entertaining anecdotes along the way—after all, who doesn't enjoy a good brain story?

DevOps transformation has been on many teams’ minds for the last decade. In my work with engineering organizations, I’ve found that it can be hard for teams to know where to start or how to actually embody a DevOps mindset and values in their daily work. Having spent the last decade building and running DevOps teams and engineering organizations across the globe, I will share with you lessons learned on this journey with teams living DevOps every day. We’ll cover aspects such as: What does it actually mean to embody a DevOps mindset in your daily work? How can you apply it to the way you think, lead, and engage with others? And how can you lead DevOps transformation in your team, and beyond? You’ll walk away with practical tips that you can apply in your own work with your team to embrace a DevOps mindset, and accelerate your learning and growth.

Many large organizations still work with centralized architecture-related teams. Their role is often to provide architectural specifications to other teams and ensure that these specifications are adhered to during implementation. These teams are often referred to as "ivory tower architecture" teams that aim to bundle highly skilled architects. This role is certainly not available in abundance on the market.However, they do not fit into an agile environment where we want to give teams the opportunity to make their own decisions. Certain guard rails are nevertheless necessary to ensure that the overall construct works. In addition, well-chosen guard rails can also drastically reduce the need for coordination between teams.We need to enable these teams to do most of the architectural work themselves, while ensuring that the individual parts fit together. This is where Team Topologies, a concept introduced by Matthew Skelton and Manuel Pais, comes into play. There is a team type called the " Enabling Team" which, in a nutshell, supports other teams with knowledge and methodology.This presentation will give you an overview of this change as well as practical guidance on how to transform a centralized architecture team into an enabling team whose task is to improve the architecture work in other teams. You will learn:- Which stakeholders you should involve in this process- Why the future enabling team also needs to be empowered and how to do this- Where common pitfalls lie on this journey- Why this journey needs to be done in an agile way with continuous learning and retrospectivesThis talk will also include many real-life examples that accompany such a transformation.

Artificial intelligence is on the rise. Whether it's quality assurance in production, returns management in online retail or customer support via chatbot: AI opens up unprecedented opportunities to significantly improve your own processes and business models. But how can AI be integrated into your own software architecture? Who decides on the right model and the right algorithm? And how do you decide on the sufficient quantity/quality of data? The role of the AI architect seems to have been born. Using a continuous example from the field of generative AI, the session will show which architectural challenges arise in the course of an AI-based software project and how these can be mastered in the best possible way.

Event Sourcing has seen a popularity boost in the last 10 years. With that come both proponents as well as opponents. It's too complex according to one. For another, it's the best way they have ever built their system. Yet others argue that it's merely an implementation detail that doesn't deserve any architect's attention.In this session, Allard will share his findings after 16 years of experience building, supporting, and providing guidance for event-sourced systems. What makes some implementations successful, while others fail in such horrible fashion?After this talk, you'll walk away with a better understanding of the potential and pitfalls of Event Sourcing, how it can be architecturally relevant, and how to successfully apply it.

Technical code and business code should be kept separate. That seems like a simple architecture rule. But it is violated in virtually every real project. Even current frameworks like Spring, Hibernate and co. easily contaminate our domain models.In this talk, we look at ways out of this misery and when and how much pollution might nevertheless be acceptable. This will be helped by- an understanding of the Domain Logic Patterns: Transaction Script, Table Module, Domain Model,- the architecture styles Onion, Clean and Hexagonal Architecture and- tactical design from DDD.

Monolith applications - those relics of the past - are notorious for their legacy technology, causing headaches and slowing us down. We’ve come to accept them as “Here be dragons” on our architectural maps.But what if we could break free? Enter GenAI— the shining knight and savior! Can it liberate us from COBOL’s clutches and propel us toward the modern world? In our session, we’ll go beyond the “Hello World” complexity. The focus will be on sharing our experiences from real-world projects, providing practical insights and lessons learned. Join us on this epic quest to tame the monoliths!

Designing good applications has become more demanding than ever: Cloud first. Extremely flexible. User obsessed. Bespoke persistence. Instant change. Never down. Perfectly secure. Sustainable. Fewer developers. More AI. The list appears to be endless.Many demands did not exist 10 or 15 years ago. Some existed but changed dramatically. Still, most discussions regarding architecture barely reflect today's demands. In this session, we will take a look at how architectural demands have changed over time and how to tackle today's challenges best.

In the development of microservices, sooner or later everyone comes across business processes that involve several services, and usually, in DDD terminology, several bounded contexts. Different approaches to implementing such processes lead to fundamentally changed outcomes. With consequences for the complexity, and thus for the operation and expandability of the system. Especially when event-driven architecture is applied, its asynchronous nature often collides with the desire for global control and synchronous responses. This can lead to "chimeras" that combine the "worst of both worlds".In this talk, he will look at some principles of event-driven architecture. He'll explore how they relate to possible approaches to implementing complex processes. Special consideration will be given to boundaries of responsibility, and the relationship of processes and data.A common pitfall in the event-driven world is simply copying workflows from a monolithic application. This can lead to hastily falling back on orchestration or workflow tools, and possibly to a "distributed monolith". How can we avoided this? The talk will introduce the idea of "micro-workflows" and explore how challenging and redesigning complex processes can lead to better systems. And finally, we'll ask the question: Should the Saga pattern be considered harmful?

Having AI that doesn't know your company is like having a brilliant strategist who wakes up from years in a coma and realizes they've never heard of your business. Can you really expect insider tips from them?How can we ensure that AI systems are accurate, transparent, and always up-to-date? All Large Language Models (LLMs) have a cut-off date after which their world knowledge stops. And they know nothing about your company's internal workings. Even the leading models have hallucination rates that can't be completely ignored. However, they offer enormous potential for productivity, efficiency, and creativity.This is where Retrieval-Augmented Generation (RAG) comes in: LLMs are enhanced through targeted information retrieval. In this presentation, we’ll explore the architecture of RAG-based systems. We’ll discuss the integration into existing IT infrastructures and the optimization of data quality and context management. We’ll learn how RAG helps to fill knowledge gaps and improve the accuracy and reliability of generative AI applications.

Microservices can be a very effective approach to speeding up delivery of value to your organisation and to your customers. If you get them right.If you don’t, then microservices are just something that makes everything you do more complicated, from working out where things are going wrong to upgrading the same dependency in tens or hundreds of services.Sarah will draw on ten years of experience building and operating microservices at the Financial Times to talk about:- What it means to be “successful” with your architecture and technology choices. Can you move fast? Understand what is happening in production? Avoid having to start again?- What you need in place to make microservices work, from technology maturity and leadership support through to platform engineering and observability- Where we go next with microservices: what are the new tools and approaches that will help us get the most out of them?

Software architects will not be replaced by Generative AI or LLMs. They will be replaced by software architects that know how to leverage Generative AI and LLMs. For the last two years, Avraham has been on a journey using generative AI to augment the way he does architecture and makes architecture decisions. Along the way, Avraham has learned so much both about generative AI and about himself as an architect and as a person. In the talk, Avraham invites you to join him on his journey. This talk will equip you with the knowledge and tools to start on your own adventure to leverage the power of GAI, elevate your architectural practice, and hopefully stay ahead of the curve.

World has seen 4 industrial revolutions since late 1700s and now is towards Industry 5.0. Impact of Information Technology is since 3rd industrial revolution. While with such revolutions we see uprising and growth, we talk about journey from Digitization to Digitalization to Digital Transformation, how ready and aware are we as Software Professionals and Architects to comprehend its impact and how skilled and equipped are we to materialize it?Are we truly mindful of the potential impact and implications of these advancements?While developed part of the world is towards Industry 5.0 which is an extension to Industry 4.0 and a transition from Tech-driven approach to Value-driven Human-centric, Resilient and Sustainable approach to industry process; developing countries are still in process to accustom and settle with Industry 4.0. In midst of these revolutions how aware and ready are we as software professionals?While giant industry players have their view about such revolutions, the actual force handling the IT sector needs to be aware and ready for the new wave and trends impacting it at all layers, specifically the way Software Architectures are influenced. In this session we will look at:What is Industry 5.0? How aware are we Software Professionals about the impact it will have on the way we design and manage our Software? Do we see a future to research and realign?

In the tech industry, we are most interested in knowledge stock: What do you know? What information can you apply easily? Whiteboard tests, for example, assess a candidates stock of knowledge.This focus is holding many individuals, teams and organizations back. As relational complexity increases, individual knowledge stock is insufficient. What we need is knowledge flow. The ability to craft and share knowledge in ways that enable the best possible decisions, under the circumstances, in the midst of change.In this talk, we'll explore:- The difference between information, knowledge, understanding and wisdom. In that group ... what is data?- How "management" differs from systems leadership- The emerging practice of developing knowledge systems as a core architectural practice.As Larry Prusak says, "Companies that don’t adapt to understanding knowledge as a force of production … will slowly die, and will never know what killed them." The same is true for technology teams ... we are knowledge workers designing knowledge flows. How does this change our approaches?

In this session, you will gain up-to-date practical knowledge on the evaluation of software architectures which includes AI-based software for security and privacy requirements, and how to improve an insecure architecture using protective measures and best practices such as derived from the OWASP AI Security and Privacy Guide and the current top 10 security issues of machine learning systems (OWASP Machine Learning Security Top 10).We will consider vulnerabilities of machine learning systems such as: Input Manipulation Attack, Data Poisoning Attack, Model Inversion Attack, Membership Inference Attack, Model Theft, AI Supply Chain Attacks, Transfer Learning Attack, Model Skewing, Output Integrity Attack, and Model Poisoning... and security and privacy goals and techniques such as: Use Limitation and Purpose Specification, Fairness, Data Minimization and Storage Limitation, Transparency, Data Accuracy, Consent.

Software architects thrive on their love for software architecture. While this is neither surprising nor wrong, software architecture must serve a purpose beyond itself. This purpose is product success, and software architecture and team structure are the basis for and essential in enabling this success. In this talk, we will explore the crucial role of the product concept and team structure and how they help achieve architectural success.You might want to think: this is self-evident, so why a session about it? Look around you? Do you see development results that don't create value for your customers? Solutions that are exciting from a developer's perspective but not for the customer? Teams that struggle with dependencies and cross-team collaboration? Therefore we need to shift our perspective to the customer's point of view, continually developing architecture and team structure to improve our product according to the customer's need. Embracing agile principles, we'll see how architecture develops alongside product understanding and team organization, adapting fluidly to changing needs.Join us if you're ready to rethink architecture in a broader context and stay agile and dynamic as an architect.

In order to thrive in today’s volatile and uncertain world, businesses needs to innovate at a much faster pace. Recognizing this, IT organizations are adopting the principles and practices of DevOps and the organizational patterns defined by Team Topologies. But while DevOps and Team topologies are vital for delivering the fast flow of changes that today’s businesses need, they are insufficient. To prevent applications from becoming obstacles to rapid change, IT must also create architectures that support fast flow.In this presentation, I describe a collection of architectural patterns that enable DevOps and Team Topologies to deliver a fast flow of changes. You will learn about how to decide between the monolithic and microservice architecture. I'll discuss patterns for designing a monolithic architecture that minimize the various kinds of coupling that inhibit fast flow. You will learn how to design an architecture that enables your organization to thrive in today's uncertain world.

Generative AI is the talk of the town. Anyone who spends just five minutes thinking about AI can surely come up with several useful business use cases. However, all too often, we find ourselves facing the following dilemma: we want to quickly launch our chatbots and assistant systems and bring our ideas to market readiness. Yet at the same time, important, complex, cross-functional aspects such as data protection, compliance, operational readiness, or model fine-tuning often slow down rapid development and deployment.Furthermore, enterprise scale AI projects often involve many different stakeholders: data engineers, AI specialists, software engineers, operational experts, and business departments. Too much talking and no progress at all are the result.AI platforms to the rescue! We believe that established platform engineering approaches and technologies, combined with LLM Ops practices, can tackle this dilemma. Only a robust, scalable, and flexible platform enables our teams to efficiently develop, operate, and manage their data, models, and applications. The platform hides the inherent technical complexity, while allowing users to fully focus on the use case and the creation of value and innovation.We will explore what a corporate AI platform can look like and the components and services it requires. We discuss how a company-wide platform strategy not only simplifies technical implementation but also creates an ecosystem for innovation, fosters collaboration, increases reusability, and ultimately drastically shortens the time to market.

early years of the second decade of the twenty-first century. A world where Docker was a job people did; K8S was a boyband (probably); Kafka was a euphemism for existential anxiety and Chaos Engineering meant, well, nothing as it hadn’t been invented yet. The Cloud … that was just weather to most people.It is 2012, and Microservices appeared on the Thoughtworks Technology Radar. 10 years ago, in 2014, Martin Fowler and James Lewis wrote down something that caused a bit of a stir – the definition of Microservices. 10 years later, for better or worse, Microservices have become the predominant architectural style for building complex systems.So much innovation has occurred in the last decade – Docker and K8S fulfilled the ‘write once and run anywhere’ promise of the JVM. Operations changed beyond recognition as we moved to Cloud Native and FaaS. Testing in Production is a practice that now signifies maturity rather than derangement.In this keynote, James takes a look at the original nine characteristics of Microservices and explores the lessons we’ve learnt since those halcyon days. (Although Kafka is still a euphemism for existential anxiety.)

As AI and GenAI become more prevalent in organizations, we need to consider the architectural implications. AI and GenAI in different ways will affect our architectural decisions. There are also architectural implications for how we might implement AI and GenAI in our IT estates. We will examine architectural issues at the hardware, model, infrastructure, tools and the application layer, For models, we will consider issues surrounding mostly serving models, although we will have some discussion about training models. Finally, we will discuss how AI changes the role of architect and the new challenges that will arise for architects.

Often, the goal of architecture is to improve developer productivity. But what does it mean for developer to be more productive? And can we measure it? Should we? But if we don't, how can we make any progress?McKinsey claimed that they could finally measure developer productivity. This was followed by extensive criticism from notable figures such as Daniel Terhorst-North, Kent Beck, and Gergely Orosz. We will look at the different viewpoints and explore whether productivity can be measured and whether it should be.

The network is back. But is it useful? While the momentum of containerization and kubernetes is well established, service meshes are a much-hyped, but still emerging field. What actually are they, and are they worth looking at?We'll explore what a service mesh is and what they claim to do for a typical microservices web backend. Are the claims of free and easy observability, resiliency, testing and security real? Are they useful during development, production, or both? How well do they work at the moment, and is the hassle really worth it?This session will also briefly cover how a service mesh works, giving you a mental model with which to explore and evaluate after the talk. I'll show a simple installation and demo of some key features. I'll then show you how to connect multiple Kubernetes clusters together using service meshes. This will give you all the knowledge to go home and try for yourself. The install scripts and config files I use will be made available.

Several strategies exist for the migration of legacy applications and a complete greenfield rebuild from scratch is not always recommended. The talk presents the different 5R strategies (retire, replace, rehost, retain, reengineer) for legacy migration and makes a comparison with their advantages and drawbacks. Special characteristics of the strategies for a migration to the cloud (e.g. lift & shift) are also considered.A strategy for itself will not be enough to master the challenges of legacy migration. Dependencies to other applications are sometimes ignored when the strategy is chosen and often it is necessary to prepare the application to meet the preconditions for the migration. At this point concrete tactics or patterns are used to convert the strategy to a successful project. Some tactics are the usage of bridging technologies or the layer-based approach for an iterative modernization of the complete application. The strangler fig pattern is quite popular for the stepwise migration of legacy applications. The talk presents concrete examples from successful migration projects for these and other tactics and patterns.

"The best architectures, requirements, and designs emerge from self-organizing teams."Hardly any other of the principles behind the Agile Manifesto is referenced as frequently as this one.It makes self-organisation appear to be the key to good - the best - software architecture and many architects, coaches and managers look to self-organisation as the solution to the problems inherent in software development.Yet architecture is the absence of any kind of self-organisation - in its most expressive form.Even in software development.This talk will explain why both perspectives are correct and how they are related.It will become clear that self-organisation is both a solution and a problem for software development and what makes software architecture so special from the perspective of socio-technical systems.And, of course, a few ideas will be shared on how to deal with this realisation in practice in order to design really good software architectures.

DPG Media's almost 6000 employees evolve over 80 media brands reaching 15 million consumers. How do they organize themselves and their technology to make sure their content creation and delivery runs smoothly every day?During this talk, Piet will run you through the cloud strategy DPG Media chose, what that means for infrastructure, platform and delivery teams, and what organisational structure works for them.

Have you ever wished you could get inside the minds of the software architects whose work you admire? The ones who effortlessly craft elegant, groundbreaking systems that seem to defy complexity? Well, get ready, because we're about to pull back the curtain and reveal their secrets.Join me to explore the unique mindset and powerful methods that set visionary architects apart. We'll dive deep into the thought processes that fuel their creativity, the strategies they use to tackle even the most daunting challenges, and the habits that keep them at the forefront of innovation.Discover how to:- Think like a visionary: See beyond the obvious, anticipate future trends, and embrace the exhilarating unknown.- Simplify the complex: Master the art of breaking down intricate problems into elegant, manageable solutions.- Build for the future: Design systems that not only work today but continue to thrive in the ever-changing tech landscape.Let's unlock the genius behind visionary architects and build a future where software doesn't just function - it inspires.

Recently the idea of a software architecture elevator has gained traction. We would like to extend on the idea of layers and stakeholders by adding dimensions to the elevator. By allowing our elevator to move not only up and down, but also left and right we can achieve a more precise idea of how to be effective and make sure software architecture is implemented as intended. Focusing on the layers of domain experts and developers we will illustrate which perspectives are typical on those layers and how to balance the archetypes of "controlling architect" and "ivory tower".

In today’s fast-paced business environment, it’s essential for organizations to continuously adapt and evolve to remain competitive and stay relevant in the market. How to build systems that can thrive in the face of constant change? This talk explores the synergy of combining Wardley Mapping, Domain-Driven Design (DDD), and Team Topologies as "Architecture for Flow". Architecture for Flow provides a holistic, pragmatic toolset for designing, building, and evolving adaptive, socio-technical systems optimized for a fast, sustainable flow of value and feedback.Key takeaways from this talk include:- Anticipating change and identifying areas where to invest, what to outsource or evolve to gain competitive advantage by combining Wardley Mapping and DDD- Identifying blockers to flow from an architecture, team ownership, and team dependencies perspective- Unlocking blockers to flow by applying patterns and practices from DDD, Wardley Mapping, Team Topologies

The right data architecture and platform for data analysis and AI is different for every company. What different approaches are there? Which constraints influence the approach and the final solution? Does everyone want the one, magical platform or are there also very tailored, specific solutions? The challenges also differ: some lack know-how and capacity, others are overwhelmed by the complexity of their own IT landscape, others have to set up everything without the help of managed services. With a high degree of practical relevance, I report on different projects and situations - and show a wide range of modern data projects and approaches. Prior knowledge:Experience with data architectures, platforms and infrastructure is helpfulLearning objectives:- Overview of the possible solutions for modern data architecture- Understanding which constraints influence the architecture and in what way- Overview of decisions that are made when designing architectures, including the trade-offs that are usually taken into account. - Application of the different perspectives in your own environment

Nowadays, everybody realizes the importance of preventing undue access to one's applications.Many conceptual models are available: RBAC, ABAC, you name it.Likewise, all popular stacks have frameworks and libraries to help developers implement your chosen policy access.If your organization only has a handful of apps, that's all fine and dandy, but problems appear at scale.One such problem is keeping under control access configuration across dozens or even hundreds of apps.It requires regular, if not continuous, auditing:it's impossible to achieve when the configuration is code, even worse if it's a compiled language.Open Policy Agent aims to externalize such configuration in a text format with specified semantics.In this presentation, I'll explain OPA in more detail and demo how to migrate from a regular Spring Boot application to an OPA-based approach in different steps.

Based on the experience of a consulting engagement, this session describes the adoption of a decision-centric approach to architecting in a large, complex enterprise.Following the shift to more agile ways of working, architects needed to pivot from an 'artifact-centric' to a 'decision-centric' approach to architecting, and shift their mindset from a 'big design upfront' to 'just enough architecting'.

Every organisation has legacy systems. Six month old startups or 30 year old giants of industry. These are systems rich in the heritage of your organisation. They are also those systems blocking transformation into a modern digital business.I have spent most of the last couple of decades helping organisations overhaul their legacy systems. In doing this we've learned a great deal about what works, and seen many paths that lead to failure.In this talk I will tell the tale of one such programme, and describe how several of the Patterns of Legacy Displacement were applied to help the client achieve their business outcomes.The talk is drawn from material being produced in collaboration with Martin Fowler, James Lewis and Ian Cartwright.https://martinfowler.com/articles/patterns-legacy-displacement/

Today, we know how to start a new project on a greenfield site and how to build good architecture. But most of us work in projects that have been around for a long time and whose architecture is (to put it mildly) not all that nice. "Monolith" and "Big Ball of Mud" are the unflattering terms for such systems. In this talk, I will introduce you to Domain-Driven Transformation, a methodology, which Henning Schwentner and I have developed over the last few years from our experience of improving legacy systems. Four steps lead from the evaluation of the current state to the domain-oriented vision of the architecture. We present a catalog of refactorings that help to heal BBOM architectures, anaemic domain models and poorly organized teams. Finally, I discuss our thoughts on the influence of certain domain properties on decomposition into subdomains.

You may have heard AI is coming for everyone's jobs and wondered how soon software architects will be replaced by robots. The more pragmatic view shows the latest technology is just another tool. In this case, it's a tool to be used in our systems, and also one for architects to leverage to improve our ability to design great software systems.Architects say "it depends" because we realize every decision depends on the context. We have to be able to assess a new situation and evaluate trade-offs based on the information available to us. The latest advancements in "AI" are just one more aspect of our ever-changing environment.In this talk, we'll explore how architects should look at LLMs and other AI technologies, both in terms of how they should be used in the systems we design, and also how they can be used to help us design those systems. Figuring that out is key to growing your Architectural Intelligence.

Sustainability is a lens through which the public has started scrutinising various industries. This lens is slowly increasing its focus on the field of IT. As software architects we are uniquely equipped to see this coming and be at the forefront of change.During this talk, the audience is invited to test its knowledge on the energy usage of various common devices. This surprises most audiences and creates awareness about the need to collect data before we can effectively design new solutions.Current efforts and organisations working towards greener IT are introduced and compared, as well as how anyone can join in these efforts.At the end of this talk, the audience has been inspired to be critical about the way we design software systems and (cloud) infrastructures, invited to remain critical on decisions made in existing and new projects and they will leave with a hopeful sense of new possibilities.

But they make everyone else smarter! It’s a common misconception that architects should make those complex and difficult to reverse decisions. Development teams are usually better equipped to make these decisions because they are closest to the action and have to live with the consequences of their decisions. Architects should therefore help the teams make better decisions. This talk shows architects how they can make the most impact by not making decisions.

Microservices have been a major tech hype for years. With lots of attention from the industry, and lots of publications and talks about the good, the bad, and the evil of this architectural style. But, have you ever wondered what a (successful) microservices implementation looks like in the real world?In the past decade, speaker Sander Hoogendoorn has helped a number of organizations renew and re-invent their tech landscapes, slowly moving from (working) legacy and a clean microservices architecture. Most recently, in the past 3 years, together with his team, in the role of CTO at the e-commerce company iBOOD.com, Sander has been successfully working on a clean microservices architecture.During this talk, Sander elaborates on the path iBOOD has followed, the major and minor architectural and design decisions that were made, and a truckload of patterns the team has implemented and even invented (even resulting in the open-source framework Easy.ts). He will take you along and discuss how to apply domain-driven design, how to break up and build up your services, how to set up the inner architecture of services, use patterns, types and classes, how to standardize URIs, how to stay in touch with your legacy, how to deal with data, and how to move data, when and what to test, how to deploy, release, and monitor your landscape, when to scale up, and how to prioritize your roadmap, based on a React, TypeScript, Node.js, Google Cloud Platform, and MongoDB stack.Sander uses many up-to-date real-life code examples, all coming from live implementations, that will inspire you to grow with your own architectures (microservices or otherwise) and design and coding practices, even if you operate on other technology stacks.

Thanks to powerful frameworks and libraries, the first Generative AI applications can be realized at Hello World level with just a few lines of code. However, these first attempts also reach their limits just as quickly. Why? Because reality presents challenges that cannot be solved easily with this trivial approach. But what is needed for a Generative AI application at enterprise level? A well designed Generative AI architecture! During this full day hands-on workshop, we will build a complex Generative AI application step by step. Starting with a minimalist RAG system, we will look at various challenges and discuss suitable solutions. In the end, we will have an architecture that can withstand the challenges of reality.

In this workshop, you will gain up-to-date practical knowledge on the evaluation of software architectures for security properties, and how to improve an insecure architecture using protective measures and best practices such as derived from the "OWASP Top 10 Security Vulnerabilities" of the "Open Web Application Security Project (OWASP)".This will be done in particular by analyzing commonly used patterns for architectures for security and by considering principles for secure design. We will also consider security and privacy aspects of architectures that make use of AI, at the hand of the OWASP AI Security and Privacy Guide and the current top 10 security issues of machine learning systems (OWASP Machine Learning Security Top 10).There will be practical exercises in break-out groups using open source tools for security analysis of architectures and their implementations, which include SonarQube and the Threat Dragon Tool. You will take on the role of the attacker and attack the (deliberately insecurely developed) web application ‘Google Gruyere’.This way, you will acquire conceptual and practical knowledge of IT security at the architectural level and in the context of software development.

Teams of a manageable size generally form the core of modern agile software development. Accordingly, the structure of these teams has a significant influence on development. In practice, however, we often find that the given team structure makes work more difficult, places a high cognitive burden on team members and stands in the way of important goals. So the question arises: how to align your Software- and Organizational Architecture?In this workshop, we use your own companies to identify individual quality goals, select suitable cutting criteria and use these to develop designs for well-structured teams based on frameworks like Team Topologies. We then compare, validate and optimize these designs. In particular, we look at the dependencies that have arisen and check that the trade-offs between cognitive load, autonomy and degree of goal achievement remain acceptable.