First of all, there is a big difference between, being an architect or holding the title of an architect versus, being a successful architect
So, what does it mean and require to be a successful architect?
One of the most common and difficult aspects, to become an architect for someone from pure technical background or position, is that it is almost always a vague role.
In fact, there are literally several roles and titles of an architect, such as; enterprise architect, solutions architect, applications architect, data architect, network architect, business architect, technical architect etc.
For example, how dose enterprise architect differs from network and solutions architect, and which one of these do I want?
In reality, you may find that in many organizations, the architect role is just so ill-defined, and it just refers to the most senior technologist around and has been given this title “architect”, in which there’s no clear definition to his/her roles in the company besides just he/she’s the senior tech person.
To answer the difficult question “what does it mean and require to be a successful architect?” you need first to understating what are the foundational aspects, attributes and capabilities an architect must have along with the minimum expectations of each.
As highlighted earlier, defining the exact role of an architect can vary to a large extent, however instead of focusing on the roles, that can vary, this article focuses on what is more important which is the expectations. in fact, there are several key expectations, some of which you might not even see it in a job add or part of the actual architect job description JD. Such as;
Architectural mindset and thinking, understanding of business model and organizational structures, technical knowledge scope, communication skills, ability to define architecture decisions and principles that serve as a guidance for the detailed solution design and technology selection, etc. this blog will focus on the knowledge scope expectation.
As an architect, whether a network architect, solutions architect or any type of architect in IT filed, the technical experience and knowledge serve as the foundation. In other words, the more technical expertise with a wider knowledge scope an architect has, the more chances the architect will have, to be a “successful architect”.
So, what does the wider knowledge scope refers to? and why is it important?
To simplify it, let’s consider what is known as the knowledge pyramid. As illustrated in the figure below, There’s three kinds of knowledge types or levels.
At the top, is the technology areas that you know and might be experienced, and the reality is, this is smallest one compared to the other ones, no matter how much experienced the architect is in certain areas. The second level, is the technologies and solutions that you know that you don’t know. For instances, you are aware that there is a software-defined WAN solution, and aware of its drivers, value etc. but you are certainly not an expert in SD-WAN. Therefore, it is something you know that you don’t know much about it, however, you are familiar with the solution and its components etc. to a certain extent that is good enough to talk about it in a very high level or to go and read about more.
On the other hand, the third level, which is the stuff that you don’t know that you don’t know. In fact, this is the most interesting and critical one, and in reality it is always the widest one. So why it’s critical? For instance, if you are in a meeting with a customer from healthcare sector, and the client mentions that they need the proposed solution to be HIPPA compliant. If you have no idea what does HIPPA is (Health Insurance Portability and Accounting Act) this will be a big issue, while you are in meeting with the customer, because it reflects lack of this sector’s specific ‘needs and requirements’ knowledge. In the end you will realize that you didn’t know that you didn’t know about HIPPA or what is it.
Does this mean you need to be experienced in various technology areas to be a successful architect? The simple answer is, for sure no.
As an architect, you don’t need to be an expert in every single area. Instead, your knowledge should be “a mile wide and an inch deep”. In other words, you need to focus on the scope or breadth of the knowledge more than the depth. That being said, we all have interest in certain solutions and technology areas, in which we can dive deeper.
The key point here, as an architect, you should try to always discover stuff that you are not aware of (you don’t know that you don’t know about) and move it into the second level which is the stuff that you know you that don’t know about it. As result you will increase your technical knowledge and awareness scope about different solutions and technologies, protocols, etc. You don’t necessarily need to know the ‘in and out’ about them, but at least you have awareness about such solutions, drivers, concepts, industry standards, protocols etc.
As an architect, you are always required to provide possible solution alternatives. That is why the smaller your technical knowledge scope or breadth, the less valid options or alternatives you will be able to provide. Let’s consider this hypothetical example, if you are architecting a solution to a customer who needs to build high performance, high scalability applications, across distributed data centers and your recommendation to this customer is consider layer 2 data center interconnect DCI solution between the data centers. Then the company says right, OK, what DCI solution should we use?
With a limited technical knowledge breadth, you may recommend solution X or Y, while in fact solution Z in this scenario is over there the most optimal solution for this scenario.
Even though, solutions X and Y can work, but the problem here, it’s not going to be the best fit and may have impact in the future on other architecture attributes such as interoperability, scalability, performance etc.
The key issue here, is without the architect technical knowledge breadth of knowing the available solutions or design options, the architect does not even know about solution Z to recommend it.
That’s why the technical knowledge scope or breath is very important for any successful architect.
For more info, you may refer to the link below, of the recorded interview with the Cisco learning network where I discussed some of the content of this blog, along with André Laurent.