Getting to know architectural duties
Before we define what an Azure architect is, let's first define what an architect's role is and how our maps specialize to reflect these different profiles. The word architect is used everywhere on the IT planet. Many organizations have their own expectations when it comes to defining the tasks and duties of an architect. Let's share our own definitions as well as some illustrative diagrams.
Enterprise architects
Enterprise architects oversee the IT and business strategies, and they make sure that every IT initiative is in line with the enterprise business goals. They are directly reporting to the IT leadership and are sometimes scattered across business lines. They are also the guardians of building coherent and consistent overall IT landscapes for their respective companies. Given their broad role, enterprise architects have a helicopter view of the IT landscape, and they are not directly dealing with deep-dive technical topics, nor are they looking in detail at specific solutions or platforms, such as Azure, unless a company would put all its assets in Azure. In terms of modeling, they often rely on the TOGAF (short for The Open Group Architecture Framework) modeling framework and ArchiMate. The typical type of diagrams they deal with looks like the following:
Figure 1.1 – Capability viewpoint: ArchiMate
As you can see, this is very high level and not directly related to any technology or platform. Therefore, this book focusing on Azure is not intended for enterprise architects, but they are, of course, still welcome to read it!
Domain architects
Domain architects own a single domain, such as the cloud. In this case, the cloud is broader than just Azure, as it would probably encompass both public and private cloud providers. Domain architects are tech-savvy, and they define their domain roadmaps while supervising domain-related initiatives. Compared to enterprise architects, their scope is more limited, but it is still too broad to master the bits and bytes of an entire domain. This book, and more particularly our generic maps, will certainly be of great interest for cloud domain architects. Diagram-wise, the domain architects will also rely on TOGAF and other architecture frameworks, but scoped to their domain.
Solution architects
Solution architects help different teams to build solutions. They have T-shaped skills, which means that they are specialists in a given field (the base of the T), but they can also collaborate across disciplines with the other experts (the top of the T). Solution architects are usually in charge of designing solution diagrams, and they tackle non-functional requirements, such as security, performance, and scalability. Their preferred readings will be our chapter dedicated to solution architecture, as well as some reference architectures. Solution architects may build both high-level technology-agnostic, and platform-specific diagrams. Azure solution architects may build reference architectures, such as, for instance, one that we can find on the Azure Architecture Center (https://docs.microsoft.com/en-us/azure/architecture/):
Figure 1.2 – AI at the edge with Azure Stack
The preceding diagram illustrates how to leverage both Azure Stack and Azure, together with artificial intelligence services. Such architectures can be instantiated per asset, but still remain rather high-level. They depict the components and their interactions, and must be completed by the non-functional requirements. We will explore this in more detail in the next chapter.
Data architects
Data architects oversee the entire data landscape. They mostly focus on designing data platforms, for storage, insights, and advanced analytics. They deal with data modeling, data quality, and business intelligence, which consists of extracting valuable insights from the data, in order to realize substantial business benefits. A well-organized data architecture should ultimately deliver the DIKW (Data, Information, Knowledge, Wisdom) pyramid as shown in Figure 1.3:
Figure 1.3 – DIKW pyramid
Organizations have a lot of data, from which they try to extract valuable information, knowledge, and wisdom over time. The more you climb the pyramid, the higher the value. Consider the following scenario to understand the DIKW pyramid:
Figure 1.4 – DIKW pyramid example
Figure 1.4 shows that we start with raw data, which does not really make sense without context. These are just numbers. At the information stage, we understand that 31 stands for a day, 3 is March, and 3,000 is the number of visits. Now, these numbers mean something. The knowledge block is self-explanatory. We have analyzed our data and noticed that year after year, March 31 is a busy day. Thanks to this valuable insight, we can take the wise decision to restock our warehouses up front to make sure we do not run short on goods.
That is, among other things, the work of a data architect to help organizations learn from their data.
Data is the new gold rush, and Azure has a ton of data services as part of its catalog, which we will cover in Chapter 6, Data Architecture.
Technical architects
Technical architects have a deep vertical knowledge of a platform or technology stack, and they have hands-on practical experience. They usually coach developers, IT professionals, and DevOps engineers in the day-to-day implementation of a solution. They contribute to reference architectures by zooming inside some of the high-level components. For instance, if a reference architecture, designed by a solution architect, uses Azure Kubernetes Services (AKS) as part of the diagram, the technical architect might zoom inside the AKS cluster, to bring extra information on the cluster internals and some specific technologies. To illustrate this, Figure 1.5 shows a high-level diagram a solution architect might have done:
Figure 1.5 – Reference architecture example
Figure 1.6 shows the extra contribution of a technical architect:
Figure 1.6 – Reference architecture refined by a technical architect
We see that the reviewed diagram contains precise technologies, such as KEDA (Kubernetes-based Event Driven Autoscaling), and Dapr (Distributed Application Runtime), for both autoscaling and interactions with event and data stores.
The technical architect will mostly be interested in our detailed maps.
Security architects
In this hyper-connected world, the importance of security architecture has grown a lot. Security architects have a vertical knowledge of the security field. They usually deal with regulatory or in-house compliance requirements. The cloud and, more particularly, the public cloud, often emphasizes security concerns (much more than for equivalent on-premises systems and applications). With regard to diagrams, security architects will add a security view (or request one) to the reference solution architectures, such as the following:
Figure 1.7 – Simplified security view example
In the preceding example, the focus is set on pure security concerns: encryption in transit (TLS 1.2) between the browser and the web application firewall (WAF). The WAF enforces a security ruleset to protect against the Open Web Application Security Project (OWASP) top 10 vulnerabilities. The API gateway acts as a policy enforcement point before it forwards the request to the backend service. The backend authenticates to the database using managed service identity (MSI), and the database is encrypted at REST with customer-managed keys. Figure 1.7 clearly emphasizes what security architects are interested in.
However, as we will explore further in Chapter 7, Security Architecture, mastering cloud and cloud-native security is a tough challenge for a traditional (on-premises) security architect. Cloud native's defense in depth primarily relies on identity, while traditional defense in depth relies heavily on the network perimeter. This gap is often a source of tension between the cloud and non-cloud worlds.
Infrastructure architects
Infrastructure architects focus on building IT systems that host applications, or systems that are sometimes shared across workloads. They play a prominent role in setting up hybrid infrastructures, which bridge both the cloud and the on-premises world. Their diagrams reflect an infrastructure-only view, often related to the concept of a landing zone, which consists of defining how and where business assets will be hosted. A typical infrastructure diagram that comes to mind for a hybrid setup is the Hub & Spoke architecture (https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/hub-spoke):
Figure 1.8 – Hub and spoke architecture
Figure 1.8 is a simplified view of the hub and spoke, which, in reality, is much more complex than this. We will explore this further in Chapter 3, Infrastructure Design. We will also stress some important aspects related to legacy processes, so as to maximize the chances of a successful cloud journey.
Application architects
Application architects focus on building features that are requested by the business. Unlike other architects, they are not primarily concerned by non-functional requirements. Their role is to enforce industry best practices and coding patterns in order to make maintainable and readable applications. Their primary concerns are to integrate with the various Azure services and SDKs, as well as leverage cloud and cloud-native design patterns that are immensely different from traditional systems. Beyond this book, a good source of information for them is the Microsoft documentation on cloud design patterns (https://docs.microsoft.com/en-us/azure/architecture/patterns/).
What is challenging for application architects is to correctly understand the ecosystem in which the application runs. Today, there is a clear trend that entails breaking the monolith. In other words, we slice the architecture into multiple decoupled pieces, and we end up with a very distributed architecture. In most modern applications, a lot of common duties are offloaded to specialized services, often not so well known by old school application architects. For instance, an API gateway already has built-in policies for API throttling, token validation, and caching. Instead of writing your own plumbing in code to handle this, it is better to offload it. Another attention point for application architects is the horizontal scaling story of the cloud, meaning that applications/services must be multi-instance aware, which is rarely the case with monoliths. We will explore these concerns further in Chapter 5, Application Architecture.
Azure architects
From the top to the bottom of our enumeration, the IT landscape shrinks, from the broadest to the narrowest scope. It would be very surprising to ever meet an Azure enterprise architect. Similarly, it is unlikely that we will stumble upon an Azure domain architect, since the parent domain would rather be the cloud (which is much broader than just Azure).
However, it makes sense to have Azure-focused solution architects, technical architects, and data architects, because they get closer to the actual implementation of a solution or platform. Depending on your interest and background, you might specialize in one or more service models, which are depicted in the following section. Thus, some Azure architects will be interested in specialized maps, and some simply won't be interested, although it is always highly recommended to look at the broader picture.
Architects versus engineers
Before we move on, we need to address the engineer that we all have inside of us! What differentiates architects from engineers is probably the fact that most architects have to deal with the non-functional requirements piece. In contrast, engineers, such as developers and IT professionals, are focused on delivering and maintaining the features and systems requested by the business, which makes them very close to the final solution. Nevertheless, this book also contains some sections that are likely to help engineers build effective solutions.
Now that we are clear with what the role of an architect is all about, it is time to get started with the different service models and acquire the essential vocabulary that every Azure architect should know.