Your question is a hard one because it touches on many areas: process, leadership, and software design (or architecture). I'm going to assume you have a standard process already, but if you don't then try one of the Agile processes. I'll talk about leadership and software architecture.
Leadership. Fred Brooks' great book, The Mythical Man-Month, talks about having a technical leader the way a surgical team has a leader. Personally, I like more collaboration than I see with doctors, so let's treat Brooks's surgical team as an extreme. Still, you need someone to technically coordinate who is doing what, things like allocating people to work in different parts of the system, deciding what the hardest (riskiest) parts are (so that they don't get deferred until they're expensive to change/fix), and make choices when the team disagrees. This kind of technical leadership is needed whether you are building software, cars, or pogo sticks.
Architecture/Design. The standard mantra is that "Every system has an architecture" but the corollary is that not every architecture is deliberately chosen. You may implicitly copy the architecture from your last project, say a 3-tier system. Or it may be pre-decided once you know you're using a framework like EJB. At the beginning of a project, you'll be making architectural decisions and some will be hard to change later. How will you persist data? Will you use a framework (eg Spring, EJB, RoR)? Will you process data incrementally or in batch?
Pretty much any architecture can be forced to meet your requirements. For example, you could use RoR to build an thermostat. But you'll have an easier time when your architecture is a good fit for the requirements. Sometimes you'll have requirements, such as low user interface latency, that can be helped out by a wise architecture choice, like using AJAX. So the beginning of your project is an opportunity to think about these things and get them right. (And this doesn't mean you go up to the mountain, think hard, then dictate your answers to the team -- here again I favor collaboration).
Don't be afraid to think about architecture up front, especially about ways it can help you avoid difficulties, but also don't try to decide everything in advance. You'll have trouble if one part of your team started using Ruby on Rails while another part started using EJB -- so make some technical decisions, the ones that are forced on you and the ones that will address your biggest risks.
One last thing: Early architecture discussions are a blessing and a curse. They are a blessing in that they get ideas out early and allow you to choose your design rather than blunder into it. But they are a curse in that everyone will have opinions, and it can be difficult to get them all pointed in the same direction (ie back to the need for technical leadership).
I recommend Chapter 12 of Applied Software Architecture for guidance on your question. The list of headings gives a good idea of its advice: Creating a vision, the architect as key technical consultant, the architect makes decisions, the architect coaches, the architect coordinates, the architect implements, the architect advocates. The 97 Things book you mention is more of a collection of pearls of wisdom rather than a cohesive guide to architecture.
George Fairbanks, Author of Just Enough Software Architecture