Even if you are using Agile, you would need a high level architecture before you can start implementing the project.
By high level architecture, I mean dividing project into small parts, infrastructure stuff, distributed/web-based/thick client etc...
Are there any books/articles on this topic??
On general architecture, you have for example:
And you have platform-specific books, for example for java:
Wikipedia has a fairly comprehensive list of pointers on software architecture.
I've had this argument with Kent Beck on more than one occasion, and he would say that you're just wrong, that you don't need to make these architectural decisions, or rather that you should choose the Simplest Thing That Could Possibly Work and proceed from there.
The problem I see is that you can be a long way down the tracks before you discover that the STTCPW won't, in fact, work, and leave you with a lot of rework. Now, if you're doing things properly incrementally, or even better with a risk-driven model so you examine the riskiest decisions first, then hopefully you will have spotted these things relatively early, but there's certainly no guarantee.
The other side of that is that a whole lot of Agile projects are in contexts where most of the architecture is pre-determined, eg, Ruby on Rails or J2EE. Those systems reduce the risk considerably, because you have a decided environment.
I don't know of any particular books on the topic, although I'm thinking of writing one; this is still pretty much up for debate in the Agile Community.
Probably my favorite fora for this are Martin Fowler's bliki, and InfoQ, with the caveat that I'm about to start posting to infoQ and so may be prejudiced.
It sounds like you are discussing functional decomposition.
There are both bottom up and top down approaches. I like thinking about a project from both sides. This is especially important since when you start from the bottom, you can think about classes and their methods. When you start from the top, you can think about how the program will flow.
Try:
Large-Scale C++ Software Design (Addison-Wesley Professional Computing Series) by John Lakos (Paperback - Jul 20, 1996)
A good article on the topic is "Who needs an architect?" by Martin Fowler.
My personal take is that you probably need to make much less architectural decisions up front than you might think. If you just do enough to come up with reasonable estimates, you should do well.
You will need to pay close attention to design forces, and get good at refactoring, though. You will want to start practicing it as early as possible. Not having come up with an architecture up front should give you many opportunities. ;)
Will you make wrong decision? Yes. Will it take time to change the architecture. Sure.
But you also saved a lot of time by not trying to dream up an architecture up front. And, because at the beginning of the project you have the least amount of information, the up front architecture wouldn't be really "right", anyway. With some luck, it will "just" be overkill, more likely, there will also be decisions made that you'd better change later, too.
Regarding risk, remember that you should start developing the most important features first. That way, your architecture will in fact be build to support the most important features best, which is exactly the way it should be.
A good book you might enjoy on the topic is Robert Martin's "Agile Software Development - Principles, Patterns, Practices".
This is the key problem with Agile, and I don't think anyone has solved it yet. Initial architectural decisions are critical to success, and as Kent Beck says ideally you would defer them until you have enough information.
That he can say it of course is largely because he can choose his clients, and demand that degree of freedom. Three months into a project changing the implementation language might be ok for him, but for most of us it's not an option. We have to make some decisions quite early, and they have to be right. We must work with insufficient information, and use our experience and nous as effectively as possible.
Most architectural texts have a process that starts with english sentences expressing required functionality, and then decompose the nouns and eventually verbs into semantic representations of classifiers that eventually end up being turned into actual lines of code.
We can't do this in agile too easily - user stories don't lend themselves to decomposition, because they are insufficiently detailed, and we don't have any other source of functional requirements.
I'd suggest avoiding anything like UML (for anything other than keeping your own notes at least) until you have at least written your Release Plan, and you have some idea of which stories are likely to be implemented in which Iteration. At this point you can start detailed architecture work.
Before this you must make some decisions, and the best you can manage I think is to try to pin down what detail you can:
That sort of thing. Often these constraints can sufficiently box in your expected delivery that you can be confident of the high level components and where they will reside.
Something I do strongly recommend is doing Information Architecture work on user interfaces. UIs are fragile and expensive to change, and a wireframe representation is close enough to the finished article to be possible to discuss with stakeholders and get valuable answers.
You need a good information architect though, and you need to regularly mine changes in the IA for user stories, to ensure everything in them gets appropriately estimated.
For the non-UI work, think carefully about some of the core concepts in the solution - often things like transaction boundaries and requirements for transaction safety can be quite clearly identified and stated, even if you don't know what specifically is contained in each type of transaction. Make some statements about constraints and success criteria specifically for transactions and data safety, and get them agreed by stakeholders.
Finally at the beginning of each iteration you can do some detail modelling and architecture work, since here is where real functional decomposition happens. I strongly recommend putting in the time pre-iteration for this work. At the start of actual coding for the iteration you should have a clear idea of every class you are going to create, where it will live and what it will talk to. If you don't have this, it's impossible to coordinate the development team.