An overview of how disciplined agile teams address architecture and design. This includes initial agile architecture modeling, proving the architecture early in the project, test-driven development, architecture spikes, architecture handbooks, and many more.
Architecture and design are so important to disciplined agile teams that we consider these issues every day. Your approach to architecture is a key enabler of agility at scale.
Challenges for an Architecture OwnerTraditional architects who don’t make the transition to agileArchitecture owners also codeSmart techie without technical leadership skillsThe architecture owner should not also be the product ownerNeglecting enterprise assets in favor of building your ownDictating architecture vs. “self-organizing design”Architecture gold-plating
Identify how much modeling you need to doGet the right people involvedChoose the right level of formalityOne initial strategy or several?Formal vs. informal modeling sessionsSingle vs. multiple candidate architectures
No single view sufficesTOGAFZachmanDODAF
Source: http://www.agilemodeling.com/essays/amdd.htmFirst, let’s start with how to read the diagram. Each box represents a development activity. The envisioning includes two main sub-activities, initial requirements envisioning and initial architecture envisioning. These are done during iteration 0, iteration being another term for cycle or sprint. “Iteration 0” is a common term for the periodbefore you start into development iterations, which are iterations one and beyond (for that release). The other activities – iteration modeling, model storming, reviews, and implementation – potentially occur during any iteration, including Inception. The time indicated in each box represents the length of an average session: perhaps you’ll model for a few minutes then code for several hours.