Evaluating Solution Architect Competence – 10 Indicators

For solution architects to be effective and to succeed there are specific competencies that are crucial. These competencies become even more crucial as architects evolve from technical roles to solution architect, senior solution architect, and principal architect.

Perhaps you are a solution architect who is struggling to get more recognition? Perhaps you want to grow into an architect role or evolve into a more senior or principal architect role? Consider the competencies listed below, and use them as a guide to help assess where you have an opportunity to grow.

Or, are you a leader and you want to evaluate the competency of your architects to understand how you can help them grow? The competencies listed below should help you to evaluate your architecture team to help determine where you as a leader can help them become more effective and competent architects.

Below, I’ve listed the 10 competencies I believe to be most critical for solution architects:

  1. Consistently Ahead of the Game: Architects need to be ahead of the game and always ready to come to the table with solutions and approaches. They are constantly evaluating risks and ready to raise risks as necessary. Architects need to have answers to questions that arise from the team, stakeholders, and sponsors. Being ahead of the game means having done the ground work already to provide reasonable answers and guidance when questions arise.
  2. Technical Knowledge: Understanding that technical knowledge alone doesn’t make a good architect, but having deep technical knowledge and expertise is crucial.
  3. Multiplying Output — Helps technical teams understand and work through tough technical problems while helping everyone else up their game through knowledge sharing, education, and coaching.
  4. Problem Solving – Demonstrate ability to solve tough problems that please sponsors and stakeholders.
  5. Leadership, Communication, Negotiation, and Alignment: Effective written and verbal communication where communication style reflects the audience. They should demonstrate varied levels of detail and communication style when speaking with executives versus speaking with highly technical implementation teams. This should be reflected in both written and verbal communication. Team members, stakeholders, and sponsors should be continually aligned and the architect understands their accountability to ensure everyone is aligned.
  6. Willingness to Have Difficult Conversations with Sponsors and Stakeholders. If architects are not willing to stand up and have tough conversations, then there is a likelihood that projects will go down wrong roads with unnecessary risk because the architect didn’t speak up at critical project junctures. Architects need to come to the table with evidence based solutions for sponsors and stakeholders even if it means it may change the paradigm. This needs to be pro-active, and architects can’t wait to be asked about it. They need to step up and bring it to the table.
  7. Fact Based Decision Maker: Keen ability to quantify and qualify information to be used as inputs to decision making. Willingness to collect and save evidence used for fact based decision making and provide as evidence and reasoning.
  8. Invites Scrutiny and Embraces Conflict: Architects must be open to conflict and able to defend their positions with evidence. Being able to make decisions while inviting scrutiny and defending decisions with evidence when scrutinized is a sign that the individual may be both confident and competent. On the flip side, weakness can be recognized when “confidence” is coupled with sneaking things through, avoiding scrutiny, avoiding conflict, or blocking the questioning of decisions.
  9. Focused on the Right Path Forward: When presented with new or conflicting information that justifies a change in approach, the architect embraces the change. The architect is focused on the best path forward and not on being right all the time.
  10. Business Acumen: Architects need to understand business and importantly “the business” of the domain in which they are operating in. If you are months into a project and the architect still doesn’t “get” the business, then that’s going to be a problem.

Post a Comment

Your email address will not be published. Required fields are marked *