According to the famous software engineer Grady Booch, software architecture “represents the significant design decisions that shape a system, where significant is measured by the cost of change”. Therefore, architecture design is an exercise in planning ahead – any changes made at the architectural level may require rework across the whole system. Architectural decisions include things like the technology stack, the development framework and architectural patterns. If you want to change from .NET to Java after you've started development, or change from a web-based system to a desktop app, then you basically have to throw everything away and start again.
Agile development methods are based on a development philosophy and a set of principles that allow the development team to deal with changing and unknown requirements. To accept change, agile methods discourage detailed up-front design, because requirements are not initially known and up-front design may therefore be wrong. Refactoring is used to ensure quality remains high.
Is this a paradox? How can you design an architecture while using a methodology that promotes not planning ahead? How can you use a methodology that encourages refactoring on something that can't be refactored?
This research is using the experiences of agile practitioners to explore this apparent paradox. Generally, practitioners get around the paradox by compromising -- doing "just enough up-front design". But how much is just enough up-front design? (Note: while this research is labelled "how much architecture?", it's more about up-front design and planning than specifically about architecture, if we can differentiate between them). According to a number of authors, how much? depends on context. Context include technical factors, business factors and people-factors -- the team itself and the decisions it makes.
Because of all the context factors, this research is not aiming to come up with some formula, a recipe, where you plug in a bunch of parameters (such as project size, criticality, stability etc) and come up with an answer that describes your optimal level of up-front design. Instead, this research involves talking to agile practitioners in industry to hear of their experiences and how they deal with of up-front design.
Thus the outcome of this research will be an explanation, a discourse, that explains how agile development teams deal with up-front design. It will be a story that teams can use to put their own situations into context, to reassure them that they are thinking about all the right things when planning -- or to give them a few ideas of things they should be thinking about.
Perhaps.
