Conference Presentation Abstracts and Slides
I’m an avid speaker at business and software development conferences. Most conferences require talk abstracts to describe the content and thrust of the talk, and it’s often easier to point the organizers to a comprehensive list than send abstracts piecemeal. This therefore is the list of presentations I submit to conferences for my current topics.
Keynotes differ from “regular” sessions in three important ways. First, they are shorter in duration (50-60 minutes). Second, I design keynotes to entertain a more diverse audience. Regular sessions tend to deep dive into one topic area, whereas keynotes may cover a wider variety of topics, exposing surprising connections between seemingly disparate subjects. Third, they are more abstract than regular sessions, encouraging Deep Thoughts in addition to pure 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
I designed the presentations listed below for a particular duration. Presentations are not fractal: I cannot arbitrarily shortened or lengthened them. I may be able to produce a different duration version, but please ask before assuming.
Supporting Constant Change [coming in 2018]
The only constant in IT is change: Business practices change, tools and frameworks evolve, and wholly new tools and techniques appear on a regular basis. How can developers develop and architects architect in an environment like this? This keynote highlights techniques to support constant change, including evolutionary architecture, immutable infrastructure, coding techniques, and better ways to gather requirements. I also cover flexible governance models, evolutionary data, and adaptability. This keynote covers the breadth of modern software development, packed with advice on how to build systems that embrace rather than avoid change.
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. EJB and SOA were once Best Practices, now shunned as anti-patterns. Why? 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.
Software Architecture Fundamentals Workshop [1 Day] [2 Day]
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. This workshop provides a foundation to build upon to start the journey towards software architect. I offer three different versions of this workshop based on length.
One-day Software Architecture Fundamentals Workshop
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:
* Soft skills
* Understanding requirements
* Architecture patterns
* Architecture anti-patterns
* Integration architecture overview
* Introduction to enterprise architecture
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:
* Translating requirements into architecture
* Architecting for change
* Advanced architectural patterns
* Architecture refactoring techniques
* Establishing architectural boundaries
Part 3 (hands-on): Architectural Katas [Katas »]
To fully leverage _knowledge_, you need _application_. Part three of this workshop my own [Katas](http://nealford.com/katas/list.html), based on the public domain [Architectural Katas](https://archkatas.herokuapp.com/) 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.
Building Evolutionary Architectures Hands-on [slides]
An evolutionary architecture supports incremental, guided change 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.
* Evolutionary Architecture Defined
* Fitness Functions
* Exercise: Fitness Function Katas
* Engineering Incremental change
* Architectural Characteristics
* Exercise: determine appropriate characteristics
* Identifying Architectural Patterns
* Exercise: components and patterns
* Evaluating the Evolvability of Existing Architecture Styles
* Retrofitting Existing Architectures
* Building Evolvable Architectures
* Automating Governance
# 90-minute Sessions
Build Your Own Technology Radar [slides]
**Thought**Works Technical Advisory Board creates a "technology radar" twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, 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. This session describes the radar visualization and how to conduct a radar building session for yourself. I cover how to conduct the exercise, along with the visual and social benefits. I also provide some nice tips and tricks derived from doing this with multiple clients.
Comparing Service Based Architectures [slides]
Microservice architectures are popular, described as "SOA done correctly". But what are the real differences between ESB-flavored 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 help 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 architectural pattern. This talk equips attendees with the knowledge and context to choose the architecture that best fits their needs.
Building Evolutionary Architectures [slides]
An evolutionary architecture supports incremental, guided change 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.
Building Evolutionary Architectures: Fitness Function Katas [information]
According to the _Building Evolutionary Architectures_ book, an architectural fitness function _provides an objective integrity assessment of some architectural characteristic(s)_. This hands-on workshop provides examples of fitness functions and group exercises to identify, define, and implement a variety of fitness functions: atomic, holistic, continuous, triggered, temporal, and others.
Hypothesis/Data Driven Development using Feature Toggles [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 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. This talk also demonstrates how to undertake major architectural restructuring with zero regression failures by relying on data and the scientific method.
Stories Every Developer 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
Most developers pursue the Latest and Greatest with intense fervor, yet the history of engineering, including software projects, contains rich lessons that we risk repeating ad nauseam. This session recounts a variety of stories of projects that failed...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 and the consequences--some good, some less so. I also look at the common threads for these stories, which resonates with problems many companies have but don't realize.
* Pets. Com
* San Francisco project
* The Vasa
* Sagrada Familia
* Tacoma Narrows Bridge
* Knight Capital
* Ariane 5
* Chandler project
Where Do Ideas Come From? Creating, Cultivating, and Communicating IP [slides]
Where do ideas for new talks, books, videos, software...ultimately, everything...come from? A common question at conference panels to the speakers is "Where do you get your ideas for talks?" This session answers that question, along with how some of us cultivate new ideas. This talk investigates three aspects of ideation:
--- **How do new ideas arise?**
I cover various ways of synthesizing new ideas: switching axiom(s), mutation, oblique strategies, and a host of other techniques to generate a germ of a new idea
--- **How do ideas grow into intellectual property?**
I cover techniques for iterating on ideas to discover deeper meanings and connections. I also cover how techniques to evolve and grow ideas.
--- **How do you communicate new IP?**
I cover various ways to convey IP: presentations, articles, books, videos, and a host of other media. I talk about how writing and presenting techniques to amplify your new idea and get it out into the world.
One key to building new IP is separating ideation, organization, and realization, which often become jumbled. By separating them, we can build practices to allow each to flourish. This talk provide concrete advice in each area to help realize new ideas.
Creativity is the reason we have all the Cool Stuff we have. This session investigates how to fan the spark of an idea into a roaring flame of intellectual erudition.