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?
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.
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.
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.
Many companies focus on technological questions when transitioning from traditional IT infrastructure to cloud computing. Yet, not all practices, processes, and policies fit cloud-related concepts like DevOps, DevSecOps, PaaS and serverless, zero-trust networking, etc. In this session, Rainer Stropek shares his views on organizational aspects that are crucial for larger organizations that want to benefit from cloud-native software development in hyper-scale public cloud environments.
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.
As software developers, we spend most our time maintaining existing systems – under time and budget pressure. Building new business functionality tends to get more difficult, expensive and risky over time due to increasing size, growing complexity and lack of overview. Although we complain about technical debt, lack of innovation and the architectural deficits of historically _grown_ software, we often patch, fix or hack symptoms instead of curing the root causes of these problems. In this talk you’ll get an overview of the systematically improving or modernizing your system. The approach shown here is based upon the established idea of identifying the specific problems first, before changing or modifying a system. We will take a closer look at different areas of investigation, such as architecture, code, technology, quality requirements, application data plus development and rollout processes, in an iterative breadth-first analysis. For each area of investigation I give examples and show methodical tools for effective and practical use. Afterwards you’ll get an overview of strategical and tactical approaches to specific improvements, based upon the problems and risks found during analysis. The presentation is aimed at software development teams, architects, product owners and technical management. Everything I present in this talk has been proven in software and system projects and reviews I conducted over the last couple of years in various industries – so expect some (anonymized) practical examples!
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.
Autonomous teams are something we often strive for in software projects. Moreover, autonomy itself is often considered a value without defining what it actually is. The talk will look at the question of team autonomy from the perspective of organisations. Can there be autonomous teams? What does autonomy mean within an organisation? Why does it happen that teams are considered as non-autonomous?
And why is the absence of autonomy still valuable? What is the connection between decisions and autonomy? And why does more autonomy inevitably lead to higher communication costs?
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.
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.
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.
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.
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.
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.
Anti-Patterns are like patterns, only more informative. With anti-patterns you will first see what patterns reoccur in “bad” retrospectives and then you will see how to avoid, or remedy, the situation. Based on her experience with facilitating retrospectives, join Aino for an entertaining and informative presentation on the anti-patterns she has seen and how to overcome the problems. This talk is focused on retrospectives, but will be interesting for everyone facilitating any kind of meeting.
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.
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.
What if what we think makes a great leader is all wrong? When you ask people to think of leadership qualities, they tend to choose words like bold, powerful, and fearless. But if you ask people to name traits of the leaders they would like to emulate and/or follow; you get a different list. In fact, from my research, bold, powerful, and fearless don’t break anywhere near the top of the list. So, you have to ask yourself, are you trying to adapt the traits you think will make you a great leader or do you want to cultivate the qualities that people are looking for in a leader they want to follow? Based on my last couple of years of research across many demographics, I’ve compiled a list of qualities others look for in leaders. My message is that because you already possess the traits to be a great leader, you can unleash the power to do great things. This past year and half have presented the world with many challenges that I think we can overcome with strong, genuine leadership. Revolutions and significant changes always start with an individual. We all have a role to play and becoming a genuine leader is the start.
In various communities, several methods for the collaborative modeling of business requirements have been established in recent years. Well-known examples are EventStorming or Domain Storytelling. These approaches are based on achieving a better shared understanding of the business requirements in an interdisciplinary way. But what about the requirements for the quality of the software being developed?
This is where Quality Storming comes in, trying to bring together a heterogeneous set of stakeholders of a product or project to collect quality requirements. The goal is to gain a shared understanding of the real needs for the quality characteristics of a product. To achieve this goal, Quality Storming uses some techniques from various already existing collaborative modelling approaches.
It is not the claim to produce perfectly formulated quality scenarios with the help of Quality Storming. Instead, the method aims to create a well-founded, prioritized basis for later formalization, which is understood across different stakeholder groups. The more often teams work with the technique, the better the quality of this basis becomes over time. Advanced teams are quite capable of creating very well-formulated scenarios within the framework of such a workshop.
In this talks I will introduce the workshop and the ideas behind it. You will also learn many hints for facilitating such workshops and how to proceed with the learnings generated in Quality Storming workshops.
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.
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.
Today it is the world of Data Science. Ample amount of data is available which when utilized at right time in right manner can help to forecast as well as predict in advance any untimely failures/disasters that can cause serious and fatal losses. Out of many, one area where such predictions and Predictive Analytics Software can be of great use is, manufacturing/process industries like power plants, oil and natural gas and many such more.
Predictive Analytics Software not only has components like main stream software-intensive systems, but it also has statistical algorithms, tools, techniques, mathematical components for pattern recognition as well as other techniques like machine learning, artificial intelligence, modelling etc. It also has diverse stakeholders and other connected systems.
Software Architecture is well practiced in main stream software-intensive systems like web, embedded, enterprise applications etc. However, Predictive Analytics being emerging branch, there is a lot of scope for research and enhancement in Software Architecture concepts with respect to such software systems.
With my experience working with Predictive Analytics Software for power plants, in this paper I will talk about following 3 points:
1. Benefits of practicing Software Architecture in Predictive Analytics Software
2. Challenges in using Software Architecture in Predictive Analytics Software
3. Future ahead