Architecture and Agile

Often claimed by Architects, sustainable Architecture is first causality of Agile. How truthful is this statement?

Let us examine arguments from both sides.

Agile enthusiastic

• Agile is about working software rather than about some imaginary nonfunctional requirements (read scalability, maintainability, etc.)
•  As one of the famous German military leader had said - No battle plan survives contact with the enemy. In simple words, practicalities mean that the exact letter of the guidelines cannot always be followed so big upfront abstract architecture is waste of resources.

Waterfall enthusiastic

• On the fly architecture (not the code) leads to spaghetti architecture which results in increased maintenance cost.

What is the truth?

I say truth often lies in middle not on either end.   

Often Agile purists quote Lean and JIT and demand architecture on the fly. Is comparison fair? Are we comparing apple to apple?  Lean and JIT have roots in manufacturing.  Let us take JIT for Car Assembly line. JIT is practiced while assembling car not while building assembly line and certainly not when car Assembly line is architected and designed.  And I just remember that there is still not any assembly line for software development even after repeated attempts by various heavy weights.

I see software architecture as multi stage. Even I like to add solutioning as founding stone of software architecture.  If one compares making a painting with software, that argument, I will buy. Each painting is different from other. Before start to paint, painter has a vision, what he wants to paint – A portrait or scenery or something else. Similarly A solutioning guy knows what he wants as end product. Painter first sketch outline and then slowly fill in the space with colors.  

 

Does software architecture follow same pattern? I think so.  In starting, painter has vision and blurred idea of final picture but as construction steps progress, painter keep on adding shades and brightness to achieve final painting.  On similar lines, software architect must have vision of what he is aiming for and as development progresses, with help of evolving business needs and under constraints of past acts (or misdeeds) keep on manipulating architecture.