Sunday, November 24, 2019

Emergent Architecture is not a thing

Emergent architecture is a term I heard for the first time from a coworker a while ago. It was touted as a combination of agile and architecture, or perhaps as the way the shiny term "architecture" was inserted into something as face paced as Scrum, or as a way for the company justify not having architects, but to put it plainly, it's not a thing.

There are a few things wrong with it... conceptually. 

I have read a lot about it, looking for any source of information I could, presentations, blogs, some links here and there, and I could not find a solid base for what they claimed it was, or any reason for it to be claimed as a thing, except for the need to name something with "architecture" on it.

Agile is a methodology, Scrum is a method, if you want to know a bit more about the difference just hit Wikipedia. They are related to how to build software.  Now, architecture, is about structure, is about what you build. You can reach that structure with any method, the structure itself is not part of the method, much less the methodology.  Since:
  • Agile is about process
  • Architecture is about structure
Then, conceptually, it makes no sense to name or classify any architecture as a type of process.

Then why the fuss about it?

You can read the term by many people in the sales part of Agile couching, classes, books, certifications and trainers. They use it because is a shiny term, and we all love shiny terms (Agile itself is a shiny term).

It also comes as a need to solve (or give the appearance of solving) one of the big problems in Agile: technical debt.

Technical debt...

Don't get me wrong, I use agile every single day, I am a defender and I really see the potential, but:
Like many methods that focus on delivering "value" to business first, code later. Scrum in particular (to pick one) lacks anything related to architecture, if you are iterating delivering something piece by piece to the customer, for "value", then you most likely are sacrificing a better structure, tool set or design (architecture).

That's why after a few months, you have a big backlog of things you would like to do, but the "business" does not consider it important. Should I move to RabbitMQ now? Should I use MongoDB instead of SQL? Oh... I need a configuration service! Too late now. Too expensive to change.

But thinking ahead is a bit contradictory with Scrum (no Big Up-Front Anything)

The big mistake: assuming change is cheap.

Building the minimum, they say:
"So as we evolve the system, we build only enough architecture and design to support the functional and nonfunctional requirements that we are focusing on for that Sprint [sic]". - PracticeAgile.com [1]

The pillar all these pseudo-not-architecture ideas are based on, is one that reads "Assumes change is cheap" (or a variation of this quote). This is plainly a lie, you cannot assume change is cheap, everything about software have proved us that change is not cheap [2].

The Agile concept that we must not do Big Design Up-Front (a la waterfall) is a good one, but that should not be confused with avoiding a good design from the beginning. You can't change from a monolith to microservices after 50% of the software is up, you can't easily (cheaply) change from a pull-model to event-based architecture after you deployed because you can't scale. These decisions should have been made before.

Architecture should come before code

As part of any solution, you need to know what you are going to build. This does not mean you will do a full waterfall-like planning with tons of pages of documentation and hour estimates and work statements, no, it means you have to plan (blueprint) what is that you are going to build. Then, you can use any method for that.

You must be as frugal as possible without sacrificing quality. Some mock-ups, physical and logical architecture, domains, patterns to be used, basic system interactions, security considerations, performance considerations, tool set, tech ops and dev ops, coding guidelines, etc.

But I don't think that deserves a new name :) 

You just need to do it right, as early as possible, because paraphrasing Meyer, "refactored garbage is still garbage" [3]

Resources:
[1] Practice Agile: https://practiceagile.com/emergent-architecture-handled-agile/
[2] OOSC, Bertrand Meyer
[3] Agile, the good, the Hype and the Ugly, Meyer