[HillRat]

Speaking as a — now former — architect, I’d agree! The best use of my time always turned out to be dealing with scope and feature risk, areas of ambiguity, and governance. Part of this is because very few software projects hinge their success on complex and elegant solutions to thorny conceptual problems, but also because competent developers generally don’t need an architect doing much more than sketching out the broad contours for them to get in and design/build the system; what they really need from the architect is client alignment, well-defined feature scope and dependencies, locked down RACIs, realistic team sizes and schedules, and just enough governance to keep everything on track without overmanagement. A successful architect, in other words, is technically-competent enough to figure out what has to go into the solution (which crosses many disciplinary boundaries) and what the overall project size roughly looks like, but the second they try to create detailed technical plans they’re wasting time and money.

[whoknowswhat11]

Thank goodness to hear from some folks with some sense here :) Feature creep risk is REAL. For some reason the new swapped out system all of a sudden has to support 20 incompatible features!