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.

Now that we’ve briefly touched on the various kinds of designs and diagrams of an application, let’s focus on the other fundamental topic of this book: the Java language.

It’s not uncommon to hear that Java is dead. However, if you are reading this book, you probably agree that this is far from the truth.

Of course, the panorama of software development languages for enterprise applications is now wider and more complicated than the golden age of Java; nevertheless, the language is still alive and widespread, especially in some areas.

In this section, we will explore the usage of Java technology in the enterprise software landscape. Then, we will take a quick glance at the history of Java Enterprise Edition (JEE). This will be a good foundation to understand existing enterprise architectures and model modern, cloud-native applications based on this technology.

Now, let’s examine why Java technology is still thriving.

Why Java technology is still relevant today

The most important reason for Java’s popularity is probably the availability of skill. There are plenty of experts on this language, as many polls and studies show (for example, PYPL and Tiobe). Another crucial point is the relevance of the ecosystem, in terms of the quantity and quality of libraries, resources, and tooling available for the Java platform.

Rewriting complex applications (including their dependencies) from Java to another language could probably take years, and, long story short, there might be no reason to do that. Java just works, and it’s an incredibly productive platform. It might be slow and resource-intensive in some scenarios, but this is balanced by its stability. The language has been battle-tested, is feature-rich, and essentially, covers all the use cases required in an enterprise, such as transactionality, integration with legacy environments, and manageability.

Now, let’s take a look at where and how Java technology is used in enterprise environments. This can be very useful to understand existing scenarios and fit new applications into existing application landscapes.

Java usage in enterprise environments

In order to fit our Java application in the overall architecture, it’s important to understand the typical context of a large enterprise, from a software architecture perspective.

Of course, the enterprise architecture depends a lot on the industry domain (for instance, banking, telecommunications, media, and more), geography, and the tenure of the organization, so my vision might be slightly biased toward the segment I have worked with for the longest (a large enterprise in the EMEA area). Still, I think we can summarize it as follows:

• Legacy: Big applications, usually running very core functions of the enterprise for many years (at least more than 10 and commonly more than 20). Needless to say, the technology here is not the most current (Cobol is widespread in this area, but it is not uncommon to see other things such as PL SQL, huge batch scripts, and even C/C++ code). However, the language is seldom an issue here. Of course, nowadays, those skills are very rare to find on the job market, but usually, the software just works. The point here is that most of the time, nobody exactly knows what the software does, as it’s poorly documented and tested. Moreover, you usually don’t have automated release procedures, so every time you perform a bugfix, you have to cross your fingers. Needless to say, a proper testing environment has never been utilized, so most of the things have to be tested in production.
• Web (and mobile): This is another big chunk of the enterprise architecture. Usually, it is easier to govern than legacy but still very critical. Indeed, by design, these applications are heavily customer-facing, so you can’t afford downtime or critical bugs. In terms of technologies, the situation here is more fragmented. Newer deployments are almost exclusively made of Single-Page Applications (SPAs) based on JavaScript (implemented with frameworks such as Angular, Vue, and React). Backends are REST services implemented in JavaScript (Node.js) or Java.
• Business applications: Often, the gap between web applications and business applications is very thin. Here, the rule of thumb is that business applications are less web-centric (even if they often have a web GUI), and usually, they are not customer exposed. The most common kind of business application is the management of internal back-office processes. It’s hard to find a recurrent pattern in business applications since it’s an area that contains very different things (such as CRMs, HR applications, branch office management, and more).
• BigData: Under various names and nuances (such as data warehouses, data lakes, and AI), BigData is commonly a very huge workload in terms of the resources required. Here, the technologies are often packaged software, while custom development is done using various languages, depending on the core engine chosen. The most common languages in this area are Java (Scala), R (which is decreasing in popularity), and Python (which is increasing in popularity). In some implementations, a big chunk of SQL is used to stitch calculations together.
• Middlewares and infrastructure: Here falls everything that glues the other apps together. The most common pattern here is the integration (synchronous or asynchronous). The keywords are ESB, SOA, and messaging. Other things such as Single Sign-On and identity providers can be included here.

As I mentioned, this is just a coarse-grained classification, useful as reference points regarding where our application will fit and which other actor our application will be interacting with.

Notice that the technologies mentioned are mostly traditional ones. With the emergence of modern paradigms (such as the cloud, microservices, and serverless), new languages and stacks are quickly gaining their place. Notable examples are Go in the microservice development area and Rust for system programming.

However, those technologies and approaches are often just evolutions (or brand-new applications) belonging to the same categories. Here, the most interesting exception is in the middleware area, where some approaches are decreasing in popularity (for example, SOA) in favor of lighter alternatives. We will discuss this in Chapter 7, Exploring Middleware and Frameworks.

Now that we’ve explored the widespread usage of Java in an enterprise context, let’s take a look at its recent history.

JEE evolution and criticism

JEE, as we have learned, is still central in common enterprise applications. The heritage of this language is just great. The effort that has been done in terms of standardizing a set of APIs for common features (such as transactionality, web services, and persistence) is just amazing, and the cooperation between different vendors, to provide interoperability and reference implementation, has been a very successful one.

However, in the last couple of years, a different set of needs has emerged. The issue with JEE is that in order to preserve long-term stability and cross-vendor compatibility, the evolution of the technology is not very quick. With the emergence of cloud and more modular applications, features such as observability, modular packaging, and access to no SQL databases have become essential for modern applications. Of course, standards and committees have also had their moments, with developers starting to move away from vanilla implementations and using third-party libraries and non-standard approaches.

Important Note:

The objective of this book is not to recap the history and controversy of the JEE platform. However, organizational issues (culminating with the donation of the project to the Eclipse Foundation) and less frequent releases have contributed to the decrease in popularity of the platform.

The upcoming of the Platform-as-a-Service (PaaS) paradigm is another important event that is changing the landscape. Modern orchestration platforms (with Kubernetes as the most famous example), both in the cloud or on-premises, are moving toward a different approach. We will examine this in greater detail later, but essentially, the core concept is that for the sake of scalability and control, some of the typical features of the application server (for example, clustering and the service registry) are delegated to the platform itself. This has a strict liaison with the microservice approach and the benefits they bring. In the JEE world, this means that those features become duplicated.

Another point is about containerization. One of the focal points of container technology is immutability and its impacts in terms of stability and the quality of the applications. You package one application into a container and easily move it between different environments. Of course, this is, not in the same direction as JEE servers, which have been engineered to host multiple applications, managing hot deploys and live changes of configurations.

A further consideration regarding application servers is that they are, by design, optimized for transaction throughput (often at the expense of startup times), and their runtime is general-purpose (including libraries covering many different use cases). Conversely, the cloud-native approach is usually aimed at a faster startup time and a runtime that is as small as possible, bringing only the features needed by that particular application. This will be the focus of our next section.

Introducing cloud-native Java

Since the inception of the microservices concept, in the Java development community, the paradigm has increasingly shifted toward the fat jar approach. This concept is nothing new, as the first examples of uber jars (a synonym of the fat jar) have been around since the early 2000s, mainly in the desktop development area. The idea around them is pretty simple: instead of using dynamic loading of libraries at runtime, let’s package them all together into an executable jar to simplify the distribution of our application. This is actually the opposite of the model of the application servers, which aim to create an environment as configurable as possible, supporting things such as hot deployment and the hot-swapping of libraries, privileging the uptime to immutability (and predictability).

In container-based and cloud-native applications, fat jar approaches have begun to be viewed as the perfect candidate for the implementation of cloud-native, microservices-oriented applications. This is for many different reasons:

• Testability: You can easily run and test the application in a local environment (it’s enough to have a compatible Java Virtual Machine or JVM). Moreover, if the interface is properly defined and documented, it’s easy to mock other components and simulate integration testing.
• Ease of installation: The handover of the application to ops groups (or to testers) is pretty easy. Usually, it’s enough to have the .jar file and configuration (normally, on a text file or environment variable).
• Stability across environments: Since everything is self-contained, it’s easy to avoid the works-on-my-machine effect. The development execution environment (usually, the developer machine) is designed pretty similarly to the production environment (aside from the configuration, which is usually well separated from the code, and of course, the external systems such as the databases). This behavior mirrors what is provided by containers, and it’s probably one of the most important reasons for the adoption of this approach in the development of microservices.

There is one last important consideration to pay attention to: curiously enough, the all-in-one fat jar approach, in contrast with what I’ve just said, is theoretically conflicting with the optimization provided by the containerization.

Indeed, one of the benefits provided by every container technology is layerization. Put simply, every container is composed by starting with a base image and just adding what’s needed. A pretty common scenario in the Java world is to create the application as a tower composed of the operating system plus the JVM plus dependencies plus the application artifact. Let’s take a glance at what this looks like in the following diagram. In gray, you will see the base image, which doesn’t change with a new release of the application. Indeed, a change to the application artifact means only redeploying the last layer on top of the underlying Base Image:

Figure 1.5 – Layering container images

As you can see in the preceding diagram, the release in this scenario is as light as simply replacing the Application Artifact layer (that is, the top layer).

By using the fat jar approach, you cannot implement this behavior. If you change something in your application but nothing in the dependencies, you have to rebuild the whole Fat JAR and put it on top of the JVM layer. You can observe what this look like in the following diagram:

Figure 1.6 – Layering container images and fat jars

In this scenario, the release includes all of the application dependencies, other than the application by itself.

While this might appear to be a trivial issue, it could mean hundreds of megabytes copied back and forth into your environment, impacting the development and release time since most of the things composing the container cannot be cached by the container runtime.

Some ecosystems do a bit of experimentation in the field of hollow jars to essentially replicate an approach similar to the application server. Here, the composed (fat) jar is split between the application layer and the dependencies layer in order to avoid having to repackage/move everything each time. However, this approach is far from being widespread.

The Java microservices ecosystem

One last consideration goes to the ecosystem in the Java microservices world. As we were beginning to mention earlier, the approach here is to delegate more things to the platform. The service itself becomes simpler, having only the dependency that is required (to reduce the size and the resource footprint) and focusing only on the business logic.

However, some of the features delegated to the application server are still required. The service registry, clustering, and configuration are the simplest examples that come to mind.

Additionally, other, newer needs start to emerge:

• HealthCheck is the first need. Since there is no application server to ensure your application is up and running, and the application is implemented as more than one running artifact, you will end up having to monitor every single microservice and possibly restarting it (or doing something different) if it becomes unhealthy.
• Visibility is another need. I might want to visualize the network of connections and dependencies, the traffic flowing between components, and more.
• Last but not least: resiliency. This is often translated as the circuit breaker even if it’s not the only pattern to help with that. If something in the chain of calls fails, you don’t want the failure to cascade.

So, as we will discover in the upcoming chapters, a new ecosystem will be needed to survive outside the JEE world.

Microservices has been a groundbreaking innovation in the world of software architectures, and it has started a whole new trend in the world of so-called cloud-native architectures (which is the main topic of this book). With this in mind, I cannot avoid mentioning another very promising paradigm: Serverless.

Serverless borrows some concepts from microservices, such as standardization and horizontal scaling, and takes it to the extreme, by relieving the developer of any responsibility outside the code itself and delegating aspects such as packaging and deployment to an underlying platform. Serverless, as a trend, has become popular as a proprietary technology on cloud platforms, but it is increasingly used in hybrid cloud scenarios.

Java is not famous in the serverless world. The need for compilation and the weight added by the JVM has, traditionally, been seen as a showstopper in the serverless world. However, as we will explore further in Chapter 9, Designing Cloud-Native Architectures, Java technology is now also gaining some momentum in that area.

And now, in order to better clarify different architectural designs, we will examine some examples based on a reference case study.

Following up on the handbook approach, each time we face a complex concept, I will try to clarify it by providing case studies. Of course, while the cases are not real (for reasons you can imagine), the challenges closely resemble several first-hand experiences I’ve incurred in my professional history.

In this section, we will start from scratch by designing a piece of software architecture. Then, we will add details to portray a more precise view. This will help you to better understand the first steps in the design of a complex piece of architecture.

Case study – mobile payments

In this case study, we will simulate the architecture design of a mobile payment solution. As contextual background, let’s suppose that a huge bank, in order to increase the service offering toward their customers and following some market research, wants to implement a mobile payment application. By definition, a mobile payment is a pretty broad term, and it includes many different use cases involving financial transactions completed using smartphones.

In this particular implementation, we will consider the use case of paying with your smartphone by charging you via your mobile phone bill.

Essentially, this means implementing a client-server architecture (with the clients implemented as a mobile application), interacting both with existing enterprise applications and external systems exposed by telecommunication operators. Now, let’s now try to analyze some use cases related to this scenario and model it by using the different schemas we’ve discussed so far.

Whiteboarding the overall architecture

Beginning on white space, let’s start whiteboarding the overall architecture. As we’ve learned, the first step is usually to sketch, at a high level, the relevant modules and the relationships between them. It’s not important to be super detailed, nor to use a particular style. We are just brainstorming the first shapes on paper:

Figure 1.7 – Architecture whiteboarding

Here, we have drafted a birds-eye view of the use case. We now know where the transaction starts, where the data is saved, and how the user interacts with the system.

Additionally, we have identified the main components of the application:

• The mobile application (represented together with the user)
• The (CDN) to serve static resources to the application
• The (CMS) to configure content to be delivered to the app
• The backend (mobile Backend as a Service or mBaaS) to proxy requests and responses
• The business logic of the application
• Session and Cache, to store non-persistent data of the users
• Database, to store persistent data
• Other parts of the application: reporting and data warehousing, authentication, Transactional Backend, and Customer Relationship Management (CRM)

As expected, this kind of design has some intrinsic issues:

• You can observe mixed-use cases (both of the mobile user and the CMS administrator), which can be foreseen by the arrows between different components, but it’s barely designed.
• There is a view in the project timeline regarding the implementation of components (reporting and data warehousing appear to be optional in the first phase of the project).

Some protocols in the interactions are named (for example, SOAP and REST), but it’s not an API specification, nor a network schema. Anyway, even if it’s not super detailed, this schema is a good starting point. It helps us to define the main application boundaries, it gives a high-level overview of the integration points, and overall, it’s a good way to kick off a more detailed analysis. We will improve on this in the next section.

In order to address some of the issues highlighted in the previous section, I’ve modeled the same system by focusing on software components. This does not follow any specific standard even if is pretty similar to the C4 approach (where C4 stands for Context, Containers, Components, and Code; we will discuss this further in later chapters):

Figure 1.8 – Software components diagram

As you can see, this schema is more homogeneous and better organized than the first sketch. At a first glance, you can view what features are provided to the user. Additionally, it highlights how the system interacts with each other in a structured way (for example, using API calls, reads and writes, and more).

Compared to the first sketch, there are some considerations that we can observe:

• The components are almost the same as the other schema.
• The diagram is less focused on the use case, even if the user is still represented (together with a high-level recap of the features available to them).
• There is no view on the project phases. This helps you to focus on just one point of view (architectural components), making the schema less confusing.
• No protocols are named, only high-level interactions (such as reads, writes, and API calls).
• Some technical components are preserved (the database), while others are skipped since they have less impact on the functional view (for example, the CDN, which is probably more relevant on a network schema).

In this section, we learned how to approach the first design of our mobile payments application; first, with a more naïve view, then by trying to detail the view in a more structured way. In the upcoming chapters, we will discuss how to further clarify and enrich those views.

In this first chapter, we just scratched the surface on the two most essential topics of this book: the different types of architectural design and the relevance of Java technology in the enterprise world.

We have discovered what the first sketches of our software architecture look like and why they are relevant, even if they are not very detailed. Then, we moved on to different schemas (such as software components, the infrastructure, and the network) to get a glimpse of other schema styles, which is useful to address specific areas of interest. On the Java side, we made some considerations about the role of Java in the enterprise landscape and how the language is evolving to meet the challenges of modern cloud environments.

These concepts will be useful starting points for the two core concepts of this book. On the architectural side, we’ve grasped how complex and important it is to view, analyze, and design a proper architecture. From a technological point of view, we’ve learned how Java, the technology we will focus on for the rest of this book, is very widespread in the enterprise context and how it is still relevant for building modern, cloud-native applications.

In the next chapter, we will start working with requirements. Requirement gathering and specifications are essential in order to rework our architectural design, adding more details and ensuring the final product will meet customer expectations.

• Who Needs an Architect? by Martin Fowler (http://files.catwell.info/misc/mirror/2003-martin-fowler-who-needs-an-architect.pdf)
• Don’t Put Fat Jars in Docker Images by Philipp Hauer (https://phauer.com/2019/no-fat-jar-in-docker-image)