Emergent or Evolutionary Architecture is a term I hear bandied around a fair bit but trying to pin down what exactly it is can be tricky.

Let’s consider a “typical” project (and this is regardless of agile vs waterfall, etc, etc).

There is an architect on the team (or next door or perhaps on a floor somewhere above the team if they are ivory).  That architect’s job is to define the architecture.  They do this by looking at the requirements, blending in the available technologies (or maybe by looking for new ones) and then producing something, a document, a diagram, some UML, to capture the architecture.  They may do this on their own or with the team.

The team then takes this architecture and builds a system that hopefully meets the business requirements.  The architect may or may not be hands on.

There are some problems with the above.  Architects have been known to over engineer their solution.  The business has been known to change their mind about the requirements or which are important.  Sometimes the requirements are ambiguous, sometimes they are just missed.

To my mind its these sorts of problems that Emergent Architecture sets out to address.

So, how do you do it?

• You follow agile practices – specifically “test first”.
• You apply good design practices – you refactor when you realise that the current solution needs to be evolved to ensure it continues to meet principles such as SOLID.
• You make sure you define your non-functional requirements and that you address them in a timely manner.
• You defer decisions until you have to face them because the requirements demand it.

It is quite scary as initially it is against you instincts.  Just remember that those instincts are not infallible they are just a collection of learned behaviours which may or may not be applicable in this context.

You are going to make mistakes and go down some blind alleys as the requirements twist and turn.  The point is that a few small mistakes along the way are better than some big mistakes based on incorrect thinking up front.

You are going to have to make enough decisions up front to allow progress but do not get carried away.  Focus on building the core business logic not on the UI, not on the persistence mechanism.  If you build it right, following those design principles then you can bolt on the likes of persistence when you actually need it.

Finally, if you had to read the Wikipedia page on SOLID then Emergent Architecture probably isn’t for you – yet.  Get a good grounding in the design principles first. If  you don’t then how are those principles going to guide you and ensure you end up with a well architected system rather than a pile of spaghetti.