Often, software development is all about cost and time. No one knows exactly why, but the software industry is almost always associated with tight deadlines, insufficient resources, and long hours. Under this kind of pressure, it’s common to question the importance of everything that is not strictly coding. Testing is a common victim of this, along with documentation and, of course, design. But of course, these phases are essential for the success of a project. While we will quickly touch on most of those aspects, architecture design is the core of this book, and I believe that by understanding the practices and goals, the need for it will become clear to everybody.

In this section, we will discover what the fundamental objects of a properly designed architecture are. Highlighting those simple but crucial points is useful in raising awareness about the importance of this phase. If you start advocating those good practices in your team, the quality of your software deliverables will increase.

The objectives of architecture design in the software life cycle

The ultimate goal of this book is not to define the architecture per se; there are plenty of papers and interesting things available on that matter, including the awesome work of Martin Fowler. Nevertheless, there are a couple of considerations that we need to bear in mind.

The architecture should support the crucial decisions within our software project. However, the architecture itself is actually a loose concept, often including different plans (such as physical, logical, network, and more) and points of view (such as users, business logic, machine-to-machine interactions, and more).

Let’s take the most overused metaphor as an example: a software project is like a building. And similarly to a construction project, we require many different points of view, with different levels of detail, ranging from general overviews to detailed calculations and the bills of materials. A general overview is useful to give us an idea of where we are and where we want to go. In addition to this, it is an essential tool for being sure we are on the right path. However, a system overview doesn’t provide enough details for teams such as networking, security, sysops, and, ultimately, the developers that require a more substantiated and quantitative view to drive their day-to-day decisions.

The main goals of designing a proper software architecture include the following:

• Prospecting a birds-eye view to project sponsors and investors. While it is not a good practice to drive a business discussion (for example, an elevator pitch) toward technical elements too soon, a higher level of management, venture capitalists, and the like are becoming increasingly curious about technical details, so a high-level overview of the application components can be crucial for winning this kind of discussion.
• Defining a shared lingo for components of our solution, which is crucial for collaborating across the team.
• Providing guidance for technological choices since putting our design decisions on paper will clarify important traits of our application. Will data be central? Do we need to focus on multiple geographies? Are user interactions the most common use case? Some of those reasonings will change over time. However, correctly designing our application will drive some crucial technology choices, in terms of choosing components and stacks to rely on.
• Splitting roles and responsibilities. While a proper project plan, a statement of work, or a Responsible, Accountable, Consulted, Informed (RACI) (which is a classical way to categorize who does what) table will be used for real project management, writing the software backbone down on paper is our first look at who we have to involve for proper project execution.

Indeed, the architecture is an excellent example of planning in advance. However, a proper software architecture should be much more than a technological datasheet.

Architecture, as with buildings, is more about the styles and guidelines to be followed all around the project. The final goal of a piece of software architecture is to find elegant solutions to the problems that will arise during the project plan. Ultimately, it will act as guidance throughout the project’s life cycle.

The software architect – role and skills

As a role, the software architect is often identified as the more senior technical resource in the IT team. In fact, the job role of an architect is almost always seen as a career progression for developers, especially in enterprise environments. While not necessary, being good at coding is crucial for a complete comprehension of the overall functioning of the system.

There are several different other skills that are required to be a successful architect, including creativity, the ability to synthesize, and vision. However, above all, experience is what it takes to become an architect.

This includes firsthand experience on many different projects, solving real-world issues: what a proper software design looks like and how the design has evolved. This skillset is very useful to have in the background of the architect.

Additionally, it’s vital to have a huge library of solutions to choose from in order to avoid reinventing the wheel. While we love to think that our problem is very unique, it’s very unlikely to be so.

This leads us to the approach that we will use in this book: we will not focus on just one aspect or technology to drill down on, but we will take a horizontal approach, discussing a number of different topics and offering ideas on how to approach potential problems. We hope to act as a handbook to support you when making real-world choices.

Is architecture design still relevant in modern development?

There will be a couple of chapters dedicated to discussing Microservices, DevOps, and the cloud-native avalanche, but it’s safe to assume that in one form or another, you will have plenty of opportunities to hear something about them.

As you might have gathered, most of these concepts are not really new. The Agile Manifesto, which is a seminal work detailing some of the practices commonly used in modern development techniques, was published in 2001, yet most of the common-sense principles it contains are misinterpreted. When I was working in IT consulting back in 2008, a common joke among development teams was "Yes, we do agile. We skip documentation and testing."

Of course, that’s just an opinion based on personal experience. There are plenty of teams who do not underestimate the importance of proper planning and documentation and are doing wonderfully while working with Agile. Yet, in some cases, less structured development methodologies have been taken as an excuse to skip some crucial steps of the development life cycle.

As we will elaborate, in Chapter 5, Exploring the Most Common Development Models, Agile is much more than slimming down boring phases of the project. Indeed, testing and documentation are still very relevant, and Agile is no excuse to skip that.

There are plenty of reflections you can take in terms of how to adapt your design techniques to DevOps, Agile, and more, and we will discuss this topic later in this book. However, one thing is certain: architecture matters. Design is very relevant. We have to spend the correct amount of time planning our choices, revisiting them when needed, and generally, sticking with some well-defined guiding principles. The alternative is poor quality deliverables or no deliverables at all.

Now, let’s take a look at what the first phases of software design usually look like.

When we start to shape the architecture of a new application, the result is often familiar.

I would say that across different geographies, industries, and application types, some elements are common. The architectural sketches are usually made of boxes and lines, with labels, arrows, and similar artifacts. That’s an intuitive way to shape our thoughts on paper.

However, in the following section, we will go through different ways of expressing those concepts. This will make us aware of available styles and techniques and will make our diagram clearer and, ultimately, easier to share and understand.

But first, let’s find out what the characteristics of architectural sketching actually are.

Sketching the main architectural components

As we discussed earlier, there are a number of different components that are recurrent in a high-level architectural sketch. Let’s examine them one by one:

• Boxes: These represent the software components. They can refer to one complete application or specific subcomponents (such as packages, modules, or similar things).
• Lines: These describe the relationships between the boxes. Those links imply some sort of communication, commonly in the form of APIs. The lines can also represent inheritance or a grouping of some sort. A direction (that is, an arrow) can also be specified.
• Layers: These are a dotted or dashed line, grouping components and their relationships. They are used to identify logical slices of the architecture (such as the frontend, backend, and more), the grouping of subcomponents (for example, validation and business logic), network segments (such as the intranet and DMZ), physical data centers, and more.
• Actors: Simulating the interactions of users within the systems, actors are usually represented as stickmen, sitting on top of some components (usually frontends or UIs of some sort). It is not uncommon to observe different channels represented, in the form of laptops or mobile phones, depending on the industry and type of application (for example, ATMs, branch offices, and physical industrial plants).

Now, let’s view an example sketch:

Figure 1.1 – The common components on a first architectural sketch

As we’ve already mentioned, the quick and dirty representation shown in this diagram is useful since it’s an easy way to start thinking about how our application should look. However, on a closer look, there are some common inaccuracies:

• The software components (that is, our boxes) might be represented with different levels of zoom: sometimes representing applications, sometimes features, and sometimes software modules. This is inconsistent and could generate confusion.
• Some components are specialized (for example, databases), while others are not. As noted in the preceding point, this leads to an inhomogeneous view.
• In some parts of the diagram, we are representing use cases or information flows (for example, with the actors), while elsewhere, we are drawing a static picture of the components.
• Some points of view don’t cope well with others because we might be representing network firewalls but not referencing any other networking setup.

Now that we’ve learned what a naïve representation looks like and what its limits are, let’s take a look at some other types of diagrams and how they represent alternative points of view.

As we discovered in the previous section, the first sketches of a piece of architecture often end up as an intuitive and naïve view, lacking essential details. In this section, we will look at an overview of different types of architectural diagrams. This will help us to pick the right diagram for the right situation, defining a clearer view of our architecture. So, let’s dig into some details.

Common types of architectural diagrams

In order to define a clearer and more detailed view of what our software will look like, it’s essential to start picking layers and points of view to represent. This will naturally lead us to focus on more tailored designs. While not exhaustive, a list of possible architectural diagrams includes the following:

• Software components: This kind of schema includes different software modules (such as applications or other components) and the interaction between them (for example, read from, write to, listen, and more). One particular instance of this diagram could include protocols and formats of communication between those components, becoming close to a complete API documentation:

Figure 1.2 – Software components diagram

• Network architecture: This is a pretty common design type and is often considered the more scientific and detailed one. It includes data such as network segments (DMZ and INTRANET), Firewall, IP addressing, and more:

Figure 1.3 – Network architecture diagram

• Physical architecture: This is a mapping of software modules into server deployments. Usually, it’s complete with information about the server hardware and model. In the case of a multiple datacenter setup (which is pretty common in enterprise environments), it can also contain details about racks and rooms. Storage is another relatively common component. Depending on the implementation, this architecture might include information about virtualization technology (for example, the mapping of VMS to the physical servers that are hosting it). Additionally, it could, where relevant, include references to cloud or container deployments:

Figure 1.4 – Physical architecture diagram

These are the very basic points of view in an architecture diagram and an essential starting point when detailing the design of your application. Diving further into the application specification life, other kinds of diagrams, often derivatives of those, could be elaborated (for example, cloud deployment diagrams, software modules, and more) depending on your specific needs. In the next section, we will focus on Java technology, which is the other fundamental topic of this book and crucial for completing our architectural view of modern applications.