Friday, June 1, 2007

Most Important Competencies of the Software Architect

Bookmark and Share

What competencies of a software architect are most important to you?

I asked this question recently at LinkedIn and was encouraged by the responses that consistently exposed the importance of the architect's role in balancing the business and technical domains and demonstrating "soft skills". We know from prior entries that these competencies are often overlooked in an architect but are critical to success.

For quick reference, here's a summary of the responses. Be sure to check out the thread for all the details.


  • Understand stakeholder needs
  • Ensure the stakeholder's understand the capabilities and limitations of the architecture
  • Gain consensus on approach through diplomacy, compromise, and mediation
Business Orientation
  • Understanding the business/domain
  • Be aware of financial implications, including costs vs. benefits
  • Discover opportunities to make trade-offs that maximize value to the customer
Technical Orientation
  • Quickly grasp the ins-and-outs of the technical and functional domains
  • Work with the development teams to make sure the target is met
  • Don't gloss over the details - but don't get buried
  • Assume accountability for product delivery
  • Manage scope
  • Provide technical expertise
  • Think in the abstract - cut through the clutter and quickly arrive at viable solutions.
  • Know when to stay in the abstract and when to go deep
  • Engage the teams and build passion for the vision
  • Demonstrate commitment to continuous improvement - for self and team
  • Be open minded, innovative, and creative
  • Delegate
  • Harvest patterns and relationship out of detail and build meaningful models and abstraction
  • Make good decisions
  • Focus on the right things
There was one additional response that I'd like to call out specifically. We've previously discussed the importance of the Architect as a "doer", and we've asserted that architects are frequently at an advantage if they're able to bang out code (at least in appropriate circumstances). Others have also written about this. One response to my question about important competencies offered a practical perspective on this topic:
...designing without coding looks to me as not speaking the same language with the developers - again a communication barrier.
A good point.

One last thing. Be sure to compare this list to the definition of a Software Architect. You may also like to have a look at the competencies that are required by the Microsoft Certified Architect (MCA) program.

No comments: