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.]
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 http://www.iso-architecture.org/ieee-1471/
Any discussion without reference to the above standard (one may agree or disagree) would be an exercise in ignorance—utter waste of time.
LikeLike
Putcha,
Could you point out what you aspect(s) of the concept of architecture in the post differ from the definition in that particular standard?
LikeLike
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.
/U.
LikeLike
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.
LikeLike
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?
Best,
Alberto
LikeLike
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).
LikeLike
My apologies for stating an obvious, but system with “Big Ball of Mud” exists and system with “Big Design Upfront” are not even BORN..
LikeLike
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.
LikeLike
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).
LikeLike
Pingback: Organizing an Application – Layering, Slicing, or Dicing? | Form Follows Function
Pingback: Quick Fixes That Last a Lifetime | Form Follows Function
Pingback: Microservices – The Too Good to be True Parts | Form Follows Function
Pingback: Microservices, SOA, and EITA: Where To Draw the Line? Why to Draw the Line? | Form Follows Function
Pingback: Who Needs Architects? – Monoliths as Systems of Stuff | Form Follows Function
Pingback: Who Needs Architects? – Are You Committed to Reaching Your Goals? | Form Follows Function
Pingback: Planning and Designing – Intentional, Accidental, Emergent | Form Follows Function
Pingback: Accidental Innovation? | Form Follows Function
Just found out that the quote from Ruth Malan was from her Trace: http://www.ruthmalan.com/Journal/2014/2014JournalJanuary.htm#The_Code_is
Lots of additional goodness there.
LikeLike