Decouple Your Web Architecture for Robust Java Applications

A company rarely, if ever, modifies the architecture of an application just because it’s the right thing to do. There is usually some underlying reason, and that reason is a business opportunity.

In this chapter, we’ll begin the process of architecture modification. We’ll do so by looking first at the new business opportunity presented and the corresponding architecture needs. Then we’ll examine other opportunities that can leverage our new architecture. Finally, we’ll express these opportunities as user stories.

Knowing how to evaluate business opportunities is what separates a programmer and a software engineer. Engineering takes into account the business side of application development, more than just making code work. That is why architecture is a key component of the process. Good architecture can more easily adapt to change, be tested, and be understood.

Examine Business Opportunities

The airline wants to expand its services. There is an opportunity to support the tour group’s request to book adventure holidays regularly. How do we go about updating the application to meet these needs?

We’ll begin by looking at the new functionality. Each new feature will be captured in a user story. We’ll write down as many stories as the airline wants features. Later, we will revisit the stories in detail to determine what needs to be architected and programmed.

Our first user story being added is:

As a tour group leader, I want to book a flight of up to 12 people so that they can experience someplace unique.

As indicated in the last chapter, there is no functionality to support this. The tour guide would have to tell the person behind the desk at the airport the details of their desired trip.

We could dive in and try to wedge in this functionality into the existing architecture. But we’ve agreed that’s a bad (monolithic) strategy. But converting to a decoupled web application should gain the company a significant payback on investment. Not just for the one new user story, but for the anticipated additional functionality. Since we’re going to be looking at modifying the architecture to better support a larger airline operation, let’s take a look at other ideas the airline has for additional functionality.

Ask yourself, "Where can the company make, or save, more money?" Let’s look at how the airline can be better served with a change in architecture. We can start by asking some questions (I've provided the specific answers for our scenario):

• What user-based issues currently exist?
  Currently, only a single user at a single location can use the application. The airline wants the application to be accessible from many locations, by many people, all at the same time. Converting to a web application will solve these issues.

• What data-centric issues currently exist? 
  The database stores just enough information for the application to book flights. The query mechanism is geared to only this functionality. There is very little ability to perform any analytics, so the airline is unable to offer specials for frequent travelers, or track late and early departures and arrivals.  For example, the current system displays a list of all of Dairy Air's clients, along with information about them, including how much they currently owe. We would like to see a list of only those who have an outstanding balance.

• What business processes contain non-electronic (paper, or worse, vocal) steps?

  • Pilots currently enter flight notes and maintenance requests via printed forms. With a decoupled architecture, this data could be entered via a mobile application while the pilot is performing a pre or post-flight walk around.

  • Mechanics make modifications to the aircraft, and, similar to the pilots, capture these changes on paper reports. It would be great if they could relate their changes real time.

• What analysis can be performed to prevent issues from happening before they occur?

  Parts purchase and installation dates can be entered. A smart analytics system can determine which parts are nearing their replacement dates, and which can be ordered “just in time,” instead of after they have broken. Airplanes on the ground, do not make money.

As you can see, there are plenty of opportunities to take advantage of a new architecture. Some solutions could be:

1. Convert to a web application, which will give us much more flexibility than the single desktop application.

2. Analytics can be introduced to offer specials, track late and early departures, and arrivals. The current database has no way of storing or querying this information.

3. Allow pilots to enter flight notes and maintenance requests (currently a paper process), possibly through a mobile application that they can use while giving an airplane a pre or post-flight walk-around.

4. Keep more advanced maintenance records (another paper process) that could be used to purchase parts when they are nearing replacement, instead of after they are broken, requiring the airplane to sit idle while waiting for the part to arrive.

Not all of these opportunities need to be put in place immediately. But knowing these opportunities exist gives us better justification for switching to the decoupled architecture.

We could burn the original application to the ground and start over. 🔥 But the company is still up and running. Plus, we know the code works and does what is expected. We want to integrate these changes over time. It allows the airline to continue operations as we are working. Also, we can get feedback from the airline employees along the way, about how features should work. That way, they don’t have to learn an entirely new system overnight.

Define Our User Stories

So far, we’ve created a user story for the first situation in our list above:

We’ll be focusing on two additional user stories to work on: the ones that correspond to the situations listed under the questions "What business processes contain non-electronic (paper, or worse, vocal) steps?" in our list above. There are many others, but since we will be coding and you have to get some sleep once in a while, we’ll just stick to two more. 😉  Try to work out the user stories yourself before checking my answer below: 

Both of these stories, plus the tour guide story, involve the user-based, data-centric, and paper- based processes questions we posed above.

There is one other user story that we will look at to illustrate how easy it is to implement AFTER we have our architecture in place (in the data-centric section): 

Let's Recap! 

• Avoid the temptation to code a feature into the current monolithic application. See where a decoupled architecture could be used instead.

• When adding a new feature (user story), look for additional business opportunities (user stories).  This justifies changing to a decoupled architecture. 

Now that we have our user stories, let's break them down and define the new entities we need in our application!