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.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Software architecture details: What are the technical risks involved?