If you've read Part 1 and Part 2 of this series, you know the basics and the soft skills you need to acquire to become a successful architect.

This article, the third in the series, discusses the technical skills you need to learn to continue your journey to becoming a successful architect.

Acquire technical breadth

As a developer, you usually acquire expertise in a particular technology stack, such as Java, MEAN, MERN, or .NET. If you are a database developer, you may have expertise in specific SQL databases and NoSQL database engines.

However, when you transition to an architect role, sticking to one technology stack or platform will do more harm than good in the long run. You need to be aware of many technology stacks and platforms and gain expertise in at least a few. The more technical skills you possess, the better your architecture and design decisions will be.

Decide if you want to be hands-on

As a developer, you have no other option than to be hands-on. You have to write code yourself, unit test it and debug it as part of your role. However, as an architect, you can choose whether to be hands-on. If you like writing code, then you can continue writing code as part of your job role, and there is nothing wrong with it. It depends on your preference.

On the positive side, being hands-on lets you stay current with the latest technology changes and trends. It also helps you evaluate and validate developers' work and their delivery estimates. It can also help you perform code reviews and check code quality and security issues.

On the other side, being hands-on can mean spending a significant portion of your day writing and debugging code. This may create conflicts with your stakeholders, as their expectations about what you are supposed to deliver may not be met or be delayed.

A balanced approach, where you roll up your sleeves and get into coding only for critical tasks usually solves this problem. Examples include solving code structure issues, defining core frameworks, and fixing security vulnerabilities.

Learn architecture Strategies, Methods, Frameworks and Patterns

In your role as an architect, you often hear a lot of buzzwords like strategy, methodology, frameworks, and patterns.

Architecture Strategies

These are defined at the business level and deal with translating business strategy into measurable objectives for implementing business and IT capabilities along with a roadmap. The main components of architecture strategy are business architecture, data architecture, application architecture, and technology/infrastructure architecture.

Architecture Methods

Architecture Methods refer to the structured collection of industry-standard, tried-and-tested techniques used to build or enhance processes to achieve business goals.

Architecture Frameworks

Architecture Frameworks enable organizations to evaluate, design, and build the right architecture. Examples include TOGAF, DoDAF, and Zachman Framework.

Architecture Patterns

Architecture Patterns refer to utilizing tried and tested patterns to solve common design problems. They are analogous to design patterns that apply to architecture and design. For example, using an MVC pattern for user interfaces, a CQRS pattern for database operations, or an event-bus pattern for communication and integration.

Consider the advantages and pitfalls of technical debt

Much like code, IT architecture design is also prone to technical debt. Technical debt includes the cost of additional work required later as a consequence of choosing easy solutions instead of better approaches. The primary objective of creating technical debt is to prioritize delivery over proper design principles.

In general, technical debt is bad and should be avoided. However, an experienced architect knows when to use technical debt to speed up delivery, reduce the time to market, and achieve better results. A part of an architect's role is to draw a roadmap for technical debts and then document, track, and address them promptly.

Understand Architecture Trade-Offs

Overly architected systems may exhibit unintended consequences like performance impacts and suboptimal user experience due to network latency and other factors. Synonymous with how database developers compromise on normalization rules and introduce data redundancy to improve query performance, architects sometimes need to compromise on architecture and design principles to specific objectives related to things like:

• Time to market

• System performance

• Customer experience

This is part and parcel of an architect's role, and a seasoned architect is expected to know when to and when not to use architecture tradeoffs.

What next?

No matter how technically strong and domain-aware you are, you cannot succeed as an architect if you do not possess strong people skills. The next article in the series discusses people skills, negotiation skills, and learning the art of communicating your architecture and design effectively to different audiences.