Skip to content

Change is inevitable

Concept · Chapter 16

  • Change is one of the few certainties for software systems. It happens both during initial development and throughout the maintenance life of a system.
  • Older thinking treated software as relatively static: a big up-front design tried to predict and plan for every future contingency before code was written.
  • Real-world systems are not static. Software modeled after the real world must change as the world it models changes. Software does not physically wear out, but it does undergo change over time.

Change is driven by two broad categories:

Technical reasons

  • New programming languages, frameworks, persistence technologies, and tools.
  • New operating systems or OS versions to support.
  • Hardware changes that affect the software.
  • New deployment strategies (e.g. moving an application to the cloud).
  • Modern stacks combine many technologies in one project, making the technology stack more complex and creating more surfaces for change.

Business reasons

  • Changing functional requirements and requests for new features.
  • Requests to improve quality attribute scenarios.
  • Competitive pressure and shifts in the market.
  • Regulatory changes.
  • Mergers, acquisitions, and changes to business/revenue models.
  • Rising user expectations that shift over the system’s lifetime.
  • Most systems will be affected by some of these forces over their lifetime, even though the specific technical or business change cannot be predicted in advance.
  • Architects should expect change and design systems capable of withstanding and adapting to it.
  • Designing an evolutionary architecture is the way to handle inevitable change.
  • Architecture consists of the earliest and hardest-to-change design decisions (see What is software architecture?), which is exactly why designing for change matters.
  • Software Architect’s Handbook (Packt, 2018), Ch.16 “Change is inevitable”, pp. 1127-1129.