This paper by Roland Faber of Siemens Healthcare recently appeared in IEEE Software. It talks pointedly about how it is more effective for architecture to be structured as a service that provides value by interacting closely with project developers rather than being structured as a function that produces documentation to be followed by the projects. It even advocates that architects perform some hands on coding in the projects (mirable dictu).
It would be impossible for me to agree more, including the part about hands on coding, my fondness for which is pretty obvious given my blog posts.
The article posits that this close, ongoing interaction is a good way of assuring both that projects understand what the architects are trying to accomplish with the architecture and also that the architects develop an appreciation for the practical issues involved in building working software. There is also a side effect of this kind of interaction that they don't mention: its value in preventing the obsolescence of the person doing the architecture.
The standard scenario in this industry is that a person spends a number of years learning their craft and refining their practice at which point, if they're good, they become an architect or manager and stop coding. The architects' (or manager's) skills stay relevant for a few years (five years seems to be a recurring number), after which they become a pointy headed character in a Dilbert cartoon.
As an industry we should be learning from this anti-pattern.
It seems to me a truism that coding keeps you grounded, and current, and keeps this Dilbertization from happening. Certainly at some point other duties e.g., architecture/management require that you take yourself off of the critical coding path, otherwise the success of the project is put in jeopardy, but new technologies or core utilities that are not on a critical path timeline are all fair game.
I strongly believe in this approach and this is the first article I've seen that reflects my personal practice.