In this chapter, I will introduce the subject of software architecture. My purpose is to help you understand my vision of software architecture and how I will tackle this topic throughout the book.

More specifically, this chapter covers the following topics:

• Software architecture in a nutshell
• A software architect's duties
• Introducing the different architecture disciplines
• Positioning software architecture within the global architecture landscape

By the end of the chapter, you should have a better grip on software architecture and a better idea of how this book will walk you through your software architecture journey.

However rich the literature is on the topic, it's not so easy to find a common definition of software architecture. We as architects like to decouple things, so let's decouple the words software and architecture. Starting with software, we can give this broad definition: computer programs. Our second word, architecture, can be defined as the art of designing buildings, houses, and the like. If we extrapolate a bit, we could define software architecture as the art of designing computer programs. This definition sounds very broad.

Rest assured, we can evacuate hardware from the equation because it represents the machines themselves. Phew—this should make our task easier, although we are left with everything that runs on a piece of hardware, which remains extremely vast.

Searching for software architecture on Google reveals about 262,000 results, which is very impressive. So many results probably mean a lot of different definitions and a lack of a common understanding of what software architecture is all about. The same query on Google Images does not bring up a single diagram that could help up figure out what software architecture is.

Given the diversity of definitions, I will provide my own, although I don't claim to have the absolute truth. I will start by tying software architecture to the Architecture Tradeoff Analysis Method (ATAM), which we will see in Chapter 3, Understanding ATAM and the Software Quality Attributes. In a nutshell, ATAM consists of evaluating different quality attributes—such as performance, availability, reliability, and so on—of a piece of software. Some of these attributes are code-related, whereas some are infrastructure- or security-related.

Although there is no single definition of software architecture, one thing is absolutely certain: a software architect should be acquainted with ATAM. Another thing that appears as an emerging consensus is that the role of a software architect is tightly coupled with the actual development of an application, and I share this viewpoint. This is how Wikipedia (https://en.wikipedia.org/wiki/Software_architect) defines software architecture, but for me, software architecture goes far beyond mere coding, and that is what you will find out while reading this book. Let's now look at what a software architect's job description might look like.

Sometimes, a good job description helps understand the tasks and duties pertaining to a given position. Here again, looking for such descriptions on the web gives many different results, but this is what I think are the responsibilities of a software architect:

• Addressing both functional requirements (FRs) and non-functional requirements (NFRs): As you know, FRs are the primary trigger to design a solution. Whether the solution/service is designed for the business or for the Information Technology (IT) department itself, you make your business case and then start the design work. NFRs (availability, security, disaster recovery (DR), and so on) are not always expressed but are also particularly important and are often the most challenging part.

  This book will help you address these requirements in a structured way. Addressing both FRs and NFRs is also the duty of a solution architect, so it can be debated whether this should fall under the duties of a software architect or not. I think that a good software architect is able to address FRs. An excellent software architect can address both while addressing FRs in a more in-depth way than a solution architect.

• Providing technical standards, coding guidelines, and design patterns to developers: Functional features are an integral part of the code base. It's a no-brainer that good design patterns usually improve the resulting quality of a solution. As a software architect, you must understand them and you must be able to sense which pattern is valuable in your own context. We will dive into design patterns in Chapter 5, Design Patterns and Clean Architecture, as well as in Chapter 6, Impact of the Cloud on the Software Architecture Practice, where we will explore cloud and cloud-native patterns.
• Interacting with stakeholders to ensure developed applications land smoothly in the company's landscape: A successful software architect understands multilateral concerns. They are able to interact with security, infrastructure, solution, and enterprise architects, as well as with developers.

  This book will give you the essential keys to achieve T-shaped skills, which means being an expert in a given field (the base of the T) but also knowledgeable across disciplines (the top of the T). To reinforce your T top bar, we will explore some fundamentals of enterprise architecture (EA), which is a common practice in large organizations, and we will touch on some infrastructure and security typical frameworks. However, I have to manage your expectations here, as the book will only introduce these topics.

• Performing an active role in the solution delivery process: A close follow-up with the development teams and a good understanding of waterfall and agile methodologies will undoubtedly lead to a smoother delivery.
• Proactive technology watching to identify new trends and paradigm shifts: Technology is an enabler. Most digital native companies managed to leverage technology wisely and they became Netflix, Facebook, and the like. A good software architect must permanently keep an eye on the ever-evolving technology landscape.

More importantly, a good software architect must exercise good judgment. They should not blindly apply framework x or y, nor pattern a or b. They must contextualize and apply their skills wisely. Let's now discover the various architecture disciplines.

There are so many types of architects that we can quickly get lost and wonder who does what in an enterprise. Because this understanding is an essential asset, let's start by reviewing the different disciplines, and I will position software architecture in the mix in the next section. The following diagram shows some of the most common architecture disciplines and their main duties:

Figure 1.1 – Architecture disciplines: main duties

From top to bottom of the preceding diagram, you can find the main duties by order of priority. Not every discipline is represented, but the main ones are. A noticeable exception, however, is cloud architecture, which we will talk about later. We will discuss some of the related frameworks in our next chapter. Let's now focus on the scope of each discipline.

EA

Enterprise architects oversee the IT and business strategies, and they make sure every IT initiative is in line with the enterprise business goals. They directly report to 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.

Most of the time, enterprise architects have a holistic view of the IT landscape and are not concerned with technicalities. Their primary focus is to identify and design business capabilities. They are helped by business architects, who are usually also a part of the EA function. Their role consists of defining the strategic orientations and making sure their standards percolate across teams. They usually work with The Open Group Architecture Framework (TOGAF) to define the processes and with ArchiMate to build visual models of the different domains. In some organizations, the EA function can assign a dedicated enterprise architect for large projects or programs.

Solution architecture (SolAr)

Solution architects help different teams to build solutions. They have so-called T-shaped skills because they oversee the design of a solution end to end (E2E). They mostly focus on NFRs to ensure a solution is fit for use. As with software architects, they also look at FRs (ensuring that they are fit for purpose), but they are not involved in the actual development of the features.

Infrastructure architecture (IA)

Infrastructure architects focus on building and operating specific application infrastructures and platforms that are shared across workloads. One of their duties is to keep the lights on, to ensure commodity services such as mail systems and workplace-related services are up and running. Infrastructure is organized around IT Service Management (ITSM), which most of the time is based on the IT Infrastructure Library (ITIL). The infrastructure department also provides a service-desk function. Many organizations have started to move (or have moved already) to ServiceNow, a more modern way to handle ITSM.

Security architecture (SA)

In this hyper-connected world, the importance of cybersecurity has grown a lot. SA deals with regulatory or in-house compliance requirements. In these modern times, more and more workloads are deployed to the cloud, which often emphasizes security concerns because many organizations are still in the middle of their cloud journey, or on the verge of starting it.

The security field is split into different sub-disciplines such as security operations centers (SOCs), the management of specialized security hardware and software, Identity and Access Management (IAM), and overall security governance, also known as the security posture. In medium-to-large organizations, you can find blue (defend) and red (attack) teams, composed of technical security experts. Together with the SOC, they evaluate the robustness of a business's overall resilience. The SA practice is usually managed by a chief information security officer (CISO), although the role is sometimes also carried out by a chief information officer (CIO).

Depending on the industry you are in, security is typically one of the lesser-known NFRs, not well understood by business, which leads to a complete lack of business requirements in that matter. Security-awareness programs are often required to alert businesses about the importance of security. In a nutshell, the way the security practice is conducted heavily depends on the culture, the risk appetite, and the organization's DNA.

Data architecture (DA)

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 (BI), which consists of extracting valuable insights from the data to realize substantial business benefits. A well-organized data architecture should ultimately deliver the data-information-knowledge-wisdom (DIKW) pyramid, as shown in the following diagram:

Figure 1.2 – DIKW pyramid

Organizations have a lot of data, from which they try to extract valuable information and knowledge and gain wisdom over time. The more you climb the pyramid, the more value there is. Consider the following scenario to understand the DIKW pyramid:

Figure 1.3 – DIKW pyramid example

This shows us that, among other things, the work of a data architect is to help organizations learn from their data.

Application architecture (AA)

Application architects focus on building features that are requested by the business. They make sure the developed application is fit for purpose. They enforce coding patterns and guidelines to make maintainable and readable applications. Their primary concern is to integrate with the various frameworks and ecosystems. Their role resembles the software architect one but is, in my opinion, more limited. Let's now position software architecture within the various disciplines.

Given the introduction outlined in the previous sections, I will position software architecture very closely to the actual development of a solution, but I will not limit it to only that.

The following screenshot shows how I position the software architecture practice:

Figure 1.4 – Software architecture within the architecture landscape

Software architects should ideally be knowledgeable in all the topics listed in the shapes with a dark background in Figure 1.4. As stated before, software architects will be less focused on NFRs (the shape with dotted lines in Figure 1.4) than a solution architect but should still know the basics. The same consideration applies to an EA practice. Let's now recap on this first chapter.

In this chapter, I set the scene by explaining my understanding of software architecture, which is based on real-world experience within different companies and industries. We reviewed the different architecture disciplines when positioning software architecture, and I wanted you to realize that you need to know a little bit of all the other disciplines to be a successful software architect. I hope that you understand the value proposition of this book and that you are ready to embark on this software architecture adventure.

In the next chapter, I will slightly touch on some of the typical frameworks used in the different disciplines. This will help you speak the vocabulary of your stakeholders to become an even better software architect.