Agile Architecting

The Agile Manifesto articulates the following core values:

  • Individuals and interactions over processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

In essence, informal, iterative, adaptive processes that rely on the collaboration of empowered individuals are strongly favored over formal, bureacratic process and its accoutrements (plans, contracts, comprehensive documentation).  If we overlay these values with values for enabling dynamic teaming, value delivery and risk management, we have the value-set that underlies the Visual Architecting Process.

Short iterative cycles, early involvement of stakeholders, and visualization, allow for quick learning, early direction setting and iterative direction correction and refinement. But this learning is done with models as long as they are effective, reducing the cost of change as the architectural design is explored, refined and elaborated. Along the way, the architecture is documented, both to aid the architects in thinking through approaches and alternatives, and as a communication tool to get input and feedback from a broad set of stakeholders.

The process promotes early discovery of opportunity to innovate and differentiate, and builds alignment and motivation through a strong, shared vision and high-level system design that identifies system building blocks that, for large systems, become the units of agile development, allowing further innovation and experiment, with generally lower cost of changelowered by isolating the impact of change.

This process then, allows us to integrate the best of agile software practices along with other practices used to get complex products created in reduced timenamely, allowing more people to be effective, productive and creatively engaged in building the system, because they have clear commitments to and from the system via the system design, and, yes, its documentation.

Embrace agile development and refactoring. Just start with models, work with all of the agile philosophies while the team is using models and document with sketches (visual and verbal) of the overall system and the key architectural mechanisms. Some of our lessons are learned the hard way, through discovery that necessitates refactoring at the code level. Others can be discovered by modeling the system and refactoring at the conceptual architectural element (module, component, service) level. Others are more apparent; we have after-all, some experience building software systems!  Yes, the ground is constantly shifting under our feet–the competitive landscape, and the technological landscape, keep changing, sometimes in revolutionary ways. But at the same time, dominant designs emerge that see us through periods of system evolution.

Naturally, I’ve defended (just enough) architecture documentation various places:

This piece is intended to plead the case for documentation within an agile culture

Also related:

On Agile and Documentation

and while I wouldn’t toss the proverbial baby out with the bathwater:

Colm Smyth has a series of posts titled “Debugging Extreme Programming–Agile not Fragile” that is architect-friendly; see, for example, Refactoring, On-site Customer and Metaphor.

 

 

 

2 Comments »

  1. Arnon Rotem-Gal-Oz said,

    September 9, 2007 @ 2:44 am

    Hi Ruth,
    I also blogged a few post on agile processes and architecture which you may find interesting. such as:

    http://www.rgoarchitects.com/nblog/2007/06/11/AgileArchitectureAndDocumentation.aspx
    http://www.rgoarchitects.com/nblog/2007/05/13/EvolvingArchitectures.aspx

  2. Ruth said,

    September 9, 2007 @ 7:24 am

    Thanks Arnon! I had read, liked and learned from your Agile Architecture and Documentation post, so I’m very happy you caught my oversight!

    I really like that you’re encouraging (agile) architects to document alternatives considered but ruled out and why. This may seem counter to the agile philosophy of minimalist documentation–there is pushback on documenting at all, so it’d be reasonable to ask why we should document approaches we decided against. But it is not counter to _being_ agile. It’s not agile to revisit/rehash decisions, simply because… the collective “we” forgot, someone new came into the room, etc.

    Jeff Tyree and Art Ackerman’s “Architecture Decisions: Demystifying Architecture” http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/mags/so/&toc=comp/mags/so/2005/02/s2toc.xml&DOI=10.1109/MS.2005.27 also calls for documenting alternatives not chosen.

    Anshu Gaind has an architecture decision template that I also like because it explicitly identifies drawbacks of the approach, so that the discussion of downsides to our chosen approach is not swept off the table but rather addressed head on: http://www.bredemeyer.com/pdf_files/WhitePapers/Key%20Decisions%20Template.doc

    We also encourage architects to “connect the dots,” tying decisions to their rationale–business strategy and architecture goals or lessons from our experience. The outcome of our thinking shows up in the code, but not the thought processes, the demands and drivers, the experiences, etc. that we were balancing as we made the architecture decisions. See http://www.bredemeyer.com/HotSpot/20040428EASoapBox.htm

RSS feed for comments on this post · TrackBack URI

Leave a Comment

You must be logged in to post a comment.