Case studies and examples

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.