Menu
Independent Consultant, Founder of DeveloperToArchitect.com
Socio-technical and Domain-Driven Design architect. Facilitator of visual and collaborative modelling with Deep Democracy
Fraunhofer IESE, Expert Data-Intensive Systems Design
Amazon Web Services EMEA SARL, Containers Specialist Solutions Architect
Global Leader of API Strategy at MuleSoft, a Salesforce Company
Freelance; Consultant; Full-Stack Software Engineer
CTO at Endava, Co-Author of Continuous Architecture in Practice
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speakers will start after lunch break each day due to the time difference.
Software architects have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which this platform-agnostic class highlights by investigating what makes architecture so hard. This class is divided into 2 main parts. Pulling things apart (Part 1) focuses on how to break up systems and identify levels of modularity. However, once you’ve broken apart your systems, how do you tie them back together? Putting them back together (Part 2) focuses on just this – the techniques of how to do contracts, orchestration, workflows, and transactions, while keeping everything loosely tied together and running smoothly.
Functional Software Architecture is architecture using functional programming. Not everything is different, but almost. Primarily: – pervasive use of immutable data / value objects – documented and controlled side effects – higher-order abstractions, based on math – combinator models These four building blocks make for architecture that is more robust and more flexible than traditional OO architecture: fewer dependencies, better reuse, less complexity. Moreover, the abstraction facilities in FP are more powerful, affording better models that are closer to the domain, come with less technical overhead, and can dredge hidden domain knowledge to the surface. This all works well with the strategic patterns of DDD. The workshop gives an introduction with examples that you can follow along.
Did you ever experiment tension between different people inside of an organisation, with regards to design strategies? On one field, the Enterprise Architects and their business capabilities, and on the other side the Domain-Driven Design practitioners with their patterns? Endless hours of discussion about the design strategy, leading to waste and polarisation. What if we could combine these two worlds? Are they so different? Join us on this hands-on, where we will work a serious of exercises where you can leverage business capabilities modelling and strategic Domain-Driven Design patterns to model different functions inside of an organisation. You will learn on to move from the different methods while leveraging the strengths of each other. Leveraging those perspectives, you can start modelling based on intention, creating highly autonomous agents, whilst aligned with the organisation purpose and mission. If your role is architect, line manager or you just want to gain experience in modelling at the enterprise level, then this is the right spot. We will model a use case, and walk through several scenarios where we apply the different modelling techniques. Previous knowledge of Strategic Domain-Driven Design and Enterprise Architecture is welcomed, but not required. You will leave the hands-on with a toolset that will allow you to apply to your product portfolio, creating sensible boundaries.
Distributed data-intensive systems are increasingly designed to be only eventually consistent. Persistent data is no longer processed with serialized and transactional access, exposing applications to a range of potential consistency and concurrency anomalies that need to be handled by the application itself. Controlling concurrent data access in monolithic systems is already challenging, but the problem is exacerbated in distributed systems. To make it worse, only little systematic engineering guidance is provided by the software architecture community regarding this issue. Susanne shares her experiences from different case studies with industry clients, and novel design guidelines developed by means of action research. In this hands-on workshop you will learn settled and novel approaches to tackle consistency- and concurrency related design challenges. After the workshop you will know how to use them in practice, and in combination with Domain Driven Design (DDD). The goals of this workshop are: • You learn the most fundamental basics of ACID transactions, distributed transactions, Sagas, Multilevel Transactions, Eventual Consistency, Conflict-Free-Replicated Data Types (CRDTS), ACID 2.0 and the CALM Theorem.
• You learn the general recommendations of DDD in relation to consistency, transactions and concurrency control. • You learn and practice novel design guidelines and patterns extending the DDD philosophy. These will enable you to design distributed data-intensive systems in such a way that you can exploit the benefits of eventual consistency, and at the same time avoid its common pitfalls. Workshop participants should already have some basic knowledge in distributed systems, database transactions and DDD.
Note: This full-day workshop will be split over two days (Monday and Tuesday) as the speakers will start after lunch break each day due to the time difference.
Software architects have no clean, easy decisions: everything is a terrible trade-off. Architecture has lots of difficult problems, which this platform-agnostic class highlights by investigating what makes architecture so hard. This class is divided into 2 main parts. Pulling things apart (Part 1) focuses on how to break up systems and identify levels of modularity. However, once you’ve broken apart your systems, how do you tie them back together? Putting them back together (Part 2) focuses on just this – the techniques of how to do contracts, orchestration, workflows, and transactions, while keeping everything loosely tied together and running smoothly.
When one’s app is challenged with poor performances, it’s easy to set up a cache in front of one’s SQL database. It doesn’t fix the root cause (e.g. bad schema design, bad SQL query, etc.) but it gets the job done. If the app is the only component that writes to the underlying database, it’s a no-brainer to update the cache accordingly, so the cache is always up-to-date with the data in the database. Things start to go sour when the app is not the only component writing to the DB. Among other sources of writes, there are batches, other apps (shared databases exist unfortunately), etc. One might think about a couple of ways to keep data in sync i.e. polling the DB every now and then, DB triggers, etc. Unfortunately, they all have issues that make them unreliable and/or fragile. You might have read about Change-Data-Capture before. It’s been described by Martin Kleppmann as turning the database inside out: it means the DB can send change events (SELECT, DELETE and UPDATE) that one can register to. Just opposite to Event Sourcing that aggregates events to produce state, CDC is about getting events out of states. Once CDC is implemented, one can subscribe to its events and update the cache accordingly. However, CDC is quite in its early stage, and implementations are quite specific. In this talk, I’ll describe an easy-to-setup architecture that leverages CDC to have an evergreen cache.
Software architecture is a soft term, apparently able to mean whatever the speaker intends it to mean at will, with little to no argument from the audience, industry, or other architects. One would think that by this time in our industry’s lifecycle, we’d have nailed some of this down by now, so let’s do that — let’s nail down what software architecture looks like in the modern software development age, including nods to agile practices, continuous-everything and DevOps, polyglot programmers and maybe even a kitten.
The talk discusses, if event-driven architectures can be used in an advisory software as a form of reactive architectures. To do so, business requirements as well as technical implementations are covered. Why was the event-driven approach been selected? Requirements either business or technical are discussed, which drives the selection of an event-driven architecture. The event-driven approach is the most suitable to support decoupling of systems and to give the end user a comprehensive view about the activities along the advisory process. 1. Introduction of rough requirements to the advisory software 2. Introduction of the advisory process 3. Variant as controlling process (classical architecture) 4. Variant as event-driven architecture (reactive architecture) 5. Advantages and disadvantages of the selected approach
6. Take aways
Software Architecture is about the important things, where “important” means high-risk and hard-to-change decisions. DevOps tries to develop a culture where constant experimentation and learning takes place while the environment changes rapidly. How can this fit together? In this talk I will talk about general strategies agile teams can use to build and foster a DevOps culture while at the same time ensuring high-quality and sustainable software delivery. These strategies will be illustrated with real-world examples from different domains and environments.
Today, end users often expect subsecond response time and 100% uptime, often for applications dealing with terabytes of data. Reactive systems can address these requirements, as they are more flexible, loosely coupled, and scalable, making them easier to develop and amenable to change. They are also significantly more tolerant of failure, and when failure does occur, they meet it with elegance rather than disaster. Reactive systems are highly responsive, giving users effective interactive feedback. In this session, you learn how users adopt reactive patterns for their high-performance applications and have a look at typical, well-architected implementations on AWS.
Micro Frontends are not the only solution and – unsurprisingly – not always suitable. Hence, in this session, I present an alternative frontend architecture that we have successfully used in numerous enterprise projects in recent years: the Frontend Modulith. We discuss dividing your applications into less complex parts, the mapping of your business domains, the categorization of libraries, and access restrictions for enforcing your intended frontend architecture. You will also see how you can drastically improve the performance of your CI process with incremental builds and tests as well as local and distributed build caches. The examples use Angular and Nx, a tool that comes from former Google employees and supports the development of structured enterprise applications with frameworks like Angular or React. In the end, you know whether Frontend Moduliths are the right approach for you and how you can use them to build sustainable frontends for your enterprise solutions.
Rapid, reliable, frequent and sustainable software development requires an architecture that is loosely coupled and modular.
Teams need to be able complete their work with minimal coordination and communication with other teams.
They also need to be able keep the software’s technology stack up to date.
However, the microservice architecture isn’t always the only way to satisfy these requirements.
Yet, neither is the monolithic architecture.
In this talk, I describe loose coupling and modularity and why they are is essential.
You will learn about three architectural patterns: traditional monolith, modular monolith and microservices.
I describe the benefits, drawbacks and issues of each pattern and how well it supports rapid, reliable, frequent and sustainable development.
You will learn some heuristics for selecting the appropriate pattern for your application.
Event-driven architecture is the pattern du jour in microservices world. But there’s more to event-driven than just asynchronous communication. Let’s talk semantics – what does “event” actually mean? Spoiler: Not everybody who uses the term means the same thing. It’s all too easy to get confused when people talk about Event Sourcing, Event Streaming, Event-Carried State Transfer, Notification Events, Domain Events, Fat Events, Event Storming and possibly yet other types of events. And above all – why should you even bother with an event-driven architecture, what are the benefits? Time for a proper clean-up. Let’s start with a clear and bounded definition of events, and from there explore the patterns of using events in micro- and macro-architecture, their benefits as well as challenges. After the talk, participants will know what questions to ask if someone suggests to go event-driven, and will be able to assess the applicability of different approaches to their architectural tasks.
A clean architecture is for greenfield projects is relatively easy. However, we usually work on legacy systems and an architecture must adapt in an evolutionary manner – otherwise it will also become legacy very quickly.
This talk will show different approaches how to improve legacy systems with domain-driven design. It will focus on different techniques for introducing bounded contexts and assessing where improvements are needed. In this way, Domain-driven Design becomes possible where it is needed most – in existing systems that are often very successful and critical from a business perspective, but were originally developed with no regard to DDD.
Large financial institutions are at a crossroads: from the nineties, the industry invested massively in first-class reliability and resilience, but modern tech is putting pressure, pushing innovation at breakneck speed, creating a fluid transaction ecosystem, and churning out ever-evolving sets of products and tech talent. In this talk, we will cover our experience liberating the data in the mainframe with a hybrid serverless/containerized solution built on AWS. It’s an architecture with tens of Java serverless functions that live-stream mainframe data to the cloud, using a suite of services capable of operating at hundreds of rps: DynamoDB, Lambda, API Gateway, Fargate. We will do a deep dive on various integration patterns and AWS services that can be used to support them. We will dedicate a special section at performance optimizations done to reduce the cold start problems and support aggressive performance targets. In the last section, we’ll use Lake Formation to create a data platform that can enable a host of new value-add activities for the entire company.
Not taking into account what a piece of software represents in real life can lead to higher complexity, additional development costs, difficult refactorings, and ultimately, a software that no longer scales.
If it gets far enough out of hand, at some point, new features cannot be implemented if they’re not compatible with the current architecture, because they would be too expensive to implement.
In this session, we’ll look at some real-life examples and at some of the things to keep in mind in order to avoid the above-mentioned issues.
Microservices, and especially the event-driven variants, are at the very peak of the hype cycle and, according to some, on their way down. Meanwhile, a large number of success stories and failures have been shared about this architectural style. In this session, Allard elaborates on how to achieve the benefits of Event-Driven Microservices by not focusing on the Event-Driven aspect and avoiding Microservices, to begin with. He will discuss how a different way of looking at Messaging allows a system to gradually evolve, maybe with microservices as an end result. And maybe, after all, there is something about events that drives these services…
Software architecture emerged in the 1990s, and has been evolving ever since, from a directive, up-front activity, where a single architect created the architecture, which was then implemented by others, to today’s team based adaptive architectural approaches where architecture is a shared activity owned by the entire team. In this talk we’ll explore the architectural practices that deliver architecture as a “shared commons” which supports the Agile+DevOps ways-of-working needed for success in the digital age.
As the worlds of RESTful APIs and asynchronous events converge, it is clear that organizations struggle with understanding and designing highly-integrated, highly-distributed systems. This session will teach attendees a new, visual approach to integration design and analysis that includes synchronous APIs, asynchronous events, and other integration methods such as batch and streaming.
“Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from “big design up front” in the 20th century, to “emergent design” and “evolutionary architecture” in the 21st. In their desire to become “agile”, many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it’s a misinterpretation and misapplication of the agile manifesto. As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be communicated, assessed, or reviewed. If you’re willing to consider that up front design is about creating a sufficient starting point, rather than creating a perfect end-state, you soon realise that a large amount of the costly rework and “refactoring” seen on many software development teams can be avoided. Join me for a discussion about the lost art of software design, and how we can reintroduce it to help teams scale and move faster.
Evolutionary Architecture is a natural culmination of both the maturing of Agile software development and the increasing role of patterns in architecture. This talk will describe the evolution of evolutionary architecture, examining the role of patterns, I will then review the various principles of evolutionary architecture, focusing on the integration of these principles into enterprise systems.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
