Traits of eminent Architects

I have been a practicing architect for over fifteen years. I have organically grown from developer to Complex solution architect with over 25 years of experience. This article is about the traits of a seasoned/eminent architect. I would split this blog into two parts. First, the key is known traits of architects without which even survival would be a problem.

The following infographic explains those primary skill dimensions and the level of breadth the individual must carry in each of the areas:

The above traits are an informative book on architecture or your organization’s architecture Boot Camp would teach you.

The following few paragraphs I want to spend on traits that are outside textbooks I have learned on practical on-ground engagements working with various clients of diverse sizes across the globe.

These qualities would help one stand out as an architect.

1. Solving business problems must be your North star
2. Listen, Listen, and listen
3. Be an ant
4. You are not an artist or draftsman
5. Empathy towards co-architects
6. don’t do by yourself
7. You own the solution
8. Get away from the tooling paradox
9. Practice Visual thinking
10. No solution is perfect

Now let’s get into the details of each of them:

Solving business problem must be your North star

Most of the time, we architects get carried away with technical paralysis in choosing products, components, design pattern selection, etc. Often, we need to realize we are solving a business problem. Implementing a technology does not solve the business problem, it would help to solve but it does not solve by itself. The problem could be user experience, fragmented process, and non-rationalized portfolio. When we build a solution, we need to ensure that the different business problems are considered, and the solution engineering matches the need at optimal cost, time, and futureproofing

Example oof paradoxes are - this is era of cloud-native architecture, so it needs to be container-based or let’s solve the integration problem with an Enterprise service bus.?

Listen, Listen, Listen

I have repeated the word three times deliberately. Because it has a meaning when building solution, we need to listen to the following people

1. Customer & Stakeholders - No one knows the business better than the customer themselves. We might have worked with similar customers, solving the same problem, however it is worth listening to customers understanding their pain points, business strategies, technical inhibitors. When it comes to the right situation, we can be suggestive and come to an agreement with them
2. Employer management - We need to cognizant of the fact that we are performing the program for customer as per agreed legal binding with our employer. So, it’s often required to consult your upline management who own the P&L of the account to ensure that the scope and commitment are in line with needs of customer and were not over engineering or vice versa.
3. Team members - Listening to your team members is the utmost important thing as the delivery is teamwork and the delivery team must be comfortable with the design, timeline, and scope. We must ensure the team has right skills and the design is seamlessly translated in a quality build

Be an ant

There is a reason I am using ant as an analogy here. Ants have the habit of accumulating food for the adverse season (usually winter). Similarly, architects will have idle time which is the right time to perform learning about recent technologies, industry trends, certifications etc. If you are on full-time engagement most of the learning you would perform will be around the technology and the solution you are trying to build. This learning would be good for the current engagement, however keeping up with the trend is required to have a meaning conversation with the CXO's. CXO's are more glued to the latest trends and technologies (though not deep) due to their network with industry bodies, technical symposiums etc. The only way as architects we can keep ourselves updated is using the idle time wisely.

You are not an Artist or Draftsman

Solution architecture is not about drawing fancy, complex diagrams. Briefly the reason for Solution architect making diagrams is to visually represent the thought process of the solution design so that the stake holders and the development team can visualize better. Visual thinking is always a better way to represent things rather than pages of documentation. So, the diagram what we are building should convey the following:

• Problem addressed
• Solution components
• Integration points
• Architecture evolution represented visually

There is no fixed depth and breadth in how a solution can be represented visually. The best dip stick is if the stakeholders and the development team appreciate and understand the solution with minimal walkthrough. If there is struggle in them in understanding, then definitely the architectural diagrams need to be re-worked. Use minimal color themes and keep it simple as the essence as mentioned earlier is to make stakeholder and development team understand the solution

Empathy towards co-architects

I consider this as the most important trait for a senior architect. The architecture would have budding architects, architects from different domain/technologies. Unlike developers’ architects need significant mentoring especially on ground in real customer engagements. Always we need to be empathetic towards co-architects and ensure they are contributing as well as learning as part of the engagement

Don't do by yourself

You would have gained expertise across technical domains (Application, security, Platform etc.) but it does not mean everything has to be done by yourself. Keep the parts of the solution with the SMEs and ensure you ask the right questions and own the overall integrity of the solution. Especially in a large complex solution divide and conquer is the best bet as often one or more of the solution components would change and will have cascading effect on other components so it’s better to handle such situation as a team?

You own the solution

Lot of architects including me used to think building solution document is the only responsibility of the architect. This is a complete misnomer which I also learnt over a period. Architects are the people who understand the solution end to end right from business problem, inception to how the solution can be sustained in sustenance phase. So, the job really does not end in building solution architecture document. Architects must ensure the right estimation is done with right staffing, skills, solution level plan with minimal disruption and optimal usage of resource and cost, identifying the risks and the potential mitigation plans. Few of the above tasks will be done in co-operation with project management professionals, however architects need to own significant ownership in all these areas.

Get away from tooling paradox

Tooling paradox is another pit fall where most of the architects fell into. Architecture tools are a good accelerator to build architecture. However, the incompetency in using the tools must not inhibit the solution thinking of the architects. The prime is conveying the solution architecture if it can be done in PowerPoint, white boarding tools, Visio/Draw.io or sophisticated paid tools does not really matter. Entire team must have access to the tool so that edits can be performed later without your intervention. Also, consistency must be ensured that single tool (even if its PowerPoint) used across the program

Practice Visual thinking

Several research studies have indicated visual thinking and visual doing are the best mechanisms in approaching complex problem solving. Though in general visual thinking needs a bit of creativity which is more for right brained people (Designers etc.). As Architects we must have minimal visual thinking and visual representation capabilities. Think every aspect of the solution in visual using various techniques such as:

• mind maps
• User stories
• Ideation boards
• Solution diagrams
• Kanban boards

Doing things in visual way helps teams to:

• Discuss, brainstorm, collaborate
• Ensuring consistency among team members, stakeholders
• Simplifies complex solutions
• Avenue for new, vibrant ideas

Briefly, it eases communication. My ready reckoner for Visual thinking (https://a.co/d/5Z3wR2Q) and Visual doing (https://a.co/d/0YFlCdK) are books on both topics by Willemien Brand

No solution is perfect

Every solution always has an avenue for improvement (visually represented by the star above with a gap!) if iterated another time by another team or even same time. So, a line must be drawn at some point when the solution reaches a logical point so that we do not get caught on analysis / paralysis paradox. It does not mean the solution can be sub-optimal or fit for purpose. All the best practices need to be ensured are included int he designs, and risks are kept minimal.?