One way to advance your career as an IT architect is by making yourself visible within and outside your organization. Your capabilities and contributions reflect your skills, and your communication and visibility determine how you are perceived within your organization and among your peers in the community.

There are many ways to make yourself visible by sharing your knowledge and creating an impact. I discuss five of those ways below.

Contribute to open-source projects

If you are not already doing so, creating your own or contributing to other open-source projects is a good idea. Open-source contributions provide many opportunities to network with like-minded developers, architects, and technologists.

You can learn a lot from the open-source community while contributing and giving back to the projects that are meaningful to you.

Maintain a social media presence

Social media platforms can help you share, learn, and connect with architects and technologists with similar interests. Posting credible information about IT architecture and related topics on social media sites can also provide good visibility that might give you an edge over the competition in job interviews and help you grow your career. If you do not already have a social media profile, consider creating one and start sharing useful content.

Mentor and coach junior technologists

To give back to the community, you can mentor junior developers into becoming better developers and coach senior developers into becoming architects. Mentoring helps you stay up-to-date with the latest technology trends and prepares you to learn what you need to know. Mentoring and coaching also open avenues to interact with people, understand problems in the field, brainstorm new ideas, and more.

Write books and blogs

An effective way to share your knowledge and ideas (and learn in the process) is to write about them. A practical way to do so is by writing articles or blogs. You can register a domain for your blog, use popular blogging platforms like Hashnode, Medium or Substack.

Writing a book is a great way to share your expertise. Writing a book is not an easy task; it requires a great deal of discipline, research, and editing and usually takes a lot of time. Self-publishing platforms have made publishing books in electronic and print formats far easier. Even when self-publishing a book or blog, consider hiring a professional editor to ensure your writing has a high quality that reflects your expertise.

Create training courses

Creating a course is a very effective way of learning a technology or topic end-to-end and establishing yourself as an authority on the subject. However, it is very time- and labor-intensive.

Online training portals allow you to create your training courses and share them for free or sell them in the portal. Remember that you may need to engage content creators and video editors depending on the type and the scale of content you want to create. It also opens up avenues to set up a secondary stream of income.

Wrap up

This article series covered things you need to know to transition from a developer to a successful IT architect, including the soft skills, technical skills, and people skills that will help advance your career. I hope you found this series of articles useful and actionable.

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

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.

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.

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.

"The more dogmatic you are about applying a design method, the fewer real-life problems you are going to solve." - P.J. 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

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.

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.

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.

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? Why bother at all?

A developer's 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.

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.

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.

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.

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.

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 an Architecture strategy and an architecture pattern? Part 3 in this series provides answers to these questions.

While this often feels like a natural process, it is a big change that requires some reframing and adjustment. In my experience, there are three important concepts you need to focus on when moving from development to architecture.

Change your mindset

The first thing you need to do is to change your mindset: Stop thinking like a developer and start thinking like an architect. That means you must prepare yourself for a paradigm shift in how you look at things and solve problems.

Moving from a software developer to an architect is one of the most challenging transitions in the IT industry. A developer's role is almost always clearly defined, while an architect's role is not as well defined. This can make the transition from a developer to an architect difficult. Architecture is typically characterized by grey areas, uncharted territories, ambiguous situations, misplaced expectations, and confusing periods that can throw unprepared developers off track and demotivate them. This article series aims to address some of these concerns, clear confusion, and help developers become better architects.

Think big

A role of a developer typically involves designing, building, and maintaining software systems by writing code, then unit testing, documenting and maintaining it. In contrast, an architect's role is comparatively broad and typically involves designing the high-level structure of software systems. It also includes detailed designs of the systems' individual components and how they interact with each other.

Some architects do not have a development or engineering background. However, architects with a development background can add more value to the project during the build phase by helping developers design the overall project and class structure and perform code reviews. While a developer's role is always hands-on, an architect's role may not be, depending on the project's needs and the architect's interests.

Resist the urge to start coding

When you come across a problem statement or a use case, your first instinct as a developer is to start writing code. As an architect, you must overcome that urge. Wanting to write code is natural to seasoned developers, and it is quite difficult to get rid of this habit.

The path to becoming a successful architect is to start visualizing the problem through a bird's eye. Think in terms of components and their interactions instead of classes and methods. Visualize systems instead of visualizing code. Think of databases and streams instead of tables and rows. It may take some time to get accustomed to this new way of thinking, sometimes even years. However, this is a very important milestone in the path to becoming a successful architect.

Types of Architects

Once you have made your decision to become an architect, you should learn the different architecture paths before deciding which one(s) to pursue. (See What type of IT architect are you? for some descriptions.) Examples include:

• Solutions Architect

• Technology Architect

• Cloud Architect

• Data/information Architect

• Database Architect

• Data Platform Architect

• Security Architect

• Integration Architect

• Enterprise Architect

• Domain Architect (insurance, banking, aerospace, and so on)

Each of these paths is different with some overlapping aspects. Some roles have another architect role as a prerequisite. For example, you cannot become an enterprise architect without having been a solutions architect for some time. The domain architect role requires you to be a subject matter expert in a particular area. Some of the roles are purely technical. But some are partially technical and partially business.

What next?

In the subsequent articles in the series, I'll discuss almost everything that you need to know or learn to become a successful architect. This includes understanding the business domain, stakeholder expectations, people skills, negotiation, visibility, career growth, social media presence, knowledge sharing, and more. My next article shares 3 soft skills aspiring IT architects need to develop. Stay tuned!

Change your mindset

Think big

Resist the urge to start coding

Type of Architects

Part 2: The Functional Skills

Why functional skills?

Understand Business Domain

Manage stakeholder expectations

Understand SLAs and ROIs

Part 3: The Technical Skills

Acquire technical breadth

Decide if you want to be hands-on

Learn architecture strategies, methods, frameworks, and patterns

Consider the advantages and pitfalls of technical debt

Understand architecture tradeoffs

Part 4: The People Skills

Communicate your architecture effectively

Customize your Architecture views for your audience

Listen and collaborate

Learn negotiating skills

Part 5: The Social Skills

Contribute to open-source projects

Maintain a social media presence

Mentor and coach junior technologists

Write books and blogs

Create training courses