Software architecture is in crisis, and the way to fix it is a hefty dose of anarchy.

Some lay the blame for this on @boicy with the whole microservices thing.

(Admittedly, @nicolefv, @jezhumble and @realgenekim didn’t help when they statistically proved that he might have been onto something with all that de-coupling and team-alignment…)
However I don’t blame him at all.

I think he saved us; bringing us back to the path of value-delivery and independent services, but now with added independent teams.
But one thing is clear. Microservices need more architecture, not less (as do other forms of #Accelerate-style software organisation).

(See if you need convincing)
I mean, all those pesky slices we need to carve up our monoliths (or were they big balls of mud?) That’s a significant amount of work right there…
The truth is, the vast majority of attempts at - and ensuing aftermaths of - such slicing and continuous delivery have highlighted problems for almost all organisations, even the ones who were doing great architecture: How to scale their architects.
One of the biggest problems? Suddenly architects (and I include myself in this group) needed to be in far too many places at once, doing all that "architecture".
And so to cope, we architects either kept doing our job and became bottlenecks, or admitted defeat / got circumnavigated, or worse still went back to code and created “frameworks” which helped teams stick to the true path.

None of these approaches have worked. And they never will.

And consequently many, many #microservices adoptions failed; with #microservices themselves getting an undeserved bad name in the process.
But microservices aren’t a curse on software delivery - and they ought to be a blessing.

What we need is a workable way to approach them, and in the process realise the associated benefits of both team autonomy and improvements in system architecture.
In the remainder of this thread I’m going to introduce the idea of an #AnarchisticArchitecture.

I’ll describe what it is and you could do it. Hopefully you’ll see how it offers the best (only?) way out of this mess.
Let’s remind ourselves first what “#anarchy” means: It’s the absence of government. The absence of authority.

Straight away that means how we are used to doing architecture, via all-powerful architects taking all the decisions, is going to have to stop.
But decisions still need to get made - that’s what architecture is.

(As @Grady_Booch has said “architecture represents the set of significant design decisions that shape the form and the function of a system, where significant is measured by cost of change.”)
@martinfowler agrees “software architecture is those decisions which are both important and hard to change”.

So the first test is can an #AnarchisticArchitecture deliver on this?

The answer is "Yes".

More from Software

The Great Software Stagnation is real, but we have to understand it to fight it. The CAUSE of the TGSS is not "teh interwebs". The cause is the "direct manipulation" paradigm : the "worst idea in computer science" \1

Progress in CS comes from discovering ever more abstract and expressive languages to tell the computer to do something. But replacing "tell the computer to do something in language" with "do it yourself using these gestures" halts that progress. \2

Stagnation started in the 1970s after the first GUIs were invented. Every genre of software that gives users a "friendly" GUI interface, effectively freezes progress at that level of abstraction / expressivity. Because we can never abandon old direct manipulation metaphors \3

The 1990s were simply the point when most people in the world finally got access to a personal computer with a GUI. So that's where we see most of the ideas frozen. \4

It's no surprise that the improvements @jonathoda cites, that are still taking place are improvements in textual representation : \5

You May Also Like

A common misunderstanding about Agile and “Big Design Up Front”:

There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.

You’re allowed to think about a desired outcome from the beginning.

It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.

It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.

It’s not BDUF if you help every team member know what success looks like.

Agile is about reducing risk.

It’s not Agile if you increase risk by starting your sprints with complete ignorance.

It’s not Agile if you don’t research.

Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.

It would be a mistake to assume this research should only be done by designers and researchers.

Product management and developers also need to be out with the team, conducting the research.

Shared Understanding is the key objective

Big Design Up Front is a thing to avoid.

Defining all the functionality before coding is BDUF.

Drawing every screen and every pixel is BDUF.

Promising functionality (or delivery dates) to customers before development starts is BDUF.

These things shouldn’t happen in Agile.
I like this heuristic, and have a few which are similar in intent to it:

Hiring efficiency:

How long does it take, measured from initial expression of interest through offer of employment signed, for a typical candidate cold inbounding to the company?

What is the *theoretical minimum* for *any* candidate?

How long does it take, as a developer newly hired at the company:

* To get a fully credentialed machine issued to you
* To get a fully functional development environment on that machine which could push code to production immediately
* To solo ship one material quanta of work

How long does it take, from first idea floated to "It's on the Internet", to create a piece of marketing collateral.

(For bonus points: break down by ambitiousness / form factor.)

How many people have to say yes to do something which is clearly worth doing which costs $5,000 / $15,000 / $250,000 and has never been done before.