In the book, you posed some interesting questions. I hope this won't be regarded as cheating but here are my questions that
spin off from the main question: What are the technical risks involved?
What is a risk? Are all risks equal?
Who identifies the technical risks in your team?
Who looks after the technical risks in your team? If it’s the (typically non-technical) project manager or ScrumMaster, is this a good idea?
What happens if you ignore technical risks?
How can you pro-actively deal with technical risks?
As I've said in some of the other threads, I basically take a risk-driven approach to architecture in order to stack the odds of a successful delivery in my favour. Too much risk-mitigation quickly leads back to big design up front and analysis paralysis though.
Quick! Before anybody notices! Cover it up with this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop