So you're bascially doing solution architecture. There aren't any methodologies that I am aware of - at least none that are succinctly described in four pages or less (something I'm interested in coming up with).
To answer your question:
1 - Understand the constraints
The obvious is understanding the problem you're trying to solve and the context.
You may have a free-hand or you might be constrainted by existing standards - where I work (in a Govt agencey) we have lots of different technologies and systems, and there's a pecking order when we're looking at something else; technology we prefer and technology we're trying to grow out of.
Zachman is an Enterprise Architecture Framework; you might find it interesting but I doubt it will have a lot of relevance at the solution level, specifically. TOGAF is another one.
2 - Views
The thing about TOGAF (and Zachman) is that it has the concept of different "views", for example the:
- security view
- data view
- technology view
- application view
- process view
- support view
- operational view
- billing view
- user view
- performance, etc...
Right up front you want to be thinking carefully about which views are relevant to the system you're planning / architecting. As the project / system develops you need to keep these in mind; they will help guide major decisions. I also like this appoarch / way of thinking because it works along the lines of "divide an conquer" - break a large puzzel into smaller ones.
3 - Modelling
I haven't heard of using styrofoam balls before, but the idea of modelling relationships in a tactile way sounds very appealing - although if it's a big system you might need a really big room :)
Whiteboard are my favorite way of exploring how classes relate (and anything, really). I strongly advise having a digital camera with you, or a phone with a camera built in; I use the latter, I take photos of the whiteboard as needed and then sync them with my computer after the meeting and email out copies to the attendees. It's very easy to capture the information and makes you look quite professional as well.
UML is very useful, but you may need to pick and choose which bits of it you use depending on your audience - it depends how formally you want to look at things.
Formally modeling systems in a modelling tool (and using formal UML, as opposed to just diagramming, in say Visio) is alse very useful. If you're not familiar with doing this you'll find there is a pain threshold you have to go through but it's generally worth it when:
- the system is above a certain size / complexity, or
- you have many smaller systems to work with.
4 - Project methodology
I'm a big fan of agile / SCRUM. I'm looking at ways of appliying agile principles to sln architecture - but I don't have anything yet.
I attended a good session at Tech-Ed last year (ARC202 Challenging the role of the architect with Kevin Francis) - I have a write up here.
This was an excellent session - it's
the first time I've ever seen anyone
explain how an (solution?) architect
should engage in a project -
regardless of the methodology. Kevins
an Agile advocate - and his talk
focused on that, which made it twice
as good: how to fit Architecture and
Agile.