Becoming an IT architect is a nice step in your IT career. Perhaps you started as a junior developer, progressed as a lead developer, and finally an architect for various large IT systems. Whatever your path is, it is one with a lot of complexities and (organizational) challenges. Great architects oversee the entire IT landscape, have a lookout for new technology trends, and are experts in many fields of modern IT. So in case you want to push your career to the next step, here are some practical things to know when working as an architect.
Different types
Before you start scrolling expert-level articles and Udemy courses that are dedicated to being an architect, it’s important to find out which type of architect you want to become. The list of different architects (roles) is pretty long. Domain architects deal with a specific (business) domain whereas Solution Architects focus on one or more (technical) solutions for given problems. Besides these, there are infrastructure architects who deal with technical infrastructure. Furthermore, Business Architects keep in mind the business aspects rather than a technical point of view. Last but not least, Enterprise Architects focus on the entire organization as a whole. Often they also lead the group of other Architects.
In many organizations, roles vary a bit and there is overlap sometimes between individual roles. For example, if you would like to become a Cloud Architect, it’s important to understand the application(s) of a specific domain as well as have the right infrastructure-related knowledge. To support the DevSecOps teams properly, you also need to understand a lot of things about Cloud security to design the best solution for them. Often, you need to convince stakeholders and upper management about specific solutions so any business-related knowledge and skills come into play.
Helicopter view
Especially in large organizations, a lot of projects are executed in parallel. Architects need to have a great level of overview of these projects. They need to be able to pinpoint those projects in the organization as well as position them relative to each other. And that from multiple perspectives: the business aspects as well as the technical ones. Architects need to have a so-called helicopter view of the organization to embed their deliverables into it.
Understand the organization
Architects working on cutting-edge projects still need to understand the other aspects of the organization to make sure the people have a smooth path transition from their current state towards the future state of their project. It’s not enough to design solutions that only live in isolation. It always needs to link to the existing organization, especially when the solution deviates from the current “status quo”.
Needed context
Besides this example, architects often act as experts for advice on a certain topic. You can only provide good advice if you understand the context of the topic you’re talking about when positioning it relative to the organization. This makes sure, the advice has the right context and managers can make informed decisions about it. For example: help with the priority of applications to migrate to the cloud. It’s tempting to start with the smallest, easiest workload, but there might be other factors to take into account: security issues, life cycle, etc. Great architects take into account various organizational aspects that are broader than the specific topic.
Understand the business
Despite all technological advancements, it’s still a must-have to understand the business. Since Architecture drills down from the strategic perspective to tactical levels in the organization all the way down to applications and infrastructure, it’s vital to understand what is going on at the business levels.
Business architecture
This is especially true when designing representational business architectures that describe the internal business aspects of the organization. It’s vital to position all aspects correctly and to align solutions with the “as is” and “to be” situations. Working like that helps decision-makers to commit to changes in the organization.
Business processes
On a lower level, business processes need to be described to “tell the story” of the business. When doing so, it becomes a bit easier to design practical solutions that demand changes in applications or infrastructure. In case you’re working with internal stakeholders and external partners, this also helps to get them aligned. Boundaries between different organizational units as well as the internal and external views are presented very clearly so this makes responsibilities clear and less diffuse.
Way of working
Seen from the Agile and DevOps perspective, this also has an impact on the way of working of architects. Forget about the days when architects are located in an “ivory tower” that rises high above the people “below them” to execute the work that is derived from their heads and hands. Often, DevOps and other experts push ideas and new technologies “upstream” so architects are forced to react. They can’t ignore it and also have to change their way of working a bit.
Some companies already adopted the Agile way of working for architects. Lengthy documents such as a “High-Level Design” or a “Product Start Architecture” are replaced by documents like “Minimum Viable Architectures” that sketch a solution and are improved and extended bit by bit. Just like how developer teams work nowadays. By adopting this way of working, the gap between Architects and the people who actually carry out the work narrows a bit.
Useful tools
Just like developers, Architects have specific tools to do their daily work. Architects describe situations, design new (business) processes, draw architecture diagrams as well, and present their solutions to stakeholders. Often, they write documents to describe solutions, to list pros and cons as well as other aspects which have an impact on the organization. In short, they use a lot of tools.
One of the most important tools is a diagramming tool to create so-called “Architectural views” based on various viewpoints. Each diagramming tool handles specific formats and describes architecture diagrams in a specific language. Archimate is one of the most popular and versatile languages which is used by many architects worldwide. Many diagramming tools support Archimate, such as Archi in Linux or Sparkx Enterprise Architect for Windows and macOS. Mastering these tools helps you to create (business) process flows and draw application diagrams Other useful diagrams include information (flow) diagrams or (cloud) infrastructure designs.
One universal language
Developers working with scripting or programming languages are forced to write code that actually leads to a working program. Without typing the right syntax it won’t work. For architects, it’s important to understand the specific notation of the diagramming language. A universal notation helps to let others understand your diagrams and to make sure they are valid. There should be no doubt about certain areas of your diagram such as interfaces with other systems, (external) services, relationships as well as specific implementations. Architecture diagrams might be very large, so be sure to “step out” of the entire picture and create new diagrams that address a specific topic/situation.
Version control
Often Architects work on strategic or tactical topics that span a rather long time. It is tempting to lock yourself up for several weeks and present your work when you’re finished. However, what’s wrong with checking your work into the central source code control system? Just like developers do. This makes your work transparent to others and you have version history as well. It’s even possible to link your designs with specific sprints and/or releases.
Technical roles
Architects who work in technical roles should understand application architectures as well as the underlying infrastructure. Since the DevOps way of working pushes on and no one can escape, it’s important to have a solid understanding of how application components work together in combination with the underlying infrastructure. You need to know the foundational infrastructure services such as virtual networks, subnets, virtual IPs, load balancers, storage solutions, user management as well as access control groups, and so on.
Infrastructure and integration
To let your application perform best and be reliable at all times, you require skills to let your application land on those infrastructure resources. You need to determine the compute options such as Virtual Machines, containers, or serverless to name a few. In the case of a hybrid cloud situation, you also need to understand the connection points between the public cloud and the on-premises data center. Just an example: in Azure, there are 4+ methods to establish a connection between them ranging from site-to-site VPN all the way to the enterprise-grade express route that acts as the backbone for all applications and services.
From an integration perspective, knowledge of traditional message queues is not enough. You require knowledge of Azure Queue Storage, Service Bus Queues, and their equivalents on AWS and Google Cloud. Especially in serverless-related architectures you also need to incorporate the concepts such as “events” and “triggers” into your diagrams.
Security
Besides traditional security-related topics, such as PKI, access management, disk encryption, messages signing, and the like, it is a must-have to understand cloud security topics. Think of Cloud Security Posture Management and Cloud Native Workload Protection. On top of that, you need to understand the main security aspects that play a role in various stages of the CI/CD pipelines. The CI/CD pipeline is at the heart of everything so you also need to understand that everything you do has an impact on the software (application) supply chain.
Soft stills
Despite all of the important “hard skills” mentioned above, don’t forget about the soft skills. Essentially an Architect influences the organization on multiple levels. He/she needs to be able to negotiate about solutions, organizational changes as well as designs which propose new (working) processes or technical solutions. Therefore it’s key to be able to present your work well across various stakeholders and other people which are affected by your work. Be able to convince others without pushing them so they feel offended.
Furthermore, you require planning and leadership skills. That have an eye of where the organization is (or should) going in the future. Watch trends and translate them back to practical solutions to make them tangible. In short, your soft skills are an absolute necessity to success.
Wrap up
As you’ve read in this article, there are a lot of topics you need to take into account when working as an architect. There are many different areas in which you require specific expertise. No one said it would be easy right? :). Start your journey by selecting the type of architect you want to be and work your way through all of the topics that have been addressed. For sure there are many more things to dive into, but the main ones are covered. Feel free to explore more useful resources to boost your knowledge and become a respectful architect for your organization. Good luck.
