ARCast - Becoming an Architect

The Discussion

• 

  Good talk in general.
  Yet, I say that architects should code, in fact they should be able to show any professional programmer how to craft production-grade code.
  When I say that, many people still believe that programming is a mundane (repetitive and tactical) task not related to design. I understand that an architect should not do mundane tasks.
  But modern, state-of-the-art programming is not mundane any more and architects must absolutely master that kind of programming, becuase is the sine-qua-non of software design and also it delivers the most business value.
  
  This is a better perspective:
  http://stal.blogspot.com/2006/03/software-architects-role.html
  

• 

  I agree that an architect has to have technical "chops".  I liked your blog post except I wonder how many people would meet your qualification list.

• 

  Hello Marco,
  I actually think that we agree on quite a lot.
  
  In my travels I've seen different types of architects who bring differents skillsets to the table. There will continue to be some who are "closer to the metal", and others, like myself, who fly at the 30,000 ft level (er ... my boss corrected me ... apparently I should be flying at 50,000 feet ). The architects on my team are more "hands on" than I am, and yes, I expect them to be able to demonstrate best practices in software engineering.  Furthermore, I whole-heartedly agree that programming is not mundane, nor are developers interchangeable commodities.
  
  imho, Architecture is about far more than programming and software design. Which altitude you fly at determines, to a large degree, what your scope of concern might be.
  
  btw, very good blog post
  
  Cheers,
  Rob Daigneau
  IUnknown@DesignPatternsFor.Net
  
  

• 

  The needed qualifications for a software architect to manage the complexity of typical development projects are quite high, as I have been seeing with each and every project. The need is just there and it is not about a qualification list for a single person being able to cover all.
  
  

  For all those qualifications, the ability to take good strategic design decisions is one of the most important. Sadly, that notion that the architect should fly in the clouds, in fact prevents him to complete her work (see [1]). A common outcome is that the so-called strategic decisions were quite wrong but by the time the project realize that, too much time and resources are already wasted.
  
  

  [1] An embryonic profession: Incomplete and unconscious design work
  http://blogs.msdn.com/marcod/archive/2006/05/04/AbstractionRole.aspx

  
  see also:
  http://www.jrothman.com/weblog/2006/04/architects-must-write-code.html
  http://www.jrothman.com/weblog/2006/05/testing-design.html
  

• 

  Hmmmm,
  
  >re: The needed qualifications for a software architect to manage the complexity of typical development projects are quite high

  The assumption being made in this statement is that all architects manage development projects.
  
  >re: that notion that the architect should fly in the clouds, in fact prevents him to complete her work
  
  I don't think we ever said that an architect should fly in the clouds or live in an ivory tower; there is some nuance to what both Ron and I are suggesting.
  
  First, once again, we probably have similar thoughts on the general set of competencies for an architect. I hope you don't mind if I post a couple of links ...
  
  What Does it Mean to be a Software Architect? - Part II
  http://www.designpatternsfor.net/default.aspx?pid=19

  ... and ...
  
  What Does it Mean to be a Software Architect? - Part I
  http://www.designpatternsfor.net/default.aspx?pid=5
  
  
  Now, to the point that we were trying to make ... it is my belief that there are actually many "species of architects". I write about that here ...
  
  The Many Species of Architects
  http://www.designpatternsfor.net/default.aspx?pid=53
  
  To provide an analogy. Did you ever see the movie "Apollo 13" with Tom Hanks? If you did, remember that in Mission Control, each row was populated by specialists in given areas. One row dealt with such things as the spacecraft trajectory, another was concerned with electrical and environmental systems, and a third row looked at flight activities. Overseeing all of this work was "the boss".  As you might recall, when problems arose, the boss delegated problem solving activities to different teams.
  
  This is not unlike what higher flying architects do. They are still grounded enough to talk to the specialists (e.g. we have security architects, mid-tier architects, and so forth on our team) without returning blank stares, and they are able to steer the ship by leveraging their experts. In other words, they've got the big picture, they point their experts in general directions, and use that info to decide upon their course.
  
  In any event, I think that one of the issues here is that our profession is grasping at one concrete definition for Architect.
  
  Regards,
  Rob Daigneau