It’s a common conundrum once a team embraces test-driven development (TDD). What becomes of the role of architect? Some suggestions include moving the role of the architect even higher than in a typical waterfall or “over the wall” process.
My take on this is a bit different. One of the toughest things when developing software using TDD is choosing which tests to write next. This drives in a very real way the capabilities and design of the resulting system. At a low level the choice of test is often relatively easy, but at a higher level it can be easy to get lost in the detail.
So here’s my suggestion for the role of the architect in TDD-based development: driving the choice of high-level test cases to implement, and moderating the discussions between developers about how such test cases are split into finer tests and eventually implemented.
The benefits of TDD (evolutionary design, scaffolding, etc.) are still there, as is the input from an individual with collected understanding of which possibilities are implemented and which are not.