In the Agile world, software architecture is about making design decisions with just enough anticipation. Too much anticipation leads to overly heavy architectural constructs that may never be used (YAGNI); too little anticipation leads to expensive refactoring and potentially fatal build-up of technical debt. This session presents an approach for Agile architecture roadmapping with just enough anticipation.
Agile software architecture
Developing large software systems automatically generate some technical dependency issues. If this is often managed by software architects in traditional projects, how do you communicate this technical dependencies when you are organized using an Agile approach? This is the topic discussed in the paper written by a Swedish research group.
This talk provokes you to think about an old question by R. Gabriel “Is Worse Better?”. It demonstrates “how worse can be better” if the focus is on delivering a business value, which is one of the most important software architecture’s property for agile software development.
The rhythm of Agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn’t require ongoing attention. But it isn’t always prudent to let the software architecture emerge at the speed of the next iteration.
If you put mayonaise in your cake because you don’t have butter, you aren’t being pragmatic, you’re being disgusting. I don’t care how good your experience is with the mayonaise in other recipes. I don’t care about it’s quality. It just doesn’t work in cake. The same goes for putting project managers and software architects in Scrum teams.
Modern Agile software development approaches like Scrum recommend a “just in time” vision of application development that tends to make people focus only on the activities that are directly useful for the current sprint. How can you include an activity with a long-term perspective like enterprise software architecture in the iterative process of Scrum?
Upfront Modeling is fine, documents describing the intended architecture are fine, and so forth. But the architecture, and our learning about it, can improve. Speculative software architecture should be made concrete and not of concrete.