In my understanding, evolutionary architecture boils down to making architecture easy to modify. Now architecture is often defined as the things that you should get right early because they will be hard to change later.

How does this fit together? Is there any difference between evolutionary architecture and simply minimizing the amount of architecture?

  • "architecture is often defined as the things that you should get right early because they will be hard to change later." UNLESS you expect them to change. That makes a huge difference and gives space for future evolution. Apr 18 '18 at 17:21
  • I would agree it is a contradiction in terms, if you define architecture as "everything that is expensive to change later", which is the best definition I have heard to this date. I do not agree with "you should get it right early" though, this definition is the very reason one should postpone architectural decisions as long as possible (in order for them to become as informed as can be). Apr 19 '18 at 18:55

Neal Ford's keynote on Evolutionary Architecture can be found here.


Architecture is the decisions that you wish you could get right early in a project, things that people perceive as hard to change. But what if we built architectures that expect change?

An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions.

He goes on to describe different architectural scenarios, starting with Big Ball of Mud, layered architectures, microkernels and REST, and culminating in microservices, which he says have n dimensions of evolutionary capability (where n is the number of distinct microservices).

According to Ford, evolutionary architectures:

  • Are loosely-coupled and highly cohesive,
  • Are composable; components can be assembled to create new architectures,
  • Can be changed incrementally, without requiring an architectural overhaul.

You can think of Evolutionary Architecture as a meta-architecture, if you like; an architecture of architectures. Guidance that dictates design principles that promote casting things in clay instead of stone.

  • 2
    I would agree that putting the word "evolutionary" in front of the word "architecture" means that it's not "architecture" in the "traditional" sense. Apr 18 '18 at 17:54
  • 7
    I can more easily think of it as giving a new name to the same old things. Every software methodology I can remember has claimed adaptability to change as one of its qualities. If this is unique, it's primarily in providing even less detail than others about how to achieve that. Apr 18 '18 at 19:02
  • 2
    @Euphoric: That doesn't fit with what (for example) Hoare and Dijkstra said when structured programming was new, nor what Booch, Meyer, etc., said when OOP was new, etc. Rather the opposite: most advocated that most of what you'd do was create small pieces that were reusable, so most change was restricted to the architecture. You'd have nice little pieces you could easily reuse in different ways, because the architecture was going to change. Apr 18 '18 at 19:12
  • 1
    @Euphoric: I'd say rather the opposite: structured programming and OOP (for two examples) mostly did deliver on their promises. It's harder to say much about this one--I don't expect a lot of details in a key note, but at least offhand, it looks like more hype and less substance than most predecessors. Apr 18 '18 at 20:07
  • 1
    @Euphoric: to a large extent, yes, they did. Much of what's routine today would be much more likely to fail using older methods. I've been involved in building a couple of systems that I can hardly imagine trying to do with older methods (though yes, I suppose it would have been possible). As far as reading the book goes, yes, I probably will--but haven't yet. Apr 18 '18 at 20:21

Yes, it is a contradiction if you are making everything easy to change indiscriminately. If you have to add code to make something "easier to change" (with "easier" poorly defined, as here), then you have made it harder to change, simply because you added code. On the other hand, if you know exactly what will be changing, which is highly unlikely, the additional code should not be viewed as unnecessary complexity.

Making things "easy to change" is probably the main reason much modern software has become so bloated and difficult to change.

  • Very true, but not really answering my question. Apr 19 '18 at 8:46
  • Hmm the answer to your question is "Yes". Apr 20 '18 at 0:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.