I've worked with several engineering architecture and software architecture teams. The "old" architecture model is very top-down: architects (who were software

I've worked with several engineering architecture and software architecture teams. The "old" architecture model is very top-down: architects (who were software devs/sysadmins a long time ago and haven't pushed a commit in >6mo) push top-down designs for large-scale systems that engineers (usually outsourced or entry-level) implement. This model works when most of the "doers" are entry-level but comes with a huge "you don't know what you don't know" disadvantage. It is very easy to read RFCs and docs for protocols and languages (repsectively) and surmise how things should work, but it's a whole other ball game when you _actually have to make them work_. The "new" model that I've seen come up is closer to internal consulting than "ivory tower." In the new model, architects (who are very much software and/or systems engineers) are "assigned" to teams to help them achieve a particular mission, like migrating them onto a corporate build and release framework or helping them release their greenfield application into "Production". They will either pair with engineers during these missions or they will take items directly from their backlog (at a lower velocity than the devs on the team, of course) and push commits themselves. I much prefer the "new" model to the "old" model.