Agreed! Most emphatically so, in fact. I've been an "architect" since 2001 and the thing that slaps me in the face again and again is that most architects I en

Agreed! Most emphatically so, in fact. I've been an "architect" since 2001 and the thing that slaps me in the face again and again is that most architects I encounter can't code, or haven't bothered to for years. First, the word architect is just a fancy word for design. And yet most architects don't know the difference between a layer and a tier. The best way to get your head around those concepts is to write code using separation of concerns, and deploying it. Yourself. Next, process. Seriously? Process was solved in the 80's. The agile movement brings nothing new here. There's a basic process that starts way before you write code - Envision (your idea) Plan (how) Build (write the code - you can use SCRUM et al here if that's your bag) Stabilise (bug fix - if your dev methodology permits then this merges with build, but an architect/project manager/program manager should still identify milestones for release readiness) Deploy Operate Companies like Thoughtworks (whom I admire for their technical ability) will tell you to screw any process, and that the software will evolve itself. This is bad, because it will result in an app that's never finished. So as an architect remember to begin with the end in mind. There's no point in starting if you don't know how to know that you've finished. If process is new to you, check out version 3.1 of Microsoft's Solution Framework. Both the team and process models are good, but neither are gospel. Stay VERY VERY far away from frameworks like TOGAF. They're a prime example of how to kill a project through process. The Zachman Framework is only good as a documentation guide, but offers little that the Microsoft Solutions Framework doesn't cover. The Unified Process, or whatever that crazy process is called that came out of the UML world is just as bloated and useless. In closing, if you want to be a good architect, learn to code better than anyone else you work with. Be that guy that's done it all and has the war stories to prove a point, like why server push won't work on an ADSL network. And don't call yourself an architect. You design software. That's kind of it.