August 14, 2017

Al Shalloway | Recording | Slides (PDF)

Conway’s law suggests that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” The reverse of this is also true – once a design is in place, it will be a drag on attempts to change the communication structures of the organization. The question is how do we break this chicken and egg situation and enable change to designs that already exist. The answer is to think about architecture in a new way – one that can be inspired from the true nature of design patterns.

In the Agile space our architectures are not intended to encompass all possible changes – that would be a gross over-design. Instead, they are intended to evolve and accommodate change as new requirements are discovered. When viewed from the Agile perspective we can see that design patterns and architecture are related in that both are about accommodating change over time.

This talk presents design patterns as a way of thinking about the problems to be solved. Design patterns are intended to enable us to encapsulate variation in a system (be it an algorithm, an object structure, the order of execution, …). In the Agile world, this variation often occurs over time as we learn new information about what we are required to do. This enables us to design code that can evolve. Patterns should be viewed as a thought process that enables emergent design as well as emergent architectures.

The talk concludes with an analysis method that facilitates the discovery of these abstractions. This reveals the full solution – design to accommodate change by discovering and attending to the abstractions in your problem. The thought process of patterns is used to illustrate how this can be done at all levels.

Learning Outcomes:

• Understand that patterns are not mere “solutions to recurring problems in a contetxt” but are the basis for a new type of thinking in design
• Understand the forces in the problem you are trying to solve
• Reduce the complexity of these forces by making a distinction between the issue and potential implementations
• Create a simplified model of the issues to be managed in the application – in particular those issues that tend to vary
• Learn how to identify the concepts in your problem domain and how to create proper abstractions for them
• Understand that Agile architecture at scale is about managing change, not trying to define a framework that will accommodate it.