/egilh

Learning by doing

The Architect and its destiny

Posted on Tuesday, January 09, 2007 9:43 PM

My ex boss, Maurizio Cunico, has written an article on MSDN on the role of the architect (in Italian).

I agree with most of the points in the article but I think there is one aspect missing; teamwork. The article describes a "one man show" scenario where the Software Architect does everything. Being humble, as Maurizio mentions, also means realizing that you have limitations and have to actively seek input from the people you work with to produce the best possible solution for the client.

You sometimes have to be a Jack of all trades if you work on small projects but I don't think it is a good idea on complex projects. I have seen many examples in the past where the "Jack of all trades" architect produced brilliant architectures on paper that had major problems when deployed in the real world (scalability, security, load balancing, ...). Working side by side with the systems architect that has to deploy and mange the software is a must if you develop large/complex on line systems.

I agree that the architect does not necessarily have to code, but the architect should help the members of the team grow, not only take care of the architecture.

What do you think?



Feel free to drop a few cents in the tip jar if this post saved you time and money

Feedback

# re: The Architect and its destiny

1/9/2007 10:14 PM by Michele

I completely agree with you. I believe that having many different point of view of the same thing can help you in choosing the best one that doesn't belongs necessairly to you.
I believe that an architect first of all has to be a wise and humble person that is able to evaluate ideas objectively (in the Pros Vs Cons way) keeeping in mind all the aspects of the project (i mean not only the tech one but time, costs, management and business development/opportunity too).
After all Architect is a normal person with a good knowledge a big experience and that can see a bit far ahead other people do.
My rule of thumb is: Whatever you don't know you can learn, do things learnig as much as you can.


# re: The Architect and its destiny

1/10/2007 9:38 AM by Marco Trova

Maurizio says the right thing about calm down the team (in italian "calmare"), because Architect must solve questions of the developers, continuosly support them.

Learning by doing? It's our work, none know all the answers in this work: architect has the seniority to solve problems fast, but cannot know every technology.

In 2003 I learned a complex framework and the XSLT from Egil, and I was an Architect, too.
In my projects I have learned more from juniors than from seniors.. ;-)


# re: The Architect and its destiny

1/10/2007 4:21 PM by Maurizio Cunico

Non vedo il mio commento. Che fine ha fatto? ho sbagliato ad inserirlo? Misteri dell'informatica.


# re: The Architect and its destiny

1/10/2007 4:31 PM by Egil Hogholt

The automatic anti spam filter may have dropped it. Did you include many links in the comment?

Feel free to send me the comment via the contact form or mail and I will insert the comment manually.


# re: The Architect and its destiny

1/12/2007 9:21 AM by Marco Trova

The article has had some echoes:

http://blogs.ugidotnet.org/dotmark/archive/2007/01/10/65776.aspx
http://blog.dotmark.net/?p=482
http://www.guisa.org/forums/thread/573.aspx


# re: The Architect and its destiny

1/12/2007 3:17 PM by Egil Hogholt

Thanks for the links.

I am happy to see that several GIUSA (Gruppo Utenti Italiani Solution Architecture) members share my view regarding the architect as a "Jack of all trades".


Post Comment
Title
 

Name
 

Url

Protected by Clearscreen.SharpHIPEnter the code you see:
Comment