HTTP APIs can now be found almost everywhere. Unfortunately, the design of many APIs is not optimal, which will sooner or later result in unpleasant consequences for their providers. In this hands-on workshop, we will practice designing a typical HTTP API together. We will discuss the most important decisions that usually occur during the design process. These include URL paths, the use of HTTP request types and status codes, error handling, versioning and much more. The implementation of frequently needed API features, such as searching, filtering or limiting the detail in API responses, is also addressed. The gradually emerging interface is transformed into a formal specification with the help of OpenAPI. Finally, we'll take a look at existing proposals for API designs that can serve as templates for our own interfaces.

Everyone thinks they are a good at communication, but... how many times have you been at an event talking to someone you really didn’t want to talk to? Been sold to by someone who didn’t get that you weren’t interested? These are examples of bad communication and they all have a few things in common, they weren’t efficient and they weren’t effective. They didn’t go into the communication with the right mindset and the right preparation Also, sorry to say it, but your own communications probably suck too. But after this workshop you’ll have a leg up on your competition: you’ll know your communication sucks... and you know how to fix it. Outline/structure of the Session: - Bad communication, and why it happens - What's the right mindset to have - What's the right preparation to do - Examples of efficient and effective communication - I will take you through my number 1 and number 2 rules for efficient and effective communication.

Good requirements management and cleanly captured requirements are the basis for a successful software project. Clear priorities enable project teams to pull together and avoid conflicting goals. Coupled with precise formulations, uncertainties can be avoided and risks reduced. However, the art is not only to put a requirement in a good starting position, but to understand the path of a requirement, to follow it through the entire development process, and to skillfully track it again and again. There are two sides to this coin, the target group-specific preparation on the sender side and the adaptation, follow-up and appropriate implementation on the receiver side. Skillful collaboration can add value that actually helps those involved. Based on our broken wings example, we would like to work with you in this session to resolve the question mentioned at the beginning: Which rules, conditions, expectations, etc. help us to meet the requirements in their entirety, i.e. the process, even in complicated environments or projects which they go through during their implementation.

Software architecture was invented in the sixties to enable larger teams to work on complex software. In this workshop, we will examine how architecture can achieve this concretely today - and how modern architectural approaches such as microservices or the separation of architecture into micro- and macro-architecture help to achieve this. This enables engineering teams to scale and also enables the architecture work by larger groups of people. In addition, we will discuss how this approach can help to scale agile projects.

Designing or discovering a bounded context, means designing and agreeing on a ubiquitous language (Where by “Language” we mean “vocabulary” for the most part). Since language can be and often is a “symbol” of a culture, this implies that we might need to shift a culture that is consistent with the language. But as your time in an organisation goes on, you become part of that organisation's culture, you use and understand the language of the organisation's domain, and start thinking in the models the organisation uses. Not doing so makes it very hard to actually get any work done. Culture is there to give meaning and context to the chaos of everyday life. But culture also has the tendency to coagulate, to create conformity, and that causes language and models to become semi fixed, and with a lot of ambiguity as a result. That ambiguity and conformity to culture might stand in the way of finding new and more useful models to solve our evolving business problems. So we might need to adapt our culture to the ubiquitous language we are designing or discovering. How to do so? Join us in this 3 hour hands-on workshop where we will introduce you to several techniques and practices that can help you in your context to shift the culture to match the need for how you do software design. To set the expectation - “culture” is a set of values, beliefs, rituals, stories, traditions, behaviours, taboos and much more. In this context, we will limit the discussion to a set of behaviours (and taboos?). We will introduce you to a sample domain model supported by a specific organisational culture, and working from that introduction we will discover how we can spot cultural patterns and symbols. Patterns and symbols that have meaning in the culture are important for us to enable us to shift a culture. Each of these symbols in the culture and model we will evaluate if they are helping us or not. Following that, we will let you do some exercises to see how we can actually change these symbols if we need to so that we can leave behind our old models and language, and acquire deeper understanding and more useful models.

The Repository pattern is one of the oldest and most well-known patterns in software architecture. It is simple, elegant, and easy to grasp - or is it? There are actually many versions of this pattern, some in books, some implemented in frameworks, which all look similar, but differ greatly, both in usage and outcome. This workshop will (re-)introduce the Repository pattern as intended in Domain Driven Design: An elegant way of keeping persistence and domain logic decoupled, improving testability, and creating options for evolutionary development. We will use a variation of ensemble programming to explore different applications of the pattern together, discuss pros and cons, and refactor an existing code base to see the resulting effects. All skill levels are welcome - we will work as a group and help each other out. You don't need to set up your laptop - we will use the facilitator's machine to navigate. The source code and instructions will be shared with you after the event.

The world has gone VUCA (Volatile, Uncertain, Complex, Ambiguous). IT has become indispensable. Complexity of IT grows uncontrolled. Skills shortage. The challenges are manifold and different from the ones we faced in the past. The typical response to these challenges is doing "more of the proven" from the past. Or a bit of Agile or DevOps - but not too much. But this does not work anymore. The challenges are different. In this session, we will examine the new challenges and why "more of the proven" does not work anymore. We will discuss which different goals and values we need to focus to survive and thrive in the future. And we will learn that the building blocks already exist and what they are. We only need to figure out when and how to apply and combine them. As William Gibson once said: "The future is already here – it's just not evenly distributed." ... let us change the distribution to our advantage!

Building software is as much an art as it is a science. In my 17-year journey in the world of software engineering, I've experienced firsthand how the right architecture can make or break a project. In this session, I will share the key lessons I've learned about software architecture. Here is a sneak peek into the topics I'll tackle: 1. The Importance of Getting Basics Right 2. The Evolution of Architectural Patterns 3. Balancing Trade-offs 4. The Human Factor in Software Architecture 5. Lessons from Failures 6. The Impact of Emerging Technologies

Over the last 7 years we used the 4+1 Views to design a system as a modular monolith - saving time, cost and complexity when the team was small & load was low and allowing simpler realignment of module boundaries as we were still discovering the domain. We gradually extracted modules into microservices as needed once we had built confidence in boundaries, when load grew and as the teams expanded and needed autonomy. So how does it work? The 4+1 views is a way of understanding systems that uses 5 different 'views' of the system, allowing to design and scale different aspects of the system in response to different triggers: 1. The logical view represents functional requirements & scales with functional complexity 2. The process view represents executable processes & how they interact & scales with concurrency and deployment requirements 3. The physical view represents the hardware & networks that the processes execute on & scales with load and throughput 4. The development view represents the system as seen by developers (e.g. code) & scales with the number of teams and team size 5. The scenarios view represents the various scenarios in which the system is used & highlights how components in the other views interact A modular monolith is a system that has 'scaled up' the logical view (multiple modules), but not scaled up the process or physical views (single process, single hardware configuration). In this talk we'll explore what went well, mistakes we made & tips for adopting this approach.

In today's fast-paced system landscape, data has become crucial for organizations in every industry. To fully leverage its potential, a clearly defined data strategy and effective data management tactics are essential. This session provides an architect's perspective on crafting a data strategy and establishing clear requirements for data management. We explore how Domain-Driven Design (DDD) can be applied to the data domain and why data product thinking is vital for modern data-driven organizations, particularly in the era of generative AI

Digitization is forcing companies to exchange data digitally with partners in the ecosystems in which they are integrated. At the same time, the requirements for security, verifiability and usage control are increasing. What is needed is technological support that takes these requirements into account. The workshop presents architectures and application scenarios for the use of distributed data analytics in this context and shows applications for cross-company data exchange. It presents architectures that allow corporate data to be exchanged between companies in a secure and trustworthy way, so that the data provider retains control over who gets his data and what he can do with the data.

Even if micro frontends are now quite popular in many companies, integrating several single-page applications into a large whole is still challenging. In this session, we will compare the available options and work out both their positive and negative consequences. We discuss different flavors of Web Components, bootstrapping multiple SPAs, and loading parts of other applications such as B. Allow module federation or SystemJS. Then we try to combine the best approaches and look at the next generation of JavaScript frameworks that masterly combine server-side and client-side rendering thanks to partial and incremental hydration. In the end, you know the options for integrating micro frontends and can evaluate them for your projects.

Many tomes on software architecture pretend as though the programming language of a project is unimportant for the architecture. After all, architecture is about building blocks and interfaces. Isn't that basically the same everywhere? No. In fact, there are great differences: OCaml's module system, for examples, fosters pervasive decoupling even within a monolith. The process concept of Erlang opens up a different view on microservices than, say, Spring Boot. It's not even all about modules: Macros in Racket or Clojure simplify the development of a DSL to the point where making a new language becomes a routine activity in software development. Moreover, the powerful abstraction mechanisms in functional languages enable particularly flexible domain models. Knowing these languages and concepts makes you a better architect.

When a system has "grown historically," this often applies to the tests as well: they run for too long but find too few bugs. The reason is that such test suites often simultaneously test too much and too little. They test too much because they include tests that incur costs but provide little added value compared to similar tests. They test too little because important functionality remains untested. In the talk, I will present analyses that uncover this issue: Pareto optimization of test suites and test impact analysis identify the tests that currently have the best cost-benefit ratio. Test gap analysis reveals which code changes are still untested, indicating missing tests. By doing so, these analyses provide us as architects with effective tools to understand and improve our test architecture.

Artificial intelligence, or AI, is becoming a big part of our lives. One type of AI is Large Language Models (LLMs), like chatGPT. This talk will show how chatGPT can help with complex tasks in software design, such as the tasks in the iSAQB Advanced Exam. We will delve into the intricacies of conversing with chatGPT, illustrating the strategies needed to generate productive prompts and effectively utilize the model as a sparring partner. The talk will exemplify these concepts by taking the audience on a step-by-step journey through the process of tackling the iSAQB Advanced Example Exam, utilizing chatGPT. We will demonstrate how to prepare for a chat session with chatGPT, how to generate robust prompts, and how to manage the chat for optimal outcomes. We aim to highlight the model's capabilities as an interactive tool that can provide valuable insights and streamline the process of developing software architecture. Whether you are a seasoned architect or a novice in the field, this presentation will equip you with novel techniques to navigate the challenging landscape of software architecture with the assistance of AI.

Data Science - A world of data, data history which uses various algorithms, statistical approaches, tools and techniques to reveal what the data articulates, has changed the current software industry scenario. Today the industry is more inclined towards the increased development of software systems having components that are more data-driven. Use of machine learning, artificial intelligence, predictive analytics is widespread. There are set standards, protocols, process and methodologies to design, develop and manage any software-intensive system. In the phase of writing Software Architecture one such set standard which is referred is - Quality Model and the listed Quality Attributes. Quality Attributes plays a vital role in defining the Architectural Goals. It is helpful in specifying, measuring and evaluating the product quality of any software / software-intensive systems. With the emerging Data Science trend, while working on Software Architecture for such data-driven software-intensive systems, there is a need to interpret existing Quality Attributes and its relevant applicability in the right context. In this session we will look at: • Quality Attributes / Characteristics that are relevant for systems that are more data-driven and developed with the use of ML, AI or PA concepts.

A main theme in modern architectures is around fine-grained, isolated, reactive components, that are managed by autonomous teams (think microservices). This is considered key to decoupling, which, in turn, leads to business agility. Unfortunately, this often goes wrong and people end up with more tightly coupled systems, that are hard to understand and change - the opposite of agility. In this talk I walk you through these challenges, talking also about orchestration and choreography, and showing you how to balance both architectural approaches. I will further compare different approaches to automate end-to-end processes, from batches over streaming to workflow engines. You will understand the impact on agility and get guidance on decision criteria, backed by examples collected in various real-life projects.

Architecture for agile projects must be defined and described differently, as well as continuously developed and evolved. Not all decisions are made at once, nor are they all known right from the start of the project. This sessions presents various useful and lightweight methods, tools and team topologies that can be applied in (large) agile projects to avoid uncontrolled growth and architectural erosion but without acting from the ivory tower and thus suffocating team autonomy.

Sociotechnical systems are nonlinear, dynamic systems that can exhibit complex and unpredictable behavior. These systems are constantly changing to provide value to customers, gain a competitive edge in the market or simply survive. Understanding the evolution patterns of sociotechnical systems is important to anticipate their behavior, designing improvement trajectory and managing change. In this talk, we explore evolution from real world use cases in its broadest scope, e.g., modernization, migration, adaptation, restructuring… We combine software evolution with the organization dynamics and people interactions to identify evolution patterns in sociotechnical systems. Finally, we study the impact of leadership and decision making on the success or failure of these cases.

Software architects interact with a ton of people in their daily lives. Customer, developer, management, EAM, Security, … needs want to be met equally. These sometimes contradictory needs crave communication, moderation and conflict management skills. But which skills are needed in particular to face these interactions like a pro? In the Advanced portfolio of iSAQB we offer the module "Softskills for Software-Architects". On the other hand, there are several other modules that entail soft skills and communication credit points- let's take a closer look together!

Serverless Computing: Quo Vadis? Exploring the State of the Art, Its Potential to Replace Classic Cloud Native Development, and Best Practices for Good Architecture

Today we know very well how to start a new project on a greenfield and how to build a good architecture. But most of us work in projects that have been around for a long time and whose architecture (to put it mildly) is not quite so beautiful. “Monolith” and “Big Ball of Mud” are the unflattering labels put on such systems. This talk will show how we can introduce (or bring back) structure. Every system is different here, so it’s important to first understand where you are. Then the right steps have to be taken. I present a catalog of refactorings to choose from and heuristics which are the right choices. The catalog contains refactorings that help to cure: BBOM architecture, anemic domain models, and badly organized teams.

Drawing on real-life examples from Avvo, Spotify, Adobe and Microsoft, Kevin Goldsmith explores why you should consider changing your organization to improve your architecture and discusses the successes and failures he’s seen around the interplay of organizational models and software architectures. Kevin often visits companies, where he hears about how they struggle to break up monolithic applications or move to a continuous deployment pipeline. Oftentimes, the organizational structure is clearly making their problems harder but is seen as something that can’t be changed. Kevin relates his own journey to a more experimental organizational style. As a developer at Microsoft, Kevin worked in a rigid hierarchy organized around functional areas. The communication flows within the organization dictated the way it structured its libraries and dependencies. This is the essence of Conway’s law. In this case, the company hierarchy and the architecture it produced was often suboptimal for the problem Kevin and his team were solving, but it was the architectural path of least resistance. When Kevin moved to Adobe and became a senior manager, he started to build his organization in the traditional way. Adobe wanted to create a more fluid and agile architecture for its products, but the company struggled to realize these goals because it was too hard to work across teams and reporting lines. The company finally started to make some progress as the organization became more fluid and loosely coupled. Kevin then went to Spotify, which had realized this problem early on and restructured its organization in a way that supported the architectural model that it wanted to build. As a vice president of engineering, Kevin was able to see firsthand how the organizational model simplified the architectural challenges that other companies struggled with while also introducing difficulties that other companies were easily able to overcome. When Kevin joined Avvo as its CTO, the company had the same organization and architectural challenges as many other startups, but rather than attack them only from an architectural angle, Avvo experimented with architecture and organization together to improve its legacy systems and help build new ones faster and with higher quality.

Sustainability, while becoming a priority for more enterprises, means many different things to different people, just like the term platforms actually. There are also many fronts on which to address sustainability, including in the IT department directly, supply chain, office operations and plant operations more broadly, to name a few. I'd like to address some of these challenges and how technology can help or has helped already, not just by making the IT department more sustainable, but also by using technology to make the rest of the enterprise more sustainable. I will focus specific attention on the role platforms, architecture, and emerging technology such as AI and XR play in addressing sustainability objectives.

A common saying by software architects is “that’s an implementation detail”. All too often we treat software architecture and implementation as two separate things, where implementation is something that happens once a software architecture is defined. In fact, it’s the other way around: software architecture should be viewed as a first draft, where implementation reveals more details and refinements. In this provocative keynote Mark Richards discusses the intersection of architecture and implementation, and how the two must be in constant alignment to achieve success. Through real-world examples, he shows how implementation can get out of alignment with the architecture, causing the system to fail to achieve its desired goals. He then shows some techniques and tools to help ensure alignment between architecture and implementation.

The structural change to the digitally networked age affects all industries, as the framework conditions for all companies have changed rapidly. Just as versatile and complex as the change itself is the disorientation in the management floors of established companies. Some persist in alibi actions, some others ignite more or less aimless actionism where orientation, target visions and implementation are required. So Digital transformation management is the ambitious process of managing the transition from traditional business models to digitally-enabled ones. This includes the adoption of new technologies, the optimization or replacement of existing processes, and the development of new strategies, roles and business models. So far so good like any other management process? Unfortunately not, because the technology is only a necessary enabler, but it is relatively easily available. In my experience, it is much more difficult not only to take people with them, but to motivate them to question a lot of the world and mindset in which they have been shaped, which they have learned. Again, everyone will agree, but let's be honest: do you have a common understanding in your management team of what constitutes digital change? Yes, great. No? Then you are the realistic case and too many activities degenerate into "something with digitization". This keynote will provide you with valuable input to transform an organization holistically...and we will probably smile about us as well a few times.

Architecture principles can be applied to detailed design and implementation. Following this idea in case of abstraction and robustness principles leads to code-verification techniques using formal methods (e. g., abstract interpretation). Semantic code-analysis techniques based on abstract interpretation support code correctness, which is the foundation to address important software-architecture goals (e. g., variability, dependability, functional safety, cybersecurity, real-time and concurrency). In this talk, we will motivate the essential connection between architecture and abstract interpretation by presenting concrete examples relevant in safety- and cybersecurity-related systems.

System availability and performance are not stand-alone goals hence non-availability and under-performance of applications and systems in IT landscape will negatively affect user experience and customer satisfaction causing revenue losses for organizations. In a complex, multi-layered, distributed computing environment with so many interdependencies that is impossible to keep track of, full-stack observability enables organizations to find needle in the haystack, by identifying and responding to systems issues before they affect customers. Observability provides multiple stakeholders with actionable insights into the complex, multi-layered, distributed IT infrastructure and is a capability of modern enterprises. Observability enables end-to-end data visibility across multi-layered IT architecture simplifying root cause analysis. DevOps and SRE teams can quickly identify and resolve issues no matter where they originate or at what point in the software lifecycle they emerge. This talk will provide you with an understanding of methods, processes and tools that can leveraged for an enterprise scale observability platform.

This session will introduce embedding vectors and their use in artificial intelligence. It will illustrate how these constructs can be effectively utilized in enterprise AI solutions, specifically in conjunction with prompt engineering. Rainer Stropek will present practical demonstrations using Microsoft's Azure Cloud and OpenAI's ChatGPT 4 model, showcasing real-world application scenarios and potential business benefits. Attendees will gain insights into emerging AI trends and practices in enterprise contexts.

What is green technology? The Green Software Foundation reckons it's all about carbon efficiency and carbon awareness. What are they and what do they mean for the future of software architecture? In this session, I will discuss the fundamental changes to system design that the energy transition demands and talk about the Green Software Maturity Matrix. Reaching carbon zero is only the start of tackling the climate crisis, but that alone may be the most difficult problem humanity has ever had to solve. We all claim to like problem solving. Here's where we prove it. The stakes couldn't be higher.

In software design and software architecture, we often face the question: should we build this generic or specific? Usually, this is not an easy question to answer. The answer depends on a lot of different factors, including future factors you may not be aware of - yet. In this talk, I’ll share my experiences and thought process as a developer and software architect with choosing between generic and specific solutions. I’ll talk about generic vs specific design & architecture, both on a project level and organization level. We’ll look at sharing code/components between teams, inner source culture, monorepo’s, microservices, lifecycle management of generic components and strategic design as a tool to help decide. After this talk, you’ll have practical insights that can help you to choose between generic and specific solutions yourself.

Nowdays, everyone is predecting that AI will kill our jobs or that AI will replace us in upcoming years. AI has been labelled a job killer because it replaces humans with robots for a wide range. The actual thing is that AI is changing our jobroles. Most of the working places will be replaced by AI. We need to upgrade ourselves and get our hands clean on new learnings and tools. AI is also creating new opportunities for us, we just have to adapt to the new environment. This talk will cover how you can upgrade yourself in this chatGPT world and survive your tech jobs using AI/ML domain.

Legacy software makes even experienced developers shudder. But the word "legacy" actually has a negative connotation only in IT. And legacy software practically always solves a business problem successfully, while a newly developed software must first find its niche. This presentation shows how to use these and other insights to come up with strategies for dealing more productively and successfully with legacy software. And that's how to turn the "problem" of legacy into an opportunity.

This talk explores the rapidly evolving landscape of modern data architectures. We take a look into recent developments such as Data Mesh (who would have guessed) and Data Lakehouse, the ELT pattern, Cloud DWHs and theirlike. We also explore the growing influence of software engineering within the data ecosystem. Speaking of software engineering: the integration of analytics systems with the transactional/operative systems will also be taken into account. Typical scenarios and contextual factors of different architectural approaches we will also be discussed. Additionally, I provide insights into the practical implementation of these architectures using tools and technologies commonly found in the “Modern Data Stack.”

Every software system has an architecture, but unfortunately many have a rather accidental one. The success of the project, the maintainability of the software and the acceptance by the project participants and users suffer from this. But explicit software architecture work does not have to be difficult. I show you how to better understand the technical requirements with minimal effort and how to derive the right solutions. And you can record the whole thing transparently for all stakeholders and easily develop it further in the future.

As software professionals, we have witnessed how the landscape of software development is constantly evolving. With an abundance of technologies, frameworks, and methodologies available, making informed decisions can be challenging. We have seen architects struggle with the pressure to deliver solutions that not only meet immediate needs but also stand the test of time. That's why we are providing this talk, "Building Castles, Not Sandcastles: Strategies for Software Architecture Success." Our goal is to empower fellow architects and software enthusiasts with a curated set of practical strategies that will guide them on their decision-making journey. Through this talk, we will delve into the mindset and deliberate thinking required to architect successful solutions. Our strategies are not just theoretical concepts but proven principles that have led to remarkable outcomes in real-world projects. We understand the challenges architects face in balancing immediate project demands with the long-term sustainability of their solutions. That's why our talk will provide actionable tips that can be readily implemented in projects of any scale. Ultimately, our aim is to share insights needed to craft software architectures that withstand the rapid changes in technology and business requirements. We want to architect greatness in everything we do—building castles that stand tall, not fleeting sandcastles.

How did I improve the loading of our application by hundreds of percent? I will talk about our architectural change implementation details, and will teach how we leveraged practical design patterns using Redis, AWS Cloudfront, microservices and observability tools to get top-level performance.

In this session, we take a look at the strategies that can be used for evaluating software architectural design at various stages of the architectural design process. While architectural design is a noble endeavour, it can be costly. Architectural evaluation can take place at various stages of architectural design and to varying levels of detail, but some kind of evaluation is always necessary. In the session we discuss how to carry out software architectural evaluation that is fit for purpose and adds value that is worthwhile for the stakeholders based on the nature of the project.

When analyzing and decomposing legacy systems according to DDD, we encountered domains that were easy to split into subdomains and domains where it was significantly more difficult. Also, the age and level of development of a domain has an impact on our ability to find good subdomains and modularize the legacy. We have since been able to describe these differences and have found and named several domain patterns. I look forward to feedback and discussion from the audience.

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.

How many times have you looked back at a project only to find a mix of technologies, architectural styles, patterns, and practices that somehow just don’t fit together, only to conclude: This is unmaintainable... Let's rewrite the whole thing! As tech professionals, we usually pride ourselves in our ability to think critically because, as part of our work, we continuously tackle complex problems. But are we really critical thinkers? If so, which decisions led to this point? Were they made consciously? What decision framework was used to structure our thoughts and avoid biases? Over the last years of my career, I have applied practices to decision-making that have significantly improved my decision-making and how I evaluate and challenge decisions made by others. In this session, I'll share the essential building blocks that improve critical thinking, help break through biases, and improve our intent and communication when making impactful decisions. You'll learn to apply tactics to help identify assumptions, evaluate options objectively, and assess risk. You'll walk out of this session with actionable takeaways that will help strengthen your decisions in our complex and ever-changing technology landscape.

Domain-Driven Design (DDD) has proven to stand up to many architectures, including microservices. Yet, how can DDD be used in a Function as a Service, or FaaS, serverless architecture? Is it more pain that it's worth? If it's possible, does it have purpose? Where are the pain points and how can they be avoided? This talk explains how to apply DDD with Bounded Contexts and rich domain model behavior while deploying and running in a virtual serverless cloud.

There are no best design practices in Software architecture—everything is a trade-off. But how do you figure out what those are? The answer to every question in software architecture is "It depends." This session starts to answer the follow up question: "Depends on what?!?" It provides a variety of techniques and tools to help architects and other team members understand and evaluate trade-offs.

There are seven fights that I have over and over again, whenever I start at a company. I'm here to convince you that it's valuable for everyone to have these things in mind from the inception of a project. Having these fights early prevents you from doing the software equivalent of poking chocolate chips into an already-baked cookie Details Usually we think of compound interest as what adds magically to our retirement or makes our student loans last forever. But there is also a compound interest of technical debt, where a project is made harder and more expensive because of early "cost-saving" choices. I think it's empowering for developers and other people involved in the inception of a project to have tools for making the project better long-term. The seven things I think should be considered very early in development are: 1. Localization. Are you ever planning on selling this to someone in another country? 2. Security. Don't be the organization that has to pay someone for disaster PR. Building in security early saves you a bunch of time and user churn later. 3. Extensibility. What makes you so sure this API will always be internal? 4. Documentation. People do not buy software solely based on Powerpoints. You need public docs. The docs have to be more useful than Stack Overflow. 5. Affordance. UI is not a word. The microtext matters. 6. Acceptance. Have you shown this to any actual humans who are like the users? 7. Accessibility. We all use computers different ways. Does your software allow that? I expect this talk will be relevant to both senior people working on leading project teams, and empowering for juniors who don't have a structure for critiquing usability problems. I want people to leave with an understanding of how small changes in the initial trajectory of a project can lead to greatly improved outcomes.

A decade ago, developers built information-sharing software by writing a lot of custom code in a single code base, then adding layers of caching. Now we build information systems: interdependent software and services, data platforms, and event streams. In systems thinking circles, a common model is The Iceberg. At the top, visible above the waterline, are the things that happen. Events (like bugs and outages) and patterns that reinforce them. At the bottom, down deep, are our mental models -- the concepts we draw from when we build software systems. I've seen many software-to-systems (aka "digital transformation") initiatives fail. They hit this Iceberg and sink spectacularly. What do we do when that happens? We double down on our traditional approaches. Real transformation can only happen when we go deep into the structures of our collective thinking. Architecture, in the systems age, is not just Kubernetes. It is engaging our mental models and working together to transform them. Our thinking designs our architecture. Scaling up our linear thinking cannot resolve systems challenges. We need to shift to systems thinking.