Book Image

Software Architecture for Busy Developers

By : Stéphane Eyskens
Book Image

Software Architecture for Busy Developers

By: Stéphane Eyskens

Overview of this book

Are you a seasoned developer who likes to add value to a project beyond just writing code? Have you realized that good development practices are not enough to make a project successful, and you now want to embrace the bigger picture in the IT landscape? If so, you're ready to become a software architect; someone who can deal with any IT stakeholder as well as add value to the numerous dimensions of software development. The sheer volume of content on software architecture can be overwhelming, however. Software Architecture for Busy Developers is here to help. Written by Stéphane Eyskens, author of The Azure Cloud Native Mapbook, this book guides you through your software architecture journey in a pragmatic way using real-world scenarios. By drawing on over 20 years of consulting experience, Stéphane will help you understand the role of a software architect, without the fluff or unnecessarily complex theory. You'll begin by understanding what non-functional requirements mean and how they concretely impact target architecture. The book then covers different frameworks used across the entire enterprise landscape with the help of use cases and examples. Finally, you'll discover ways in which the cloud is becoming a game changer in the world of software architecture. By the end of this book, you'll have gained a holistic understanding of the architectural landscape, as well as more specific software architecture skills. You'll also be ready to pursue your software architecture journey on your own - and in just one weekend!
Table of Contents (14 chapters)
Section 1: Introduction
Section 2: The Broader Architecture Landscape
Section 3: Software Design Patterns and Architecture Models
Section 4: Impact of the Cloud on Software Architecture Practices
Section 5: Architectural Trends and Summary

Introducing the different 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

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.


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.1 – Architecture disciplines: main duties

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

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.