Scaling Agile Development Via Architecture

Interesting Article from Scott Ambler on Scaling Agile Development Via Architecture
"Every system has an architecture, even systems developed using agile methodologies. Whether you attempt to define that architecture up front in detail or whether it emerges over time is up to you. My experience is that most agile teams follow a strategy somewhere between these two extremes, one that involves investing a bit of time up front to think through the "big issues" but which addresses the details on a just-in-time (JIT) basis. That strategy, combined with proving your architectural ideas as soon as possible through working code, results in a very agile and low-risk approach to system architecture."

Agile Architecture Strategies

  1. Focus on collaboration over documentation. "Agile architects" are … not simply people who document their vision and hand it off to developers.
  2. Prove it with code. Everything looks good on a whiteboard, or in a modeling tool.
  3. Keep it simple. Agile software developers model … in ways which are very different than traditionalists.
  4. Use the simplest tools. … free form diagrams, … simple sketches …
  5. Think through the big issues up front.
  6. Think through the details just in time. … "model storm" focused issues on a JIT basis.
  7. Allow good architectures to emerge over time. … the fact is that the details will emerge as your system evolves to meet the changing needs of your stakeholders.
  8. Travel light. Remember Agile Modeling’s They Ain’t Gonna Read It (TAGRI) advice.
  9. Have a few overview diagrams. Just like a road map overviews the organization of a town, your navigation diagram(s) overviews the organization of your system.
  10. Be flexible. … the nature of the project will help to define the types of views that you should consider creating.
  11. Display models publicly. Distributed teams find that a Wiki with snapshots of diagrams and point-form text works well.  
  12. Take a requirements-driven approach. Your architecture must be based on actual requirements put forth by your stakeholders, otherwise you are "hacking in the large."
  13. Model with others. By working collaboratively you will create a higher quality product, will develop a shared vision, and will learn from one another.

More here…

Direct Link…

Worth Reading…


Leave a Reply

Please log in using one of these methods to post your comment: Logo

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

Google photo

You are commenting using your Google 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