What makes a good Architect?

What makes a good Architect?

  • Comments 5

So, about a week ago I posted an article about our ArcReady & ArcCouncil events. This got me to thinking, what really does make a good architect?  Every organization is different for sure, but I believe that there are some common skills that an architect must possess.  You have to have a good understanding of technology and how it all fits together.  Not a deep understanding per se, just a broad technical understanding.  For instance, you need to know enough about WCF and how and where it can be implemented successfully, but I would argue that you don't need to know how to code every solution possible.  I'm interested in hearing what you, our readers, think makes a good architect.  What skills does your company look for in it's architects?  Do you even have an architect on your staff?  Do you think you should?  What separates a good architect from a bad architect? 

 Please, feel free to use the comments link below to provide your own input :) I'm curious to hear what everyone has to say!

 

  • I agree and disagree on you. First of all, architects should be able to code. They do not have to code the whole solution, but they should be able to code atleast a proof of concept on their own. As typically, an architect would be dealing with new technologies which the developer would not be familiar with.

    Secondly, with Microsoft shifting focus to Team System, it becomes even important for the architect to familiarize himself with DSL and some other core technologies.

    I would summarize what I think can make a good architect.

    1. Communication is the most important quality. He should be able to articulate things to both business and developers in a way they can understand.

    2. No ivory tower business. Should be able to work with all developers. Ability to concede to good ideas.

    3. Good Understanding of SOA, WCF, DSL, Team System.

    4. Obviously Problem Solving skills.

    5. Some Understanding of Servers and Infrastructure.

    Most of these might suit solutions or applications architect but

  • I only agree with this in part.  An architect cannot know everything and that may be why the underlying statement you make about now having to know the details of the underlying technology and how to implement at the code level.

    However, I believe that it is the architects’ responsibility to know exactly these details and risks.  If not the architect, then who is to know these things?  If they are not known, then they must be explored and understood.  It would not be responsible to pick technologies off a menu and create a dish.  Maybe some of the flavors just will not taste right together.  I think if you did this then you would be no more than an informed person from the business that knew how to buy a car at the local dealer, by your shear ability to read magazines and know that the wheels turn and engine causes acceleration.

    How would you feel if every day you drove to work and crossed over a bridge whose materials where picked by someone who did not know the details and intricate nature of their interactions.

    I intentionally left this vague, because the details were not important.

    My question back would be this.  If you do not know how to implement a long running transaction, they how can you pick the right platforms for integration?  Knowing the exact syntax for this is not relevant, but the fundamental understanding of how it needs to be done is critical in asking the right questions.  In my experience, you get that understanding from actually writing the code at some point in your career.

    Architects mitigate risk and critical failures.  I don’t think this can be done with only a high level understanding.

  • Excellent feedback.  I did not mean to make it sounds like a good architect is someone who has never coded :)  On the contrary, I think a good architect is someone who has a lot of coding experience, understands both business needs and technology, and most importantly how to solve business needs with technology in the best way for the situation at hand.  I agree that just reading about new technologies, or current industry buzz words does not make you a good architect.  You should be someone who does those things, and then goes ahead and creates your own solutions using them to test out theories and see how things do work.  This would require writing code, but as has been pointed out, it doesn't mean you are the one writing the entire solution...merely a proof of concept.

  • One great thing that RouteCode pointed out is that the architect needs some understanding of the servers and infrastructure.

    I agree with this 100% and might go as far to say that architects need to have very detailed knowlege of networking and how routers, switches and geographic location of data or systems effect the overal solutions he/she architects.

    This in my mind is one area that frequently overlooked.

  • I am an Architect myself and I can relate to all of your answers. Most often I come to the rescue where developers find difficult getting into and at times I need some hard-core help in getting solutions done.

    To me there are just different types of Architects and the industry has not really recognized them. Architecgs blur from Enterprise, Solutions, Applications and Infrastructure Architects. Generally, they are expected to solve problems and yet not have a definitive authority on solution or execution. It is a difficult role that takes time and expertise and there is still more left to say.

Page 1 of 1 (5 items)
Leave a Comment
  • Please add 8 and 5 and type the answer here:
  • Post