Answered! Is an architecture-centric viewpoint more consistent with the waterfall model or Boehm's spiral model of software…

Waterfall, Boehm’s Spiral Model, Unified Process, eXtreme Programming, and Scrum are processes that can all include architectural work, but differ in how big the release cycles are for building user-functional software, and in how much change to requirements and software they can accommdate in the middle of a release cycle.

Waterfall release cycles are generally biggest, taking several months before users see any functional software (in my experience at a Waterfall company, the release cycles were 6 months with 3 month fix-up afterward, I’ve heard accounts from a manager at Motrolla confirming the same thing there).

Boehm’s Spiral Model introduces rigorous risk analysis and evolution into the software construction process, but does not assert the timing of showing finished features to stakeholders.

Unified Process asserts evolution/iterations and a lot of architecture and documentation as lego pieces to plug in and out depending on the team and project.

eXtreme Programming (same with Scrum) is very light-weight and focused on quick evolutionary/iterative development generally in the order of weeks or couple-of-weeks, showing completely working pieces of software at the end of each iteration.

In properly executed eXtreme Programming or Scrum weekly iterative development, architecture is still paramount. In my experiences of both XP and Scrum, the team had a software architect / senior developer who oversaw the team output every week and ensured all the pieces fit into his grand architectural vision. One thing that eXtreme Programming emphasizes vs Waterfall in architecture though is not to have any fixed documentation or architecture, yet let it evolve/emerge and alternatively document in a WIKI or some changing online documentation (like Google Docs) that changes constantly. In my practical experience, it does go out of sync with developed software, but that is not the point. Architecture serves as general guidance on how to build software in a way that accomplishes architectural goals, such as scalability, maintainability, extensibility, security, usability, etc…

In the end, architecture must always be there to serve creation of higher-quality more usable software and not the other way around, no matter what process or form of documentation is involved.