Division of "labor" is counter productive in development, because in immortal words of Jack W. Reeves, "Code is Design." Say anything else (UML) and you're delu

Division of "labor" is counter productive in development, because in immortal words of Jack W. Reeves, "Code is Design." Say anything else (UML) and you're deluding yourself. So non-coding architects are effectively only HALF-designing the system. Read this article and weep, for it was written in 1992 and 20 years later, is still rings true, even though there was no UML at the time: http://www.developerdotstar.com/mag/articles/reeves_design.html http://www.developerdotstar.com/mag/articles/reeves_design.h... The problem with non-coding architects is that they are isolated from learning. They have an incomplete feedback loop, and are isolated from the repercussions of their decisions. This at first makes a non-coding architect useless and then makes him actively wrong. This is especially true in systems as complex as enterprise systems. Because code is design and because building the design is free (in comparison to building a bridge), you need to actually translate your mental design into the real blueprint--the code. If you are isolated from that, then it's like sketching blueprints. You may be consistently wrong on some aspect of it, but you'll never know. If skyscrapers could be built and torn down overnight, I bet you money architects would build the skyscrapers without the same rigor of blueprints, look at the result and say "Nah, move this a foot over!" and build again. The correct equivalent for building construction workers is the compiler.