This is a key issue with Agile, and I don't think anyone has solved it. Initial architectural decisions are critical to success, and as Kent Beck says, you would put them off until you have enough information.
What he can say is, of course, largely because he can choose his clients and demand this degree of freedom. Three months for a project that changes the language of implementation may be fine, but for most of us this is not an option. We must make some decisions quite early, and they must be right. We must work with insufficient information and make the best use of our experience and capabilities.
Most architectural texts have a process starting with English sentences expressing the required functionality and then decomposing nouns and, ultimately, verbs into semantic representations of classifiers, which ultimately turn into real lines of code.
We cannot do this too easily: user stories cannot be decomposed because they are not detailed enough and we have no other sources of functional requirements.
I would suggest avoiding something like UML (for something other than storing your own notes) until you at least write your release plan and you have some idea of which stories are likely to be implemented in Iteration. At this stage, you can begin a detailed work with architecture.
Before that, you have to make some decisions, and the best way to manage them, I think, is to try to determine which part you can:
- what non-functional requirements may be
- what standards you must follow
- what existing systems should you interact with and their APIs,
- what will the deployment platform be
- what skills does the target operating group have,
That kind of thing. Often these restrictions can be short enough in the expected delivery so that you can be sure of the high-level components and where they will be located.
Something that I highly recommend makes Information Architecture work on user interfaces. User interfaces are fragile and expensive to change, and the presentation of the wireframe is close enough to the finished article so that you can discuss with interested parties and get valuable answers.
You need a good information architect, and you need to regularly make changes to IA for user stories to ensure that everyone in them gets a proper rating.
To work with the non-user interface, think about some basic concepts in the solution - often things such as transaction boundaries and transaction security requirements can be clearly defined and indicated, even if you do not know what is specifically contained in each type of transaction. Make a few statements about limitations and success criteria specifically for transactions and data security and get their consent from the parties concerned.
Finally, at the beginning of each iteration, you can perform some detailed modeling and work with the architecture, since there is a real functional decomposition. I highly recommend inserting a preliminary iteration at this time for this work. At the beginning of the actual iteration coding, you should have a clear idea of each class that you intend to create, where it will live and what it will talk to. If you do not have this, it is not possible to agree on a development team.