On SoftwareArchitecture, PeteMcBreen defined Architecture as "the set of decisions that we have to live with for the life of the project or system". In that sense, XP tries not to have an architecture, by as few irreversible commitments as possible. The shape of the software is not architected, it is grown, and can change up until the last refactoring. This doesn't mean XP has no ArchitecturalIntegrity. XP uses metaphors and refactoring to achieve ArchitecturalIntegrity without an architecture. -- FalkBruegmann ---- Well, we do have our SystemMetaphor, which is the basic architecture of the system, and we do keep the system consistent in some way that seems to me to be architectural so that it grows more like a cathedral than a bazaar, to steal another metaphor. There should be an integrity to the shape of the software. I'd say that more of the flexibility is within the metaphor - we haven't really addressed how flexibly one could change the metaphor. -- RonJeffries ''It appears to me that XP doesn't prevent or obviate architecture. I think the initial spike they do, as well as the system metaphor Ron mentions, is about architecture. C3's decision to use the SmalltalkLanguage is necessarily architecture too. So I think the idea that XpNeedsNoArchitecture is not correct.'' -- PeterMerel ''As best I have been able to discern, the mere fact that C3 decided to go with an object-oriented approach and some sort of logical model and desired certain traits from the implementation (e.g., maintainability) means that they picked an architecture and a set of qualities for that architecture. The SpikeSolution means that C3 had a chance to test their architecture before they were deeply committed. Architecture is very important to XP; there just wasn't the chance to waste a large investment in an architecture that was not going to work.'' -- HankRoark I feel there is a difference between committing to a metaphor, which makes things easier for the developers and addresses essential complexity on the one hand, and the necessary decisions targeting accidental complexity on the other hand. Would it be correct to say that XP tries to have as few commitments of the latter kind, while other methods are more focused on getting these decisions right? -- FalkBruegmann ---- ''moved here from ChiefArchitect'' I am very interested in whether XP needs an architect or not. Elsewhere on this page, DonWells talks about how there was no need for an architect in two of the projects he worked on. I suggest that there was no need since the teams clearly consisted of highly-skilled and experienced people - they all naturally did the right thing and had a common understanding of how to approach the problem, architecturally speaking, thus applying appropriate DesignPatterns and suchlike. I wouldn't expect the same success in those projects if the teams consisted of inexperienced developers, even if they executed XP perfectly. They simply wouldn't recognize what their code was telling them or may not have developed a keen sense of smell yet. -- ChanningWalton Given a team of inexperienced programmers, I wouldn't expect a great deal of success regardless of the process used. With XP, though, I would expect them to start recognizing their failures earlier. ---- See also: CanAnArchitectureEmerge, ArchitectsDontCreateArchitectures CategorySpeculativeStatement