Technical and Strategic Architects: Expert vs Analyst

Earlier we discussed Analyzing Software: Technical, Tactical and Strategic Qualities. As a comment pointed out, finding the right candidates is very challenging. This article explores the differences in skills needed, something that might benefit you in selecting the right candidate for the right role.

Definitions

When comparing people who are an analyst or an expert, many similarities can be found. Both have proper education, and both are for sure not rookies in the field. Thus to help separating the different skills needed for different roles, a more narrow definition of the terms will be used.

• The Expert: a person who has gained Experience through extensive practice
• The Analyst: a person who has Analyzed the work of many different Experts

The Expert

During an interview with a candidate, people start talking about their experience: what have they done. It tends to be that people often repeat their approach, especially if it yielded prior success. Thus almost naturally they tend to specialize in a specific reference architecture. Two examples of a reference architecture are:

• Java backend with Spring, Elasticsearch data store, AWS and separate DevOps team that deploys
• Magento webstore, private hosted

Note 1: a current or target state architecture contains not only software [architecture] but also infrastructure, people, and processes.

Note 2: a specific reference architecture contains common elements found in a group of [instance] architectures. Most of the time it eliminates the domain/company specific elements but could be generalized on other aspects.

Candidates who mainly talk about their experience, will deliver the software solution using the reference architecture they are experienced in. You can expect from such candidates a solution with low effort and risk, while having high Technical Quality.

The correct industry word for Expert would be Technical Architect. The Technical Architect plays a role in the design of components of the software architecture. A Technical Architect fits your team if: (1) the reference architecture that the architect is experienced in, aligns with the broader architecture of the company, and (2) the architect is able to understand that "different usages" of the technology might be needed to improve Tactical Quality. Especially, point 2 is challenging for some Technical Architects; they argue that shorter cleaner code is more effective but severely underestimate the Tactical Quality of a system that is needed for expanding the lifetime of an investment.

The Analyst

You recognize an analyst by their focus on processes, responsibilities and decision consequences. They are capable of drawing a specific software architecture on the board during an interview without leveraging prior experience in the [business] domain or specific technologies. Also, they can discuss many different reference architectures and the trade-offs between them.

The Analyst does not rely on his/her experience, but analyzes how the software solution can be built. What are the alternatives - understands the different dimensions of a plan - and how to select between them. The Analyst operates on Strategic level (see Strategic Quality) and defines the architecture and the components in the architecture.

Any Analyst has to be partly hands-on. Might it be in his/her current role, or in other side projects. That shows that the analyst can:

1. delegate and won't become the bottleneck; software development is teamwork, delegation is key
2. be accountable and responsible for the technical correctness of all software
3. ensure the team has the right technical skills

The industry has many different roles that should be filled by an Analyst: Chief Architect, Enterprise Architect, and Domain Architect. In this article we won't go into the differences of the roles, but depending on the size and structure of the company some or all positions are present and/or might have overlap. A good fit for the Chief Architect is found when: (1) the domain is well understood by the candidate, (2) the candidate can formulate a vision on the future, and (3) the company has clear strategic objectives.

Conclusion

When you are building the right team for your organization, start with the analysts. The Chief and Enterprise/Domain Architects will develop a blueprint (the target state architecture) in which you can hire the right Technical Architects. Too often people are hired based on the current state. This means that it just became harder to realize your business objectives.

Software development is the most valuable aspect of a company - technology companies are now they most valued companies in the world. But software development is also teamplay and needs the right people on the right positions. This article described how to evaluate candidates for the right positions. To end with an analogy to soccer: don't hire Cristiano Ronaldo and use him as goalkeeper and then expect to win the competition!