Accidental Architecture

Hillside Slum

I’m not sure if it’s ironic or fitting that my very first post on Form Follows Function, “Like it or not, you have an architecture (in fact, you may have several)”, dealt with the concept of accidental architecture. A blog dedicated to software and solution architecture starts off by discussing the fact that architecture exists even in the absence of intentional design? It is, however, a theme that seems to recur.

The latest recurrence was a Twitter exchange with Ruth Malan, in which she stated:

Design is the act and the outcome. We design a system. The system has a design.

This prompted Arnon Rotem-Gal-Oz to observe that architecture need not be intentional and “…even areas you neglect well [sic] have design and then you’d have to deal with its implications”. To this I added “accidental architecture is still architecture – whether it’s good architecture or not is another thing”.

Ruth closed with a reference to a passage by Grady Booch:

Every software-intensive system has an architecture. In some cases that architecture is intentional, while in others it is accidental. Most of the time it is both, born of the consequences of a myriad of design decisions made by its architects and its developers over the lifetime of a system, from its inception through its evolution.

The idea that an architecture can “emerge” out of skillful construction rather than as a result of purposeful design, is trivially true. The “Big Ball of Mud”, an ad hoc arrangement of code that grows organically, remains a popular design pattern (yes, it’s a pattern rather than an anti-pattern – see the Introduction of “Big Ball of Mud” for an explanation of why). What remains in question is how effective is an architecture that largely or even entirely “emerges”.

Even the current architectural style of the day, microservices, can fall prey to the Big Ball of Mud syndrome. A plethora of small service applications developed without a unifying vision of how they will make up a coherent whole can easily turn muddy (if not already born muddy). The tagline of Simon Brown’s “Distributed big balls of mud” sums it up: “If you can’t build a monolith, what makes you think microservices are the answer?”.

Someone building a house using this theory might purchase the finest of building materials and fixtures. They might construct and finish each room with the greatest of care. If, however, the bathroom is built opening into the dining room and kitchen, some might question the design. Software, solution, and even enterprise IT architectures exist as systems of systems. The execution of a system’s components is extremely important, but you cannot ignore the context of the larger ecosystem in which those components will exist.

Too much design up front, architects attempting to make decisions below the level of granularity for which they have sufficient information, is obviously wrong. It’s like attempting to drive while blindfolded using only a GPS. By the same token, jumping in the car and driving without any idea of a destination beyond what’s at the end of your hood is unlikely to be successful either. Finding a workable balance between the two seems to be the optimal solution.

[Shanty Town Image by Otsogey via Wikimedia Commons.]


18 thoughts on “Accidental Architecture

  1. I thought (like many others) that architecture of X (whatever is the subject of discussion) is a high level design of X. Then I learnt that it is NOT. I am not sure if this clarity exists in this blog / discussion. For a long time there was NO agreed definition of “architecture” but fortunately it is well resolved in July 2011 but the misunderstanding persists. Those who are interested may see

    Any discussion without reference to the above standard (one may agree or disagree) would be an exercise in ignorance—utter waste of time.


  2. Very good post that in my opinion highlights a very common misunderstanding – namely that architecture always result from conscious decisions.

    In my opinion the same thing can be said about strategy which is also at the most basic level a series of decisions. Those decisions will be made regardless of whether someone makes them intentionally at a very high level of the organisation or just doesn’t bother – in which case someone at a lower level will at some point be forced to make them anyway.



    • Thanks!

      Excellent point re: strategy – I have a post on the to-do list about the parallels between planning and design. As you say, the decisions will be made, the only question is how.


  3. Very interesting post without falling in the “milky way” of metaphors why some designs simply emerge with no structured approach and others don’t.

    I’m your experience have you came across the human reasons why apparently no purpose, no design systems, actually can be operated and achieve the design functions? Or do you tend to think that is just a matter of luck?




    • Systems whose design has been allowed to “emerge” or in other cases neglected completely, can function. That’s the reason I alluded to above re: Big Ball of Mud being a pattern rather than an anti-pattern – people “use” that practice to build systems.

      What the lack of a coherent design does is increase the cost to build, enhance, maintain, and operate those systems. It can also seriously harm performance, security, scalability, reliability, etc.

      In short, those systems that work in spite of a lack of design aren’t due to luck, but to a great deal effort and expense (far more than should have been the case).


    • Igor,

      Indeed…as I noted above, that’s what makes “Big Ball of Mud” a pattern rather than an anti-pattern (which I’d argue is the correct designation for BDUF). What’s in question, however, is whether the Big Ball is the optimal pattern, which I’d argue is easily answered in the negative. Likewise for BDUF, it’s not the only alternative to aimless emergence. It’s a continuum, not a binary switch.


      • Gene I agree, but let’s compare apples with apples; current EA baseline state might be a) there is no EA across the board at all (but each business unit managed somehow), b)people aware that accidental EA had grown by itself without any managed direction and trying to transfer it to something more useful c) EA practice established but required transformation to cover proverbial gap between existing and future capabilities. I might missed some edge cases bit I believe those 3 usually covers more than 90% of all cases. How you going to proceed from current state of affair to target one is a different story – but here IMHO we have multiple departure points (baseline lanscape) and an ideal single destination (target state).


  4. Pingback: Organizing an Application – Layering, Slicing, or Dicing? | Form Follows Function

  5. Pingback: Quick Fixes That Last a Lifetime | Form Follows Function

  6. Pingback: Microservices – The Too Good to be True Parts | Form Follows Function

  7. Pingback: Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line? | Form Follows Function

  8. Pingback: Who Needs Architects? – Monoliths as Systems of Stuff | Form Follows Function

  9. Pingback: Who Needs Architects? – Are You Committed to Reaching Your Goals? | Form Follows Function

  10. Pingback: Planning and Designing – Intentional, Accidental, Emergent | Form Follows Function

  11. Pingback: Accidental Innovation? | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.