I'm on a mission to find out if software architecture can be lean and agile

So I’ve been toying with the idea of doing software architecture in an “agile” or “lean” way. Sounds like a great way to spend a week in mad ‘dicussions’ with various people about the semantics of architecture and solution design and how little of it you should really do in order to be “lean”.

What could it actually mean though? Digging past the jargon, I’ve found a few principles which I can list here without any evidence of them working what-so-ever. That is because this is the start of the journey. So expect a blog at some stage in the future which describes the outcomes of me trying to smash these principles that I found on the ’net (see end for references) into a government organisation.

Some of the things below are going to be really controversial. Some are going to be obvious. But my theory is that if you don’t aim for something radical and different, then you might as well not bother. Shoot for the stars.

I couldn’t have compiled this list without any sources, so here’s a few sites that have helped me greatly in the process which you should check out:

http://agilemodeling.com/essays/agileArchitecture.htm

http://www.scaledagileframework.com/agile-architecture/

Principles of Agile/Lean Architecture

• Collective ownership: everyone is responsible for architecture and everyone is empowered to modify artifacts
• Architecture Owner facilitates & co-ordinates architecture, resolves conflict, fosters collaboration and innovation
• Don’t have ivory tower architecture, embed architecture in each project team
• Drive the architecture based on requirements and existing infrastructure
• Have multiple solution options and rationale behind selecting the most appropriate
• Travel light - be light on documentation (this sounds difficult to actually achieve in practice)
• Prioritise a working architecture that is understood and adopted by all team members over completely fully absolutely detailed documentation
• Prove the architecture through concrete experiments, prototyping, modelling, spiking and A/B testing
• Prioritise architectural epics with high technical risk (usually associated with performance requirements)
• Communicate and promote the architecture - display it publicly
• Define architectural epics and features that support business features
• Consider the future but don’t overbuild today
• Trade-offs if you overbuild today (if only more people followed this):
  • It’s hard to estimate the actual value you are producing
  • You’re guessing what you think you are building
  • You’re increasing your maintenance burden because things built today will have to be tested and maintained throughout the rest of the project
  • It’s hard to tell how much needs to be tested because you are limited to validation based on imaginary feedback
  • If you are guessing the requirements then you are also guessing the risk
• Model for the future but don’t over-model it
• Increase flexibility by deferring design decisions
• Build the simplest architecture possible that achieves the business goals
• Use simple common language to describe the business domain and the architecture
• Continuous refactoring
• Ensure interfaces clearly express their intent
• Observe age-old design practices that are still relevant today such as loose coupling
• Integrate with automated testing to test the architecture against operational, performance and reliability requirements
• Avoid silos, blinkers and redundant code: define and communicate intentional architecture outside of the immediate project team
• Use Architectural Flow:
  • Funnel: collect all possible ideas and initiatives
  • Review: understand epics and refine
  • Analysis: lightweight business case analysis and go/no-go decision
  • Portfolio Backlog: approved prioritised epics awaiting implementation
  • Implementation: split epics into architectural features and implement

Let’s see how it goes, eh!

Comments (0)