Agile software architecture
Many successful digital products have evolved haphazardly over the years, accumulating messy architecture and code that require extensive rewrite efforts to sustain reliability and innovation velocity in the long term. We outline pragmatic steps for refactoring platforms.
Modern software development inspired by Agile approaches welcomes changing requirements, even late in the process, but how can we write our software so that those changes don’t create a mess? Evolutionary design is the key.
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.
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.
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.
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.
Scrum Expert Copyright © 2009-2024 Martinig & Associates