I used to refer to the article below, which is unfortunately shrank in the information ocean of the internet. Luckily I saved that to myself to be ready all time, therefore now I can share it to you. Most of the text is saved from http://www-128.ibm.com/developerworks/ibm/library/ar-togaf1/. Please read the following discussion between David Jackson and Andras Szakal, certified ITAC architects and key members of TOGAF.

They, in addition to being certified IT Architects within IBM, have worked extensively as part of The Open Group. David was chairperson of The Open Group Architecture Forum. Andras was chairperson of the IT Architect Certification (ITAC) Working Group, which is responsible for the ITAC standard and represents IBM on the Board of Directors for The Open Group. He put in many years working with The Open Group to develop and gain acceptance of TOGAF.

David and Andras agreed to talk to developerWorks about IT architecture in general and TOGAF in particular.

Understanding the IT architect's place in today's business environment

Before discussing TOGAF, we should clarify a larger issue: the architect's role in software development. Some developers just "dive in and code," but most recognize the need for preplanning. However, many developers don't understand the level at which this architecture work takes place. Often, they are familiar with the idea of planning an application, but planning for the enterprise requires a different - though complementary - set of skills.

David compares the enterprise or IT architect with that of a civil architect, who plans cities or builds buildings. "The role of the IT architect is to be able to understand the business problem and the business domain and explain it to the technical people, and to be able to understand the technology domains and explain the technical possibilities to business people. Or in the civil architecture notion, it's the architect who can explain to the purchaser -- the person who is funding a building or city, 'These are the possibilities of how you can build this building.' The architect eventually comes up with the blueprints to give to the builder and says, 'OK, here's what the owners of this building want. Here's the way they want this building built, here are the features they want in this building.' But what makes a good architect? Given the presence of both in the equation, is it more important to be able to understand the business side of the conversation or the technical side? It's a question often debated by David and Andras, who favors the technical side.

"Andras believes that a good architect needs to start out as a developer and have a good background in development and operations before becoming an architect," David says. "I think it's harder to take someone who has a strong foundation and mental construct of an engineer and get them to have the artistic bent and artistic nature that's necessary to become a good architect." Is it possible for a really good engineer to become a really good architect? "Some people can move out of that engineering mindset and become an architect, but they might have a harder time doing it."

Andras responds. "I do believe that even though engineering specialists - who we're talking about here when we're talking about developers - are not architects, they are still of great and important value. We understand that the architect role and responsibility is focused on taking the business requirements and value and translating that into the proper solution. My personal opinion is that it is valuable to have someone with IT technology background to fill that role, because their role is essentially as the technical lead of the team."

Given that, technical skills are a must, no matter where an IT architect starts out. "A good building architect needs to know the structural strength of steel before they design in it," David agrees.