I recently started writing a book on the topic of architecture views. As I progressed through the different views, I began to think about categorizing them, making it easier to understand where each view belongs in the world of architecture. This was more difficult than I anticipated. I considered categorization by stakeholders, scope, discipline, domain, and role, and after a while, I found that the views crossed all these aspects. This led me to reflect on the field of IT architecture and the role of the architect in any given organization. I thought about some of my friends working in various industry sectors, and when they ask what I do, I explain that I work as an Enterprise Architect, and the result is blank faces. I then make an attempt to explain the role and that “Enterprise” has nothing to do with Star Trek. Eventually, I summarize in simple terms with, “I help businesses with their technology strategy, execution, and planning.”
The thing is that outside of architectural circles, it is difficult for some business stakeholders to understand what we do. This is perhaps because we deal in rather abstract terms. It comes with the job as we learn to use abstraction to manage complexity. Therefore, we use definitions such as Enterprise, Solution, and Business, which are not always tangible to other stakeholders. Consider other professions: Chemical Engineer, Financial Advisor, Accountant, or Surgeon. Without a big explanation, we sort of understand what the profession entails. This led me to explore what we mean by the IT architecture profession.
THE PROFESSION
A central principle of a profession is that it requires specialized knowledge and skills. In IT architecture, it takes many years to gain the knowledge and skills required to be a professional architect. In my opinion, at the core of our profession are our knowledge and skills in technology. This is what we bring to the table; it is our knowledge and expertise in both business and technology that make the IT architecture profession unique.
In addition to business and technology skills, it is essential that the architect possesses soft skills such as leadership, politics, and people management. These are often undervalued. When communicating IT architecture and what an IT architect does, I notice that there are a number of recurring aspects: scope, discipline, domain, and role.
SCOPE
We often think of scope in terms of organizational levels. At the highest organizational levels, the scope is broad, and the architecture is often more abstract. At the lower organizational levels, the scope is narrow, and the architecture is more detailed. As an architect, I find that we often define scope in terms of Enterprise, Business, and Solution. As mentioned before, these terms are rather abstract and do not align well with how scope is defined in most organizations.
A common structure for scope in many organizations is to consider strategic, tactical, and operational levels. Aligning with this definition of scope would perhaps help business stakeholders gain a better understanding of where the architect is operating. I considered titles such as Strategic IT Architect or perhaps a description that illustrates working at several levels, for example, “IT Architect operating at the strategic and tactical levels.”.
DISCIPLINE
Disciplines provide the fundamental principles and knowledge in the general areas of the profession. For example, Clinical Nursing is a discipline within the profession of Nursing. In IT architecture, Enterprise, Business, Solution, Software, and Infrastructure architecture are commonly described as disciplines. In my opinion, these form the core disciplines in IT architecture, and within architectural circles, I think they are well accepted. There are several other definitions of disciplines, such as security, data, or application, but I feel that these are already addressed within the core disciplines.
I find that we often express roles as being equal to a particular discipline. However, an experienced architect typically has knowledge and expertise in several of these disciplines, and any given architecture role may require knowledge of multiple disciplines. I feel that aligning roles solely with does not often reflect what most architects actually do. For example, many of the architects I have worked with on solution architectures also practice software architecture and business architecture in their role.
I think it is beneficial to practice and have knowledge of several disciplines. In my opinion, this aids communication between architects and hinders an “ivory tower” culture. It promotes a view of that architecture disciplines are interconnected, spanning all the way from strategy through to operations.
DOMAIN
Domains are often specialized areas of knowledge and may require the involvement of several disciplines. In other professions, domains often align with a particular industry. For example, in the engineering profession, we have the automotive domain, which involves expertise from both mechanical and electrical engineering disciplines. In the case of IT architecture, we often focus our domains around specific technologies such as cloud, security, business intelligence, or artificial intelligence.
I think there is room to consider industry domains since these sectors often require specialized knowledge and expertise, for example, legal requirements, regulations, or knowledge of the business model. Domains seem like a particularly useful way of describing what an architect does since they are often specific, particularly when combined with an industry domain.
ROLE
If scope, discipline, and domain all provide relevant descriptions of what the architect does, how do we define roles? We can perhaps consider what the purpose of a role is. We often use roles for several purposes:
- Role within a Profession
This is often a broad definition of a role covering the fundamental expectations according to the profession. - Established Roles within an Organisation
Roles defined within an organisation that are specific and tailored to that organisation’s needs. For example, a department or a project role. - Role for Recruitment
These may be specific or broadly defined depending on the needs of the organisation. Sometimes roles for recruitment are defined so that an individual can act in several roles, or actual roles are not yet clearly defined but there is a clear need for a particular skill set.
I took a look at how the industry describes the roles of the IT Architect, rather unscientifically, by performing some searches on LinkedIn. The results are interesting and perhaps say something about how the industry sees roles in our profession.
| Role Title | Count |
| IT Architect | 10700 |
| Enterprise Architect | 1200 |
| Business Architect | 412 |
| Solution Architect | 5082 |
| Software Architect | 2029 |
| Infrastructure Architect | 523 |
| Chief/Lead Architect | 102 |
* Results from job searches on LinkedIn in EMEA (2024-06-06)
The job descriptions provided from the search often have a title that reflects the discipline and sometimes the domain, but it was also quite common to express seniority. We can see from the results that industry still favors the title IT Architect, while Enterprise, Solution, and Software architects forming the larger part of industry needs.
It seems that the difficulty in defining roles in the IT architecture profession is that any given architecture assignment can touch several scopes, disciplines, and domains. This is unsurprising since it is in the nature of our profession to observe the big picture, and try to connecting the business and technology dots across scopes and domains. I find that this is often a key factor, or perhaps a talent often reflected in the people who hold IT architect roles.
It seems to me that it is simpler for an organisation to define an architect role since the context for the role already exists in the organisation; it is specific. Defining roles in the IT architecture profession is much more difficult and requires industry consensus, which perhaps may only be gained over time.
CONCLUSION
In the IT Architecture profession, it is still early days. Other professions such as medical or engineering have formed over hundreds or even thousands of years. The information technology is new and it’s perhaps not surprising that it is sometimes difficult to explain what we do as architects. It seems to me that industry commonly uses the well-established titles Enterprise Architect, Solution Architect, Software Architect and Infrastructure Architect under the broad title of IT Architect and seniority is commonly given. It also seems that Business Architect roles are often encapsulated in the Enterprise Architect role. However, any given role may require knowledge in several disciplines.
Perhaps the direction for the profession is to focus on gaining consensus around how we describe scope, domain and discipline rather than worrying too much about titles. An organisation should be able to describe a role from these aspects and describe the required seniority.
At the end of the day, this was a thought-provoking exercise and with regards to my original problem, the categorisation of architecture views, I found that scope was perhaps the simplest way to organise the book.
I hope that this article inspires the reader to consider what we do as IT architects, and contribute with ideas to driving the IT architecture profession forward. The IT architecture profession is of great importance to our society and its significance will only grow the future. By reflecting on the profession, we can shape the future of IT architecture together.