4 people skills aspiring IT architects need to master

No matter how technically strong and domain-aware you are, it will be difficult to succeed as an architect if you do not possess good people skills. This skill is undoubtedly the single most important factor for your success in your new role.

This article, the fourth in this series on becoming a successful IT architect, describes different ways of developing people and communication skills.

Read other articles in this series on transitioning from a developer to an IT architect:

• 3 lessons for software developers pivoting into IT architecture
• 3 soft skills aspiring IT architects need to develop
• 5 technical skills aspiring IT architects need to learn

1. Communicate your architecture effectively

As a developer, when you are done writing code, you validate it by running unit tests and regression tests. You generally do not explain your code to anyone except reviewers, if there are any. Your code is the end product and therefore does not need any further communication down the line.

However, as an architect, your architecture and design are consumed by other teams. For example, your architecture forms the basis for project managers to chart out timelines, developer leads to start their coding activities, and test leads to improve their test cases. This makes it imperative to effectively communicate your architecture to all stakeholders. Effective communication is all about letting your stakeholders know the whats, whys, and hows of your architecture. For example:

• What are the components of your architecture?
• Why did you choose event-driven architecture (EDA) over traditional REST-based synchronous messaging?
• How is caching achieved in the data layer?

One of the most commonly used methods to communicate architectures is using architecture description languages (ADLs), such as ArchiMate and the C4 model.

[ Ebook: 10 resources to make you a better communicator ]

2. Customize your architecture views for your audience

As an architect, you will find yourself working with different people with varying levels of technical and domain knowledge, such as developers, other architects from participating applications and services, project managers, and scrum masters.

Architects and developers may understand your technical design, but project managers may find it difficult to comprehend. Project managers may understand domain jargon and metrics, but developers usually have a hard time wrapping their heads around domain jargon.

Therefore, the most effective way to convey your architecture and get buy-in from all the stakeholders is to create multiple views of your architecture for different audiences. Each of these views contains images and terminologies that are suited for its intended audience.

For example:

• Executive View may depict high-level business systems aligned with enterprise goals and strategies.
• Project Manager View may contain only the high-level logical components without getting deeper into technology.
• Developer View may contain the low-level design and technology stack.
• Infrastructure View may contain physical components and integration patterns.
• Network View may depict network pathways, protocols, and CIDR ranges.

[ Create an organizational culture that fosters innovation. Download The IT executive's guide to building open teams. ]

3. Listen and collaborate

When you design a system, you discover one of the many ways to solve a problem. Your solution may or may not be the perfect one; it may not even be the right one. During the architecture-design review, you will usually figure out there are other ways to solve the same problem—and some might be better than yours. The only way great software architectures can be built is through collaboration.

"As P.J. Plauger says, 'The more dogmatic you are about applying a design method, the fewer real-life problems you are going to solve.' (Plauger 1993)

"Treat design as a wicked, sloppy, heuristic process. Don't settle for the first design that occurs to you. Collaborate. Strive for simplicity. Prototype when you need to. Iterate, iterate, and iterate again. You'll be happy with your designs."
—Steven McConnell, Code Complete

4. Learn negotiating skills

When you are working on a midsize or large project that involves several teams, your architecture and design usually affect other teams' timelines and deliverables. In such situations, you may witness pushback against your architecture and design. One of the most commonly used solutions to this conundrum is to negotiate the design with the stakeholders.

Examples of negotiation include:

• Changing the technology stack to align with those of other participating applications or services within the system.
• Removing or deferring technology stacks or components that do not work well within the system.
• Replacing vendor products with open source solutions and vice versa (to save costs or reuse existing licenses, for example).
• Changing how components within the system communicate with each other. For example, EDA vs. REST-based communication.
• Making changes in build-vs-buy decisions. For example, buying a commercial-off-the-shelf (COTS) product instead of building the component in house.

Negotiation helps you move forward with your design while keeping your stakeholders happy and satisfied.

[ Related reading:  5 tips for succeeding with stakeholders in architecture projects ]

What's next?

The next (and final) article in the series talks about how you can augment your career as an architect by contributing to open source projects, utilizing social media to improve your visibility, learning by teaching, writing blogs and books, and creating online courses.

[ Here's another way to boost your career: Become a Red Hat Certified Architect. ]