Menu
We have been building software systems for over sixty years, and they continue to grow in size and complexity. Not only do we have legacy mainframe systems, but systems in object-oriented programming languages have grown so rapidly and uncontrollably over the last twenty years that many of them have become large obscure tangles as well. All this legacy code drives up development costs and makes us reluctant to touch these old software systems. Is this inevitable? Or is there also good legacy? And what can we do to get our Legacy in good shape and keep it that way?
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 systems often live for many years or even decades, are carefully maintained and patched again and again. But at some point the UI looks dusty, changes take forever and you want to benefit from the possibilities of modern technologies. The decision to modernize the system is made. And then comes the simplest requirement in the world, which we’ve all heard before: ‘But the new system must be able to do the same things as the old one!’ It is not surprising that we hear this requirement so often: it is simple, it can be formulated even if you know the system only superficially, and it seems to be precise. In fact, this requirement is quite nonsensical. In this talk, we will explain why the simplest requirement in the world is nonsense and provide experience, guidance, and best practices for modernization projects where the goal is to design the target state and plan the path of modernization.
We see a lot of confusion regarding architectural work these days. When? How much? Who? Tons of heated debates and nobody asking the essential question: Why? But without asking Why, all the other questions are futile. Thus, we will start this session by asking: *Why* do we need architectural work? Which problem(s) does it address? After finding some surprising answers, we will move on and ask ourselves: *How* can we do it best? What are the key activities of architectural work? Finally, we will ask ourselves: *When* should we do *what* and *how much*, depending on the given context? After this session, we will have created a lot clearer picture what architectural work actually is about – without the usual fuzz, stripped down to its pure essence.
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.
In our audits we identify major challenges for the future-proofness of software systems. Our customers range from public administration to DAX companies, startups and the church. In this talk we share our experiences from analyzing more than 100 systems during the last ten years. The challenges include inscrutable code organization, vintage technology stacks, architectures without modularization and customer variants created by copy and paste.
What these challenges have in common is that they do not simply drop out of a tool. Instead, each challenge is preceded by collecting evidence, tying together manual inspection and automated analysis, applying appropriate visualizations and making the right conclusions. Hence, we do not only share the final results, but focus on the methodology and individual steps we made to identify the challenges. We hope this will be inspiration for other architects to identify challenges in their own systems.
Naming is hard. Teams who write software often give rather technological names to the components they write. This is a problem because it makes the system less understandable and more difficult to extend. I propose to show more respect to the language that the users and other domain experts speak because it will allow us to think as they think which will make our software more compatible with the users’ mental models. Let’s call the modules, components, interfaces, services and entities as business-friendly and technology-neutral as possible and use some patterns from Domain-Driven Design to achieve an architecture that is well-structured, easy to explain and maintain over the years. It’s a matter of attitude and attention, folks!
One of the objectives of software architecture is the understanding and communicating complexity. We have long recognized that the most effective way to communicate complexity is via human language. But language poses a challenge when working in a team comprised of members of different (sub)cultures and nationalities, each with a native language that might not be the same as the language we are communicating in. Each of these cultures has a different perception about how to communicate effectively. By way of example, in some cultures, it is considered appropriate and respectable to use the tentative voice “perhaps we should consider trying X”. Whereas in other cultures it is the assertive voice that is valued “This is how we should do it”. Assuming that everybody in the room wants to communicate effectively, what aspects can we define that impact our design? What organizational culture fits better with what type of architecture (microservices, monolith)? And what cultural needs must these architectures and boundaries address to succeed? Join us in this interactive talk where we together explore these challenges!
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
IT is characterized by innovations and rapid changes. Sustainability, and with it the interests of the next generation, has not been as much of a focal point so far. However, in order to achieve the ambitious climate targets, the IT sector, as an important driver of digitization, has to make its contribution as well. An intelligent use of resources to avoid waste and litter is a start here. The experience gained in economical energy consumption on a large scale in the cloud, but also on a small scale in the embedded sector, can also be useful for companies. I present some aspects that have received too little attention as of yet and how one can improve one’s climate footprint by switching to a “green cloud” and other processor architectures. Thereby, the competing interests of economy and ecology can be better combined.
When was the last time you took a day off? Are you going to the office every weekday? How often do you work with people? All these questions usually show one thing – we all have stress that comes from our work. Famous Work-Life balance is often non-existent in many organizations, and developers feel trapped in their daily routine to “deliver a business value” to their employer. With stress, your creativity shrinks and innovative approach dies in a busy work you do.
What if I was to say it does not have to be that way? In this talk, we will discuss ways how to relax and avoid “Stress Driven Development”. We will look at the problem from a perspective of an individual contributor, a technical lead, and a manager. As a result, the audience will be able to take away best practices for tackling stress and help others in their organizations to become more productive and simply happier individuals.
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.
What is the internal structure of your cloud-native Java microservice? How do you organize your SPA / PWA frontend? Is there a relation between the frontend and backend design? This session will introduce a consistent, feature-driven, standards-based structure called BCE and apply it to microservices and SPAs. I will create and review a lot of code and present the ideas on a few slides. Your questions are highly appreciated.
Individuals have a different tolerance for ambiguity and change. This personality trait affects how we make decisions, prioritise and choose solutions. We are in a VUCA world and tolerance of ambiguity is an essential trait to be effective, productive and calm. In this session you will learn to understand the VUCA environment and how to navigate it, reflect on your ambiguity tolerance and get valuable information on how to build and maintain ambiguity tolerance for yourself and the team. You will get a first orientation to become a master and not a victim in dealing with ambiguity.
Natural language processing (NLP) has made incredible strides in the past few months. With these new possibilities and more and more textual data, we will see an increasing demand for NLP-based development. We have built several NLP-based systems in productive quality over the past eight years. It didn’t always go completely smoothly and the product didn’t always deliver what we wanted to achieve in the end. In this lecture we would like to report on our experiences: 1. What are the use cases of text analytics? 2. Which specific information can be extracted from text using NLP libraries? 3. What are the limits of text analytics? This talk should encourage to deal with NLP but at the same time slow down the current euphoria and expectations.
Certainty is the comfort zone of software architecture. The idea that architecture offers a dependable, stable and solid foundation on which to build. Sadly, such certainty is in conflict with the nature of reality. By definition, most software development is development in the presence of incomplete knowledge. Any development process that offers certainty of knowledge through early planning is faking and bluffing that certainty. This talk looks at the relationship of knowledge to software, the codification of knowledge in architecture, the acquisition of knowledge to development process, and how we can make progress in the presence of known unknowns, unknown unknowns and unknowable unknowns.
In development and implementation of AI-based systems , the main challenge is not to develop the best models/algorithms, but to provide support for the entire lifecycle – from a business idea, through collection and management of data, software development managing both data and code, product deployment and operation, and to its evolution. There is a clear need for specific support of Software Architecture for AI. In this talk we will show the different aspects of a Software Architect has to master to integrate AI-based technologies, like for instance patterns for AI-based solutions, mastering a new development approach or handling requirements and safety issues with AI-based systems.
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.
Cloud storage footprint is in exabytes and exponentially growing and companies pay billions of dollars to store and retrieve data. In this talk, we will cover some of the space and time optimizations, which have historically been applied to on-premise file storage, and how they would be applied to objects stored in Cloud. Deduplication and compression are techniques that have been traditionally used to reduce the amount of storage used by applications. Data encryption is table stakes for any remote storage offering and today, we have client-side and server-side encryption support by Cloudproviders. Combining compression, encryption, and deduplication for object stores in Cloud is challenging due to the nature of overwrites and versioning, but the right strategy can save millions for an organization. We will cover some strategies for employing these techniques depending on whether an organization prefers client side or server side encryption, and discuss online and offline deduplication of objects. Companies such as Box, and Netflix, employ a subset of these techniques to reduce their cloud footprint and provide agility in their cloud operations.
During my career in IT and people development I had several turning points where I either was made to use journaling techniques or experimented with them myself to successfully tackle the next challenge. Over the years I reflected why those ‘written self-reflection’ techniques are so powerful and – at the same time – they are still quite rarely used in the business context. In this workshop I will happily share my experience and my findings backend by a scientific psychological model with you! You want to leverage your resources?
You want to change habits in your life’s “departments”? You want to harvest outstanding outcomes – at work and beyond? YES? Then join us to get ready for ACTion and be inspired how to leverage journaling techniques – at work & beyond. We’ll even use our hands, hearts and minds to directly try out some of them!
Our hope is that anyone looking to embark on a legacy modernisation programme or who is currently involved with one will find some useful advice here. We have spent most of the last couple of decades helping large organizations 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 we describe several of the legacy supplanation patterns that we found to be successful as well as some of the “anti-patterns” that more often than not lead to failure. For each pattern, we describe a particular approach, the context where it’s effective and explain how and why you might use them, giving real world examples along the way. Key to our approach is seeing legacy replacement as a holistic activity that cuts across technology, business processes and organisation structure. In more detail using these patterns often means discovering how one large technical solution meets multiple business needs and then seeing if it is possible to extract individual needs for independent delivery using a new solution. We describe how different elements of current solutions might be mapped to business capabilities and, using examples, how the various patterns can then be used to incrementally deliver these replacement solutions over time. A common objection is that finding these “seams” in existing systems is too difficult. While we agree it is challenging at first, we have found it to be a better approach than the alternatives which all too often result in Feature Parity and Big Bang releases. We describe these anti-patterns as well as some of the underlying organisational reasons many legacy replacement programmes fail. This talk is drawn from material being produced in collaboration with Martin Fowler and James Lewis which will be published in the coming months on Martin’s site.
Recent research summarised in the book Accelerate points to a set of practices that lead to high software development organisation performance. Simultaneously, research from the Santa Fe institute on Complex Adaptive Systems over the last 20 years seems to point to a grand unified theory of organisational design. So have we cracked it? Do we now have the answer to the question: how do we create and scale high performing software and organisations? In this talk, James explores the relationships between team structure, software architecture and the emergent phenomenon of complexity science.
Software metrics can be used effectively to judge the maintainability and architectural quality of a code base. Even more importantly, they can be used as canaries in a coal mine to warn early about dangerous accumulations of architectural and technical debt. I will introduces some key metrics that every architect should know (e.g., average component dependency, propagation cost, structural debt index, and more). Then I will talk about the journey to create a metric to measure maintainability and introduces a new metric maintainability level. This metric is promising because its value usually matches quite well the gut feeling of developers about the maintainability of their software systems. Therefore, it can be used to monitor code maintainability and as an early warning indicator if things move in the wrong direction.
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.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
