Thoughts On Architecture - What does it mean to be an architect?

Once again friends, the below is an interesting discussion that happened with one of the groups that I am associated in Linked-In. After my reply for this question, I got private replies from couple of people telling that this reply really motivated them...

When people say something is good, I immediately share that with the community.. So adding my 2 cents...

This was the question:-

Grady Booch: Thoughts On Architecture

"There are some things we are confident we know: every software-intensive system has an architecture (though most of them are accidental); multiple views are necessary to fully grok such an architecture (and what views one chooses is often a matter of taste, culture, history, and domain); while the code is the truth, it is never the whole truth (for a considerable amount of information lives in tribal memory).

There are also a number of things we know we don't know: what is the optimal way to represent an architecture? what is the role of architecture in the software development lifecycle? how should the as-designed architecture and the as-built architecture coevolve? and, what does it mean to be an architect?"

These are the questions Grady Booch will attempt to answer at the IT Architect Regional Conference this October. Before he gives his answers, what are yours?

And my reply was:-

"what does it mean to be an architect?"

To be an architect, first means to be the user of the system:- The end user is the one who is going to be day-in/day-out with the system. He is one who is going to be the happiest person in the world if his problem would be addressed by the system. He is one who wishes / expects that the proposed system would ease his life and give him more time and mental peace to concentrate on other things. So first an architect should wear the shoes of an end-user.

Second, the customer who give you the money :- This is a very challenging shoe to wear! Customer expects to get a Discovery Space Ship by paying for a Mercedez! In real life too, all of expect the same in each and every penny we spend. So this is the shoe that an architect needs to wear next. This shoe would help the architect to identify the tool and technologies that he/she needs to adapt to convince the customer that he has a Discovery for the price of a Mercedez. Thus I meant this to be a challenging shoe.

Third the implementor shoe:- Whatever an architect proposes and convinces his customer as state-of-the-art, would always be executed (developed) by a group who would be far below that what an solution expert is. There are always day-in/day-out issues. So this is the shoe that he/she needs to wear to understand what would be a feasible solution to achieve with the give group and get to a win-win situation.

Here it is win-win-win situation.

When an architect starts wearing these shoes and seriously spend some time before deriving at the final one, that is what it takes to get not the so called state-of-the-art but the "this-is-what-i-want" solution.

So is always the future (your end user), the present (your customer) and the past (your developers) who make things a win-win-win situation for you.

Apart from this I definitely would not like to discuss about code, patterns, design and all. If you look at it, as an architect, tech lead, project manager, you would be able to define and specify things only till the 100th feet, but from the 100th till 0, it is only the style of the individual developer. An architect is also a developer, even when is an architect. So as an architect, the solution what I propose should be making my end user happy, but which that translates as appreciated and applauds to my developers and thus I achieve a W-W-W situation!

It is always a matter of referenceability and always I ask myself "where in the referenceability curve are you?".