Neal Ford

Software Architecture Fundamentals

Monday, 9:00 AM PDT

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 the fundamentals to transition from developer to architect, or to help “accidental” architects.

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, 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 1, From Developer to Architect, covers:

• Soft skills
• Continuous Delivery
• Understanding large codebases
• 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 evaluating architectures via Agile ATAM, the impacts of continuous delivery on architecture, comparing architectures, SOA, SOAP, and REST, integration hubs, and enterprise architecture approaches and strategies.

Part 2, Deeper Dive, covers:

• Continuous Delivery for architects
• Applying abstraction
• Comparing architectures
• SOAP vs REST/ WS vs Messaging
• Integration hubs
• Enterprise architecture approaches and strategies
• Comparing service-based architectures

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

Building Microservice Architectures

Tuesday, 8:30 AM PDT

Inspired by success stories from companies such as Amazon and Netflix, many organizations are moving towards microservice architectures at a brisk pace. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.

Microservice architecture is important because it’s the first architecture to fully embrace the Continuous Delivery and DevOps revolutions. In this session, I cover the motivations for building a microservice architecture (including making the distinction between “regular SOA” and microservices), some considerations you must make before starting (such as transactions versus eventual consistency), how to determine service partition boundaries, and ten tips to dowse you towards success. I also discuss the role of polyglot development, enterprise governance, how data and databases fit into this new world, and tooling to help ensure consistency between core services like logging and monitoring. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.

Hypothesis/Data Driven Development using Feature Toggles

Tuesday, 10:30 AM PDT

Hypothesis and data driven development ties together current thinking about requirements, Continuous Delivery, DevOps, modern architecture, and engineering techniques to help rethink building software.

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.

Building Evolutionary Architectures

Tuesday, 1:30 PM PDT

An evolutionary architecture supports incremental, guided change along 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 keynote illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.

Continuous Delivery for Architects Workshop

Tuesday, 3:15 PM PDT

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.

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.

This workshop allows you to apply techniques either against a sample codebase…or bring one of your own. Suggested exercises include using metrics to learn more about the structure of your class, how to determine how to partition a mono-lithic architecture into a service-based ond, and Architectural Katas with Devops added.

Continuous Delivery for Architects Workshop

Tuesday, 5:00 PM PDT

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.

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.

This workshop allows you to apply techniques either against a sample codebase…or bring one of your own. Suggested exercises include using metrics to learn more about the structure of your class, how to determine how to partition a mono-lithic architecture into a service-based ond, and Architectural Katas with Devops added.

Build Your Own Technology Radar Workshop for Architects

Tuesday, 8:30 PM PDT

A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.

ThoughtWorks 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. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.

Comparing Service-based Architectures

Wednesday, 9:00 AM PDT

This session compares Service-oriented, Service-based, and Micro-service architectures, describing the problem each is designed to solve, differences and similarities, variants and hybrids, and engineering practices.

Microservice architectures are quite popular, described as “SOA done correctly”. But what are the real differences between SOA, Microservice, and service-based architectures? 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 the considerations and constraints for each. I also discuss specific engineering practices, orchestration styles, reuse strategies, and migrating from monolithic applications to service-based or microservice architectures. No one architecture can solve every problem, and many projects take on more complexity than necessary by choosing the wrong paradigm.