I feel tempted to make another thesis:
“To architect a solution you have to have experience from the the business-area you are architecting for”.

To be honest I do not believe in either, because of the same problems as mentioned above.

In my opinion, the most important caracteristics for an architect is to:
- Be a quick learner
- Have no prejudices for or against technologies, but be able to learn about and select the right one for the right solution.
- Have an open mind, being a good listener when the businnes explains ther needs.

And after reading some of the comments, I tend to disagree with most of them.

Ofcourse it might be very helpful if the architect has first hand experience himself. But when I compare the Digital Architect with the Architect in the real world, I tend to think that it might be enough if the architect is capable of understanding and applying the principles leading to a good architecture. He (or she) should be supported (if necessary) by a number of engineers who are skilled on several different aspects of the scope of the architecture at hand. Like the engineers in the real world, working on aspects of interior climate or electrical engineering.

In a perfect world, an architect may be able to get away with just an academic knowledge of an implementation. But we all know that we don’t live in a perfect world, so what the implementation experience gives you is the first hand knowledge/experience to be able to adjust to the new and different challenges the project will throw at you. Only way to quickly do that is to ask someone who’s done it before, hopefully that person is you.

A good architect needs some implementation experience and at least a high level understanding of the technologies being proposed in a solution to be able to ask the right questions and/or answer questions from clients.

One point that I think has been left out and one that I believe is important to consider is that the architect not only needs to consider the people and skills required to implement a solution but also the people/skills required to support the solution. All too often I have seen good solutions fail or do not live up to their potential because the support teams do not fully understand the technology or do not have the right skills.

The architect needs to consider the support side as well as the implementation to insure that the architecture solution can be supported effectively once the implementation project is complete.

If the customers starts asking questions about any of these areas, and the architect can’t answer at least the most fundamental questions correctly, it tends to shake the customer’s confidence in the proposed solution.

The architect also needs to be able to come up with work breakdown structures, level of effort estimates, and other estimates, based on the tools being used. If these levels of effort are not informed by at least some level of experience, the estimates could be way off. If they are way too high, it’s likely that the customer will opt for a competitor’s offer. If they are way too low, it’s possible that the delivery team will balk at the schedule and try to push back, which could trigger concern on the part of the customer who may fear that the $2 million project will soon become a $5 million project, with the PM trying to make it up in change requests.

Often, when things don’t go as planned, and the defects start piling up, it’s important that the architect knows what’s “normal” for this type of project and these tools, and be able to give a reliable estimate of how many defects are likely to be found, and how long it will take to fix them.

The architect also needs to be able to adjust the architecture as plans change, requirements change, or as client constraints change. For example, the client might initially want to keep costs down, using inexpensive hardware, but may quickly need to upscale the project to much larger and more scalable servers. If the architect has painted the customer into a corner, such as using Microsoft Windows servers, it limits the ability to transition to AIX on P-Series or Linux on Z-Series.

Very often, the customer knows his business, but he knows he is dependent on the Architect for the successful translation of those requirements to the technology. It helps if the Architect doesn’t have a blank stare when standards specific to that business, such as Edifact, HL7, HIPPA, or SWIFT are mentioned.

Ideally, the client would like to see the Architect creating the code in his mind, so that all he has to do is document it enough to get it implemented by a team as quickly as possible.

I’m Out!

I agree.

It is important to have demonstrated good implementation experience in the past - in line with EA principles and practices (in business or IT) to sufficient scale and complexity to be effective in genuine EA (architecture of the Enterprise, not only of IT).

However - the main part of the EA is one of leadership , advice and guidance so it wouldn’t be the best use of his/her time to spend on implementation matters.

Its a ticky balance - I think it isn’t a bad idea for any EA to keep an active interest in implementation matters (at a reasonably high level) to keep up with with trends and what’s practical for that particular Enterprise.