Architecture and architects - what about it?

Arno Nel posted a couple of statements about architecture a couple of weeks ago:

Architecture is 50% business, 50% Tech.

The Architect doesn't decide wether or not to use DataGrids.

The Architect doesn't care about coding standards

The Architect doesn't care about reading UML

The Architect doesn't care about Agile/RUP/MSF etc

The Architect translates IT to Business

"Microsoft believes that traveling the “arc of possibility” is the foundation of everything done by creative developers, IT professionals, and business people with a mission. Architecture transcends the individual and creates a community of ideas with a shared language of design. Architecture crosses the boundaries of systems to unite the components of business."

What do YOU think Architecture is, cause I certainly don't know.

I definitely think he has a point here - nobody seems to be able to clearly define what an architect really does... You could say that an architect has to translate business needs into a solution or that he has to look ahead and fill in the bigger picture for a customer but this does create a lot of overlap with we call functional analysts or business consultants. The only thing which seems to distinguish an architect from a business consultant or functional analyst seems to be his thorough understanding of technological building blocks. Robert Bogue responed with some interesting comments - What is Architecture?:

However, my thoughts on your statements are ...
1) On Architecture is 50% business, 50% tech -- I'd say that architecture is one part art (elegance, simplicity), one part facilitated visioning (getting a common idea of what is going on), and one part conversion (converting requirements into design). While it's true that business and technology are both required, I'd say that the important aspects are not well respected with this point of view. Knowing how to facilitate people coming together, knowing how to convert requirements into design, and knowing how to maintain simplicity in the face of complexity are a much more important perspective.
2) On The Architected doesn't decide w[h]ether or not to use DataGrids I don't know that I can agree to this statement in every case. It depends upon what the solution is and what is necessary. She may decide that DataGrids are critical to some reusability that is desired and could specify them. However, in most cases, you're right. In most cases shouldn't be any reason why an architect would specify the use of DataGrids or not. Think of it this way, a traditional building architect doesn't generally specify the supplier for a bolt only how strong it must be.
3) On The architect doesn[']t care about coding standards I heartily disagree here. He doesn't care WHAT is in the coding standards but he does that they exist. In the same way that a building architect doesn't care what kind of light fixtures are used in the building but does care that they all match (consistency) or coordinate (complimentary).
4) On The architect doesn[']t care about reading UML Here to I heartily disagree. I don't disagree that the architect won't read all the UML, however, I believe the architect should do "drive bys" of what is being constructed. That includes reviews of the UML and any other supporting documentation being used to construct the actual solution. If the point is that they don't care whether it's UML or something else I disagree again. The architect's time is overcommitted. If the architect understands UML then UML should be used to facilitate communication (reduce the cost) and to make communications more effective.
5) On The architect doesn[']t care about Agile/RUP/MSF etc. Again, I disagree. The architect needs to understand the process being used to know how to insert themselves into the process in a way that is both timely and respectful of the process. Choosing an approach that they are familiar with is important. Also, they may decide that to achieve the objectives one may work better than another. For instance, an agile approach will work better with poorly understood requirements. RUP will work better with risky components to the project, etc.
6) On The Architect translates IT to Business While I agree that the statement is true I believe it misses the fundamental truth that an architect guides a conversion process from raw data into a solution. Also, I'd argue that the statement even in it's form here should be reversed. They help to translate the business problems into IT solutions (not IT into business.)

In a recent discussion, I heard the statement - "An architect is technology agnostic" - he does not care if the solution will be build with Microsoft or Java - he has to have experience with multiple patforms. Mmm, seems like a rather challenging requirement - I only know of a handfull of people who actually have worked with both Java and Microsoft. I also guess it is not really realistic to keep an indepth understanding of both technologies. I don't know about what you think but I'm having a hard time keeping up with all the new stuff Microsoft releases. Maybe Michael Platt posts about architecture type definitions provides some extra insight - he's talking about 3 different types of architects: enterprise architects, solutions architects and infrastructure architects. Simon Says has a similar posting about Architect personas. The last one is definitly worthwhile to read especially for the interesting comments - here's my favorite one :

This could run and run, but its a sign of the growing maturity of the IT profession that there's a discussion at all [about architecture].

So yes, architecture is not something to dismiss as a fad or as yet another buzzword - I think that Craig Andera in The definition of architecture - clarifies things a lot - "What should a software architect do?" It now seems fairly obvious to me that the answer is "Design software". and As is having an intimate knowledge of the technologies involved - good software architects should be reasonably good coders the same way good physical architects should know the properties of drywall and steel! . So maybe architects don't care about datagrids but they should at least know when to use a datagrid and when a repeater.

So suppose you want to hire an architect - what type of questions shoud you ask him - I found these questions from Java Interview attended by Banta Singh - as well as the answers quite amusing. But maybe, these are the kind of answers somebody gets when he starts to get a little deeper in a interview with a so called "architect". Microsoft recently published an interview to promote their new architects certification - Roundtable Q&A: What Makes a Good IT Architect? Three IT experts who helped craft the new Microsoft Certified Architect credential explain how the IT pro’s skill set has evolved from pure technologist into strategic business manager. - also worth a look as well as these comments about the new Architect certification.