Davy Brion has posted some rants about the Microsoft MVP program and the type of people that are attracted to it.
What David has mentioned holds true in some other areas of IT industry too.
"Architect" another cool but severely abused title :) If you take David's post and replace "Microsoft MVP" with the word "Architect" you would find everything still holds true. I am a strong believer that "Architect" as a designation\title should be done away with.

In my 8+ years of IT experience I have seen quite a few of this breed :) With exception of few I found most of them just good with
  • UML modelling tools (such as Visio)
  • Generating high quality project artifacts (Such as Function Specs, Design documents)
  • Buzz word mongers.
  • Smooth talkers
These maybe important qualities to have in an Architect but a sound technical background is a non negotiable. Everyone knows what is the end result if you engage such people. Such Architects mostly produce things that look impressive on paper but implementing them most often then not becomes infeasible.

    Well, its not the Architects fault always. In a typical engagement this is how the Architect works. At the start of the project the Architect
    1. Understands the problem domain.
    2. Talks to the client coming up with a solution approach.
    3. Shares the solution approach with the client and key stakeholders.
    4. Gets their feedback.
    5. and finally creates artifacts for the team to get started.
    What starts of as a full time gig for the Architect, gets reduced to a advisory role as the project progresses. And after some time the Architect is gone, entrusting people like us the responsibility of implementing their grand vision. This is where I believe the problem lies.

    When we are working in an Agile age where requirements evolve, designs evolve, technology evolves, mandating a design at the start of the project is incorrect. The time where Architectural decisions are made, are times of maximum uncertainly as the project is getting off ground. What ends up happening is that Architectural document\guidelines gets sidelined and the solution evolves based on what the immediate requirements are. This is shear waste of resources.

    There is another problem with this approach. Where is the accountability? If I am not going to develop something I am architecting \ designing, I can virtually propose anything. Literally anything !! If things work out fine I can always take the credit else I can always pass the blame to others. Works well for me! I can keep on doing that project after project and keep going up in the organization ladder, with virtual little or no real contribution to any project I work on.

    At the end I am not going to present any solution for this situation but point my readers to an excellent presentation by Simon Brown where Simon discusses the role of the software architect, challenging some of the current assumptions and trying to redefine it in the context of Agile development.