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 method
  • 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 


Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt...
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t...
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not ...
Read more