3 soft skills aspiring IT architects need to develop

In part 1 of this article series, 3 lessons for software developers pivoting into IT architecture, I discussed how an architect's role is much broader (and less technical) than a developer's role.

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

• 3 lessons for software developers pivoting into IT architecture
• 5 technical skills aspiring IT architects need to learn
• 4 people skills aspiring IT architects need to master

After crossing the first bridge on the path to becoming an IT architect, the second bridge for a developer to cross is understanding and gaining non-technical, functional skills. But why should an architect acquire these skills, which are also called "soft skills"? Why bother at all?

[ Here's one way to develop new skills: Become a Red Hat Certified Architect. ]

A developer role is viewed as mostly technical, and their visibility is generally limited to their manager. In contrast, an IT architect has several non-technical skills and a much higher profile and visibility. This makes it imperative for an architect to gain functional skills, including the three below, on top of their technical skills.

1. Understand the business domain

A developer converts a documented design (and maybe coffee) to code. An architect converts business requirements to designs.

As a developer, when you start writing code, you pretty much know what problem you're solving and what code has to be written. But as an architect, you often have a bunch of problem statements and half-baked, half-written requirements. To make the most sense of what is written, what is not written and implied, and what is written and not meant, you need to be aware of the business domain and have an understanding of rudimentary domain jargon.

A successful architect combines technical knowledge with business knowledge and aims to solve business problems using technology. To solve business problems, you need to understand business. You do not have to know the nuts and bolts of the business domain, but you do need to know the basics of how things work and the relevant domain's jargon. This helps you work with stakeholders and subject matter experts (SMEs) to understand the business requirements. You should ask the right questions and not make assumptions. This will help your architecture and design align better with the requirements.

2. Manage stakeholder expectations

Managing stakeholder expectations is a key function for an architect. As an architect, you work with many more people than you did when you were a developer. The term "stakeholder" refers to the different people involved in a project, including managers, middle and upper management, vendors, clients, system integrators, and so on. They all have a role to play in the project's successful execution.

[ Get 5 tips for succeeding with stakeholders in architecture projects. ]

As a developer, your audience is usually just your immediate manager. However, as an architect, your audience is not just your immediate manager, but multiple stakeholders. The architect role has higher visibility than a developer role, and it's not uncommon for architects to work with multiple stakeholders at any given time.

When you begin a new role or project, the most effective strategy is to have a conversation with your stakeholder(s) to ensure each party's expectations are communicated properly. For example, if you are newly assigned to a project that traditionally reels under heavy technical debt and code-quality issues, senior management may expect you to chart a plan to reduce technical debt and improve code quality significantly and quickly. However, if senior management does not explicitly communicate this expectation to you because they assume you already know it, you might be in trouble a few months down the line. This two-way dialogue also allows you to communicate your realistic plans and expectations to senior management.

3. Understand the SLA and ROI expectations

In the developer world, a service level agreement (SLA) refers to a committed deadline to deliver a piece of code or a feature. An SLA for a development milestone is internal. So a breach of a development SLA is generally acceptable.

In the architect world, an SLA is a deadline committed to a client deliverable. It's usually taken very seriously because meeting it affects business outcomes. Missing these SLAs could even involve financial penalties.

When transitioning from a developer to an architect role, understanding the criticality of an SLA and the implications of an SLA breach goes a long way to transforming you into a better business-aware architect.

[ Learn more about building a resilient IT culture ]

Return on investment (ROI) is another important concept that you, as an aspiring architect, should be aware of. There's no ROI in the developer world. Developers convert design to code and usually don't have to worry about profitability or ROI. However, an architect works closely with business stakeholders and is expected to be aware of profitability and ROI.

Businesses exist to make money, and no project or venture will survive long enough to see the light of day if it does not generate revenue, no matter how technically complex or challenging it is. A successful architect knows what project or venture is profitable and how to make it profitable using technology.

What next?

The next article in the series talks about technical skills that you'll need to master to become a successful architect. Should you focus on one stack or master many stacks? How do you manage and keep technical debt under control? What is the difference between architecture strategy and an architecture pattern? Part 3 in this series provides answers to these questions.

[ Check out Red Hat's Portfolio Architecture Center for a wide variety of reference architectures you can use. ]