Communication Skills

All projects start with a need expressed as requirements, whether these are articulated in a formal document or presented as a chaotic jumble in an email. An architect will be able to:

• Read requirements and immediately grasp at least the gist of what is needed
• Challenge ambiguity and assist in the refinement of requirements
• Determine the feasibility of technology to satisfy requirements
• Specify the solution in terms that are clear to the readers

These functions depend on the skill of the architect to build & maintain good relationships, write documentation and present effectively to an audience.

Relationships

Architects are very much an integral component of the relationship chain from problem to solution. They must be capable of earning the respect of those who rely on them:

• The customer needs to trust the architect with their vision or to solve their problem
• The constructors needs to be confident in the technical choices of the architect & his/her ability to specify a cohesive end-to-end design, especially where design crosses several teams
• The project manager needs to know that the architect is reliable & accurate when making planning estimates

The mix of human natures in the span between ‘the business’ (customers & users) and technology constructors is complex, requiring the architect to know how to interact with each. This demands a high calibre of social skills, similar to those of a project manager.

Persuasiveness & negotiation skills are also valuable assets for an architect. These are best complemented with logical argument supported by well-researched facts & excellent presentation.

It’s natural that everyone wants to appear to be the originator of the solution, especially when the kudos value is high. With everyone fighting for a prize that is generated from within the architecture function, the skill of diplomacy is a strong bonus. Egotistical architects are never popular.

Documentation

All architects must be able to articulate their designs so that both constructors & customers can understand them.
If the customer doesn’t understand what has been designed, then probability determines whether s/he will be disappointed by the result.
If the constructor doesn’t understand the design, they are likely to ‘patch’ what they believe the design to mean, resulting in a potentially chaotic implementation.
The following are key to effective communication of design:

• Consciousness of the different solution perspectives (e.g., user, business manager, administrator; database developer, software developer, network engineer, etc.)
• Meticulousness in ensuring cohesiveness of design across the different perspectives to avoid ambiguities or confusion
• Continuous monitoring of design interpretations (e.g., what does the Customer believe they’re getting; what does the Constructor believe they’re building)

Typically, architectural documentation are liberally scattered with relevant diagrams & illustrations, often in a form standardised by a ‘framework’ or ‘methodology’. This improves the efficiency of specification and reduces the chance for ambiguity to creep in.

Presentation

Architects are frequently called upon to present material to group audiences, performing duties such as leading workshops and presenting design proposals.

The audiences of these can range from senior business management to graduate intern Java coders, so audience consciousness, articulation and clear diction are often in the toolbox of a good architect.

Workshop leadership requires firmness, tact & time-consciousness. During workshops, the architect will be able to rapidly detect non-issues, issues that need to be recorded & tackled later and topics that need to be addressed immediately.

Since architects must evoke confidence in their presented designs & proposals, the quality of preparation, as well as appropriate dress code, are hallmarks of a professional solution architect.