Neal Ford  |
  • Author, ThoughtWorker, & Meme Wrangler

Conference Presentation Abstracts and Slides

I’m an avid speaker at software development conferences. Most conferences require talk abstracts to describe the content and thrust of the talk, and it’s often easier to point them to a comprehensive list than send them piecemeal. Thus, this is the list of presentations I’m actively submitting to conferences.

Keynotes

Keynotes differ from “regular” sessions in three important ways. First, they are shorter in duration (50-60 minutes). Second, keynotes are designed to be entertaining to a more diverse audience. Regular sessions tend to deep dive on one topic area, whereas keynotes may cover a wide variety of topics, exposing surprising connections between seemingly disparate subjects. Third, they are more abstract than regular sessions, attempting to invoke Deep Thoughts rather than purely factual exposition.

Workshops (1/2 or full day)

Workshops are multi-segment courses with deeper content and hands-on exercises.

90 Minute Sessions

A note about timing
The presentations listed below are designed for a particular time interval. Presentations are not fractal: they cannot be arbitrarily shortened or lengthened. I may be able to produce a different timed version, but please ask before assuming.


A note about Evolutionary Architectures

Astute readers may notice three different talks titled Evolutionary Architectures on my site: a keynote, a workshop, and a 90-minute session. They are all derived from my upcoming book, but targeted at different audiences:

Keynotes

Why does Yesterday's Best Practice Become Tomorrow's Antipattern? [slides]

Modern software development exhibits a curious trend: Yesterday’s Best Practice Becomes Tomorrow’s Antipattern. Why? EJB and SOA were once Best Practices, now shunned as anti-patterns. This keynote investigates why this trend continues, including increased tech stack complexity, primordial abstraction ooze, code reuse abuse, strangling dependency management, and the fundamental dynamic equilibrium of the software development ecosystem. I also investigate How to Avoid Yesterday’s Best Practice from Becoming Tomorrow’s Antipattern, including domain centric architectures, immutabile infrastructure, evolutionary architecture, incremental architectural change, and how to favor evolvability over predictability. Also includes figurative and literal dumpster fires.


Evolutionary Architectures Keynote [slides] [workshop]

An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This keynote, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This keynote provides a high-level overview of a different way to think about software architecture.


Stories Every Architect Should Know [slides]

Those who cannot remember the past are condemned to repeat it.  –George Santayana
The past is never dead. It’s not even past. –William Faulkner

The history of software architecture contains rich lessons, yet architects constantly clamor only for the latest and greatest. This keynote recounts a variety of stories of projects that failed architecturally…and why. Ranging from the Vasa in 1628 to Knight Capital in 2012, each story tells of a mistaken interpretation of some architectural fundamental principle. Attendees learn from the mistakes of the past, to avoid or at least recognize them when they appear tomorrow.

Workshops

Software Architecture Fundamentals Workshop [slides]

The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren’t there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it’s a fast moving discipline, where entire suites of best practices become obsolete overnight.

Part One  [slides]

Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, architectural patterns, and soft skills. While we can’t make you an architect overnight, we can start you on the journey with a map and a good compass. Part one covers:

Part Two  [slides]

Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including translating requirements, comparing service-based architectures, soft skills, architecture refactoring, and more. Part two covers:

Part 3 (hands-on): Architectural Katas [Katas »]

To fully leverage knowledge, you need application. Part three of this workshop uses the public domain Architectural Katas exercise to apply learnings from the first two parts.

From the Architectural Katas website:

Architectural Katas are intended as a small-group (3-5 people) exercise, usually as part of a larger group (4-10 groups are ideal), each of whom is doing a different kata. A Moderator keeps track of time, assigns Katas (or allows this website to choose one randomly), and acts as the facilitator for the exercise.

Each group is given a project (in many ways, an RFP–Request For Proposal) that needs development. The project team meets for a while, discovers requirements that aren’t in the orignal proposal by asking questions of the “customer” (the Moderator), discusses technology options that could work, and sketches out a rough vision of what the solution could look like. Then, after they’ve discussed for a while, the project team must present their solution to the other project teams in the room, and answer challenges (in the form of hard-but-fair questions) from the other project teams. Once that challenge phase is done, the room votes on their results, and the next project team takes the floor.

Part 3, Architectural Katas, is an instructor-led hands-on Katas exercise.


Evolutionary Architecture Hands-on  [slides]

An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This workshop, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how different parts of architecture interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This hands-on workshop provides a high-level overview of a different way to think about software architecture.

Outline: * Architecture Dimensions * Engineering Incremental change * Architectural Characteristics * Exercise: determine appropriate characteristics * Identifying Components * Identifying Architectural Patterns * Exercise: components and patterns * Identifying Fitness Functions * Exercise: determining fitness functions * Retrofitting Existing Architectures * Building Evolvable Architectures

90-minute Sessions

Build Your Own Technology Radar [slides]

ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about what technologies are interesting and where we spend our time. This is a useful exercise both for you and your company. This session describes the radar visualization, how to create litmus tests for technologies, and the process of building a radar. You need two radars. As an individual, a technology radar helps guide your career decisions and focus your precious R&D time. For your company, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. Attendees leave with tools that enhance your filtering mechanisms for new technology and help you (and your organization) develop a cogent strategy to make good choices.


Comparing Service Based Architectures [slides]

Microservice architectures are quite popular, described as “SOA done correctly”. But what are the real differences between Service Oriented, Service Based, and Micro_service architectural styles? And what about middle ground between the _shared everything of SOA versus shared nothing of microservices? This talk explores the similarities and differences between various service-oriented architectural styles. I describe the characteristics of SOA, microservices, and hybrid service-based architectures, along with decision criteria to choose between them. I also discuss specific engineering practices, orchestration styles, reuse strategies, and migrating between architectural styles (e.g., from monolithic applications to service-based or microservice). No one architecture can solve every problem, and many projects take on more complexity than necessary by choosing the wrong paradigm. This talk equips attendees with the knowledge and context to choose the architecture that best fits their needs.


Continuous Delivery for Architects [slides]

Yesterday’s best practice is tomorrow’s anti-pattern. Architecture doesn’t exist in a vacuum, a painful lesson developers who built logically sound but operationally cumbersome architectures learned. Continuous Delivery is a process for automating the production readiness of your application every time a change occurs–to code, infrastructure, or configuration. Some architectures and practices yield code that works better in this environment. This session takes a deep dive into the intersection of the architect role and the engineering practices in Continuous Delivery. I first set context for the information you must master before delving into the nuances of modern architectural concerns. I discuss the role of metrics to understand code, how Domain Driven Design’s Bounded Context reifies in architecture, how to reduce intra-component/service coupling, the tension between coupling and cohesion, microservices architectures, and other engineering techniques.


Evolutionary Architectures [slides] [workshop]

An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.

For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.

The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This talk illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.


Feature Toggles and Hypothesis-driven Development [slides]

Agile development claims to abhor “Big Design Up Front”…yet what is that giant backlog building session but BDUF in other clothing? Back in the olden days of software development, we were forced to speculate on what users want, then build it. We were basically running a buffet. But what if we could switch to à la carte? With modern engineering practices like Continuous Delivery, we can shift our perspective and start building by hypothesis rather than speculation. This talk shows the full spectrum of software development, from ideation through execution and deployment, through the lens of modern software engineering practices. I discuss building a true MVP, then building a platform using feature toggles, canary releases, A/B testing, and other modern DevOps tools to allow you to run experiments to see what your users really want. By building a platform for experimentation, product development shifts from up-front guessing to market driven. This talk unifies the practices of modern architecture, DevOps, and Continuous Delivery to provide a new approach to feature development.


Stories Every Architect Should Know [slides]

Those who cannot remember the past are condemned to repeat it.  –George Santayana
The past is never dead. It’s not even past. –William Faulkner

The history of software architecture contains rich lessons, yet architects constantly clamor only for the latest and greatest. This talk recounts more than a dozen stories of projects that failed architecturally…and why. Ranging from the Vasa in 1628 to Knight Capital in 2012, each story tells of a mistaken interpretation of some architectural fundamental principle. Attendees learn from the mistakes of the past, to avoid or at least recognize them when they appear tomorrow.




   Follow Neal on Twitter

Neal Ford  |
  • Author, ThoughtWorker, & Meme Wrangler