Continuous Design of IT Systems
May 2019 • Presentation
This presentation covers how to use continuous design on your projects with a mixture of agile, domain-driven design, functional programming, and architecture ideas.
Software Engineering Institute
I’ve been applying a mixture of agile, domain-driven design, functional programming, and architecture ideas to information technology (IT) systems. Most architectural case studies report on one round of design, but my projects were being designed and redesigned continuously. This talk covers some insights I’ve had and some ways of working that may help you on your projects.
- Agile and architecture differ in their use of control systems (open loop, closed loop) to guide projects. We can mix them, but only when the team agrees to the mixture; e.g., agilists don’t shout YAGNI and architects don’t stop the presses. We should use open loop control for some things and closed loop for others.
- The team won’t have a single architect but neither will it have silos of expertise. Instead, the team creates and evolves a shared understanding of the architecture that is represented in the code base (including types, framework components, comments, and READMEs).
- The team maintains intellectual control of the system. It keeps the state space small and sufficiently well understood to reason about it and derive conclusions. The design is continuously changing, so team members evolve the code to match that understanding and actively communicate relevant changes to the rest of the team.
- Humans are not ideal computing machines and work better with some external representations (i.e., source code) than others. To facilitate human reasoning, teams should mercilessly refactor their code so that it matches their internal theories of the requirements and the design. Without aggressive refactoring, complexity quickly accumulates, preventing axiomatic reasoning and intellectual control. Theory building is refactoring.
- We should expect the code tied to the domain to converge as the team masters the requirements. The architectural infrastructure may never converge. As the team’s theories become clearer, the source code (in the small) will take on a functional, definitional flavor regardless of programming language.