What do you need to know to be an IT Architect?

Update:  This post has moved to here. 

My team has been spending a fair amount of time recently asking this question "What is it that you need to know to be an IT Architect?".  What you should be reading? What skills should you be honing? Who should be following?

Recently, I had the opportunity to sit down with IASA (the International Association of Software Architects) to try and answer this very question.  I spent a week with Paul Preiss (the president), Angela Yochem (a fellow, and VP of Enterprise Architecture at SunTrust), Aaron Tan Dani (who runs the ISAC in Malaysia), and a few people from Redmond.  During this week we created a taxonomy for what we believed were "the essential things you need to know to be an IT Architect".

We started by defining what we believe as the fundamental skills that every Architect needs.  We classified these into five areas, known as IT Environment, Business / Technology Strategy, Design Skills, Quality Attribute Skills, and Human Dynamics:

IT Environment is about the organization of the IT department, Engineering, Operations, Governance, and Project Management.  These represent the fundamental skills required for understanding how the IT organization works and how the IT Architect functions as part of this.

Business / Technology Strategy is understanding how the business maps to technology (and hopefully vice versa).  It covers business fundamentals, business and technology alignment (mapping), valuation (e.g. is an IT project going to return value?), and industry concerns.

Design Skills are an IT Architect's primary tool for creating solutions.  Skills required here include knowledge of patterns and best practices, building blocks, artifacts, tools, and methodologies.

Quality Attributes are the considerations that cross cut every technology solution (or at least they should!).  These include management and monitoring, attribute types (security, reliability, supportability - this list can go on), and implementation.

Finally, the area of Human Dynamics cover skills required such as communications (writing, listening, speaking etc.), situational awareness, and leadership.

What are your thoughts?  Ignoring the specific domains (e.g. solutions architecture, infrastructure architecture etc.), are we missing anything from the set of fundamental skills that every IT Architect needs?  Are these the right areas or would you change them?

Comments

• Anonymous
  September 10, 2006
  heh, NickMalick posted his view at architect requirements today.
  See what does he want to see http://blogs.msdn.com/nickmalik/archive/2006/09/09/EA_Interviews.aspx
• Anonymous
  September 10, 2006
  A good IT architect also requires thought leadership and willing to confront the machine (aka courage)
• Anonymous
  September 10, 2006
  Having read over the headings a few times I'd say you've pretty much got it covered. Areas such as performance and testing would come under Engineering in my opinion.
  
  One thing that occurred to me, are you deliberately limiting artifacts and methodologies to the design phase as being the main deliverable of an Architect? In the general scheme of things I'd see artifacts and methodologies coming into the likes of Project and Programme Management.
• Anonymous
  September 10, 2006
  I agree w Alistair - artifacts and methodologies are project and programe mgmnt responsibilities, but with direction and at least guidance from the "architects" by way of reference artifacts and enterprise-wide methodology standards (and of course exceptions w approp governance)
• Anonymous
  September 10, 2006
  The comment has been removed
• Anonymous
  September 11, 2006
  Good list. I would change a few things:
  1. What appears to be missing is the requrement for an Architect to be well rooted in technology and possess "depth and breadth" of technological knowledge and understanding.
  2. Expand industry concerns to mention "following industry standards" as essential skill of an Architect.
  3. Add "ability to negotiate and compromise" to the list of soft skills.
  
• Anonymous
  September 12, 2006
  I think an architect should have following competency.
  
  1. Technlogy 2. business strategy 3. Organization al politics 4. Consulting 5. Leadership.
  
  Visit this url...it has good explanation about Architect Role: http://www.bredemeyer.com/pdf_files/role.pdf
• Anonymous
  September 20, 2006
  I agree with Alistair on his comments,but i strongly feel that the whole engineering skillset has been left out of the loop,when a solid background in enginnering is neccessary in order to make appropriate decisions like what platform to use,limitations,realistic deadlines,scalability issues,security.
  You can't have a very forward looking plan without understanding the engineering part...and yes i am an engineer!!!!
• Anonymous
  September 22, 2006
  As the business world turns its attention to BPM and workflow engines I think IT architects should have at least basic knwoledge of Value Stream Mapping techniques like the ones in Lean Manufacturing (not to design but to understand them, business design is in the hands of business process architects); specific notations that denote business processes like BPMN; Six Sigma terms and tools (like process yield, Cpk, Design of Experiments) and finally a good understanding of business strategy and goals in order to "squezze" the most out of technology to help management reach out those goals.
  
  The famous IT/Business divide will be diminished at design level so architects, both IT and business, will be key players in the game.
• Anonymous
  September 24, 2006
  Depends a lot on the organisation and existing technology.
  
  To be effective it can come down to knowing what not to say, compexity of presentation...
  
  In a small outfit (common) the architect may primarily do something else, and that won't change.  Has implications...
  
  On the quality front especially, must be aware of the full business impact of quality decisions.  (The board typically has little or no gut feel about software, so the architect must be many miles ahead on the full impact, when arguing a case.  That should not be pseudo-knowledge but a real deep seated understanding.)
• Anonymous
  October 09, 2006
  PingBack from http://asailorskis.com/arch/?p=58