I don't think it has anything to do with waterfall versus agile. I work in an agile process as a software architect, and "Here's the spec, implement it" is exactly what I get pressured to do by product owners, scrum masters, and yes, sometimes even by developers, who naturally feel insulted by the idea of having an architect "over" them and have no desire to collaborate on design.

The biggest problem with the idea of software architecture is that it's turned into a job title. It stunts both architects and developers by attempting to divide the labor of programming. We are all programmers, and programming is really just design, from the lowest level of designing lines of code up to the highest level of designing distributed systems. Software architects who don't write code get stale very quickly. The longer-tenured architects at the company I work for are sad sacks. I've been on calls where they "reviewed" and approved "designs" that were actually questionnaires filled in by my product owner and fact-checked by me. The documents they read, while accurate, did not allow them to understand the work on any level at all. Their job was to check for things such as, what browsers will this be tested against? You get on a conference call with them, they ask some bizarre questions based on misconceptions they got from inaccurately reading between the very widely spaced lines, they don't understand the answers, and then they rubber-stamp the paperwork. That's apparently a significant part of their job.

Meanwhile, the developers are encouraged to remain code monkeys because that division of labor makes sense to management. To the developers, this seems like disrespect, and it is, though it isn't as insulting as they think, because management doesn't realize that they're basically saying that developers sucks at half their job.

I don't think "architect" should be a title. Everyone should have the same basic title. Call it "developer" or whatever. Just make it clear that we're all doing the same kind of work. Gradations are okay: junior, senior, longbeard, whatever. There are a million differentiations between different programmers in practice. Senior developers should help junior developers when they need it. Developers should consult with other developers on any difficult or momentous decisions. Some people should be focused on the big picture, but not everyone at the same time. At any moment, some developers will be working on prototypes and new projects, and other developers will be working on maintenance. People will develop expertise and ownership. The point is that every difference is personal. One developer may write stellar systems-level code but have unfortunate taste when it comes to designing distributed systems that work together over a network. One developer may be slow at finishing new projects but good at ferreting out bugs.

That's why you need have technical managers with power who make situation-specific judgments about who does what. And that's what this is all about: replacing personal judgment with rules and formulas. Who should design and implement System X, Doug or Sam? Doug, Sam, and their boss know their capabilities. Doug would like to design and implement System X, but their boss knows that is a stretch for Doug and is too risky for the given time frame. Sam knows she can design and implement System X, and so does her boss. So Sam should design and implement the system. Horrible! Unacceptable! Unscientific! Everyone should be assigned tasks based on their job title. Since Sam seems more capable than Doug in this situation, let's give her the title "Software Architect." She will design System X. Since Doug seems less capable in this situation, let's give him the title "Developer." He will implement System X.

What happens next release when there's a system that Doug really ought to design, to stretch his design skills or because it's in an area he knows well? Well, you can promote him, and then he'll be theoretically "assignable" to design any project. If you don't want to promote him, then Sam will do the design and he'll be stuck implementing it. Sam, of course, will be kept busy with design work and "supporting" Doug, so she won't code much, and pretty soon she'll be useless and will spend her time in meetings "representing" engineering, telling sales what's possible and what isn't and hoping that her answers aren't invalidated by things that have changed behind her back. Doug, of course, is busy changing things behind her back, because he only gets to make design-impacting decisions if he doesn't admit that they are design-impacting.

Wow, this is really a subject that gets me worked up. So much for my productivity this morning. I'm an architect, and God help me, I do not want to have this title at the next company I go to.