GOTO Copenhagen 2024

The early years of the second decade of the twenty-first century. A world where Docker was a job people did; K8S was a boyband (probably); Kafka was a euphemism for existential anxiety and Chaos Engineering meant, well, nothing as it hadn’t been invented yet. The Cloud … that was just weather to most people.

It is 2012, and Microservices appeared on the Thoughtworks Technology Radar. 10 years ago, in 2014, Martin Fowler and James Lewis wrote down something that caused a bit of a stir – the definition of Microservices. 10 years later, for better or worse, Microservices have become the predominant architectural style for building software at scale.

So much innovation has occurred in the last decade – Docker and K8S fulfilled the ‘write once and run anywhere’ promise of the JVM. Operations changed beyond recognition as we moved to Cloud Native and FaaS. Testing in Production is a practice that now signifies maturity rather than derangement.

In this keynote, James takes a look at the original nine characteristics of Microservices and explores the lessons we’ve learnt since those halcyon days. (Although Kafka is still a euphemism for existential anxiety.)

After almost 2 years of high attention on coding assistants, many engineering managers are disappointed by the measurable results, and engineers are suffering from hype fatigue, even the ones who have learned to love their new AI team mate. Meanwhile, the pace of change in the AI tooling space is still quite high, which contributes further to the hype fatigue.

This presentation gives an overview of the tooling and features available today, what works and what doesn't, and what might work with more technical advances. It will mostly focus on AI assistance for tasks that involve writing, reading and changing code, but also touch on software delivery tasks that don't touch code directly, like requirements analysis. This whirlwind tour of the AI tooling landscape is based on Birgitta's experience as Thoughtworks' global SME for AI-assisted software delivery.

Responsible technology is having its time in the sun currently. Concerns about misinformation, bias, data privacy, cybersecurity risks, and accessibility issues, to name just a few of the concerns, seem to appear everywhere in the media. Who is the latest organization to be breached? Which airport is recovering from an "incident" - that wonderfully vague word?

Delivering technology in a responsible manner includes considering all the stakeholders to the solution, not just the obvious ones. The various flavors of architects operating across a solution (perhaps just a small number of people wearing different hats) must attempt to bring the perspectives of other stakeholders into the discussion surrounding features, targets, security requirements, and more. Making this work can be a challenge for teams.

In this talk, I will first discuss some principles of responsible technology and describe the various ways that making tech responsible generates value for organizations. I will then discuss how various aspects of responsible tech intersect with our good friends the -ilities. Finally, I will describe some techniques that can be used to support teams on their way to building responsible technology.