Agile Architecture an oxymoron ?
That agility and architecture contradict each other is quite often assumed by poeple looking at agility from the 10000 Mile view. It happens when you read the agile manifesto with your twitter account therefore not seeing the last note :
while there is value in the items on the right, we value the items on the left more.
When you actually drill down and look at real projects closer you will see that architecture thinking is more relevant than ever :
– complexity of the projects is growing
– need for adaptability but as well predictability in the context of the business global warming.
– need for scale to meet the demand for speed.
In a world of agile teams and teams of agile teams, there is a strong need for alignment to make sure everybody goes in the same direction to reach a common goal.
This obviously cannot be achieved with a traditional big design upfront approach anymore and requires a different way of thinking.
In the following I have tried to define this way of thinking through a Vision, Purpose and Values of an agile architect.
We take a technology “overarching” view to help project teams create emergent designs that meet the stated and implied needs of the customer in the expected quality and return on Investment for the Business.
We guide the technical teams towards good practices (architecture, methods and tools).
We drive and improve architecture knowledge sharing.
- We are active members of development teams, developing software where appropriate and act as architectural consultants to the team
- We involve stakeholders and remember enterprise constraints.
- We can’t predict the future and therefore do not overbuild the architecture ( remember YAGNI )
- We take ownership and resolve decision dead locks when needed because commitment beats committees !
- We make just enough decisions now to enable development to happen and avoid unnecessary delays (build the runway) because now beats later !
- We display architecture model(s) publicly, even when they are a work in progress, to promote feedback from others
- We defer commitment: We trust we can solve tomorrow’s problem tomorrow and consider several alternatives as long as they are viable. We do now only what is needed to progress and get Feedback. It is a balancing act.
- We evolve the architecture incrementally and iteratively, allowing it to emerge over time.
- We model for a purpose.
- We prove architectures through concrete experiments because : Building beats talking and Data beats opinions !
- We take an economic view ( what is the simplest way to solves today’s problem without jeopardizing the future and minimizing cost of delay ) because simplicity beats feature !
- We apply patterns gently
- We travel light by documenting just enough to communicate to the intended audience ( make it CRUFT otherwise TAGRI 😉 )
- We depict Models simply using the simplest tools ( remember the Whiteboard ).
All the stuff you do without noticing