In my previous books, I’ve focused on principles and practices (e.g., Three Ways, Four Types of Work). However, I’ve always wanted to describe the spectrum of cultural, experiential and value decisions we make that either enable greatness or create chronic suffering and underperformance. They are currently as follows:

Almost five years ago I published at manifesto of sorts at https://principlesofchaos.org to define a new discipline in software engineering called Chaos Engineering. It wasn’t about creating chaos, but rather identifying the chaos inherent in a complex system. The other practices that commonly address availability (incident management, alerting, monitoring, disaster recovery, etc) are all reactive: they focus on time to detect, and time to remediate. Chaos Engineering on the other hand is proactive: finding systemic vulnerabilities before they affect customers. Now that Chaos Engineering has high adoption at big tech companies and non-digital native orgs alike, we can look at how the practice is maturing. Our knowledge of systemic properties of complex systems is improving and leading us into a new era of Continuous Verification.

Taming the complex distributed systems we're responsible for requires changing not just the tools and technical approaches we use; it also requires changing who is involved in production, how they collaborate, and how we measure success.

In this talk, you'll learn about several practices core to production excellence: giving everyone a stake in production, collaborating to ensure observability, measuring with Service Level Objectives, and prioritizing improvements using risk analysis.

Increasingly our software systems have to be right the first time. The costs of software failures can devastate companies and hinder governments. Security breaches can have societal impacts that can last years. Software is hard to design and implement. Let alone design and implement well. What can we do to be better at designing and delivering better, safer, and more secure software and systems? Does language choice, such as Java vs. C++ vs. C vs. Erlang matter in terms of producing better software? When does security become a quality concern? Will AI lead to better or worse software and systems? In this session, we will discuss lessons learned from, among other things, almost a decade of working on NASA software projects that had to work correctly or people could die. And how these lessons continue to impact the speaker's mindset and outlook daily.

Distributed and concurrent systems can be considered a social group which collaborate to achieve collective goals. In order to collaborate a system of rules must be applied that affords good hygiene, fault tolerance, and effective communication to coordinate, share knowledge, and provide feedback in a trusted manner. These rules form a number of protocols which enable the group to act as a system that is greater than the sum of the individual components. In this talk we will explore the history of protocols and their application when building distributed systems. Protocols provide the foundation on which the quality attributes are delivered. Qualities such as performance, resilience, and security.

Is it possible to enable the evolution of a monolith? After a hugely expensive (financially and culturally) failed attempt at a complete rewrite, Ticketmaster is attempting to do just that, bounce back and evolve the monolith that is Ticketmaster’s core ticketing platform. This multi-year effort requires striking a delicate balance between showing appropriate respect for the platform’s highly profitable 40 plus year history while not allowing past success to blind us to demands of a highly dynamic market of fans, artists, venues, and more. This is not a session about best practices for developing your monolith; this session is the true (and at times ugly) story of one company’s journey towards a more flexible, adaptable, and easily maintainable architecture supported by a culture that prizes learning and respect above all else.

This presentation will challenge a common movement that is sweeping the lands unnoticed. Agile micro-service projects that live in a single VCS repository, that are slow to test, hard to understand need to be deployed and versioned as a single unit. While that sounds silly, ask these questions of your project:

• Are you using a layered architecture?
• Do you generally have an interface for each class (Java/.NET)?
• Do your Views live in one folder and your ViewModels in another?
• Has your platform’s package manager made it too easy to just add, more?
• Has your team mistaken “reuse” as a goal, not an outcome?
• Does your team favor living code over doco, yet no one understands how the system works?
• Could you make a one line code change, test it, commit it, package it and deploy it in under 15min?
• Do you think you are doing Microservices, but all the code lives in the same repo? Share the same contracts? Get versioned and deployed together? Share a data store?

Even if you are not on the Microservices band wagon, will your framework of choice be relevant in 5 years? Can your team pivot to new libraries, GUI or data store technologies in days or weeks? Or, are you actively building the next legacy project churn-and-burn style?

This session will pose some challenges to prevailing convention and ask how did we get here. More importantly we will discover the costs of our decisions and how we start applying an engineering instead of religious approach to design.

Birds do it, bees do it. Even ants and fish in the sea do it. When certain individuals group together, they create a “swarm intelligence”— a collective brain capable of solving complex problems which would be insurmountable for an isolated individual. In the world of artificial intelligence, swarm engineering allows us to make robots that work in large numbers (under 1000), and tiny sizes (under 1 cm). Swarm strategies are either inspired from nature (ant colonies, fish shoals, bird flocks, cellular systems) or are automatically discovered using machine learning and crowdsourcing. Demonstrated applications range from the deployment of swarms of flying robots to create outdoor communication networks, or the use of 1000 coin-sized robots to form structures and explore the environment, to the design of nanoparticles for cancer treatment.

On the strange love that monitoring systems have for watching response times, and why things seem to still work in spite of it all.

"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 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 of the lost art of software design, and how we can reintroduce it.

Recent research summarised in the book Accelerates 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 this research and takes a look at the surprising links between microservices, elephants, Sydney and companies.

At the Financial Times, we built our first microservices in 2013. We like a microservices-based approach, because by breaking up the system into lots of independently deployable services - making releases small, quick and reversible - we can deliver more value, more quickly, to our customers and we can run hundreds of experiments a year.

This approach has had a big - and positive - impact on our culture. However, it is much more challenging to operate.

So how do we go about building stable, resilient systems from microservices? And how do we make sure we can fix any problems as quickly as possible?

I'll talk about building necessary operational capabilities in from the start: how monitoring can help you work out when something has gone wrong and how observability tools like log aggregation, tracing and metrics can help you fix it as quickly as possible.

We've also now being building microservice architectures for long enough to start to hit a whole new set of problems. Projects finish and teams move on to another part of the system, or maybe an entirely new system. So how do we reduce the risk of big issues happening once the team gets smaller and there start to be services that no-one in the team has ever touched?

The next legacy systems are going to be microservices, not monoliths, and you need to be working now to prevent that causing a lot of pain in the future.

Many organizations these days need to manage a mix of the following infrastructure types:

• Bare Metal
• Public Cloud
• Private Cloud

While each type has its own challenges, many organizations now need to expand from managing bare metal to managing two or three types in parallel.

We have a look at some common challenges teams face adapting to these changes, and look for patterns and principles to help ease the expansion.

Organisations adopting agile practices tend to throw out the old practices of requirements gathering, up front system design and careful analysis in favour of writing code just in time and pushing into production multiple times per day.

Doesn’t this make us far less secure?

Michael will provide a whirlwind tour of real world security today and use that to address this question and talk about the tension between agile and security - and offer ways that you can resolve this tension.

Data breaches are the new normal. We’ve created ecosystems with so many moving parts and so
many complex units, it’s little wonder that we so frequently see them go wrong. A combination of
more systems, more people, more devices and more ways than ever of producing and publishing
data stack the odds in favour of attackers breaching more systems than ever.

In this talk, you’ll get a look inside the world of data breaches based on my experiences dealing with
billions of breached records. You’ll see what’s motivating hackers, how they’re gaining access to data
and how organisations are dealing with the aftermath of attacks. Most importantly, it will help you
contextualise these incidents and understand both what these attacks actually look like and how to
defend against them in your organisation.