_Airline Rewards App: Mapping requirements to architecture for application migration and modernization

In this article, the first one in the series about Application Migration and Modernization topic, I’ll walk you through the design steps, technical choices, and some caveats and expectations of application migration to the public cloud, which involves a significant cloud migration strategy and application modernization plan, and some of the trade-offs and issues associated with this approach.

Introduction

I will demonstrate this process based on the existing business goals, the characteristics of the architecture, and the functional and non-functional goals the architecture must meet. Particular emphasis will be placed on cloud migration and application modernization that goes well beyond traditional lift and shift approaches. And it goes even beyond standard cloud migration and application modernization patterns, including lift and shift and PaaS cloud migration process.

While the article is heavily focused on technical performance, it will also make assumptions about business factors, which will be discussed in the following article in the series about Application Migration and Modernization. To make the piece more attractive, I use a real-life example.

Architectural considerations for an Airline Rewards application modernization

The application covered here and used as an example is an airline rewards and loyalty application. Its current form consists of a few simple web pages that allow users to see past flights, acquired miles, segments, current reward status, and benefits and to manage simple profile information such as name and address. Airline employees can drive employee and customer accounts, edit miles and segment history, and finally, the application provides a redemption store. The application is only accessible via web pages; no mobile application exists.

The airline has a grand vision of massively expanding this project, including:

• the ability to show upcoming flights,
• an option to cancel and book flights via rewards,
• integration with partner airlines,
• a mobile application, the desire to integrate email and SMS notifications,
• the ability to manage payment information,
• the statistics around travel history,
• the ability to gamify flight history and upgrade requests.

From our previous session, we can make some assumptions about our vision. We are taking a monolithic application and migrating it to a microservices serverless platform from an older monolithic platform to solve a number of considerations as described below. Though there is nothing inherently wrong with the monolithic application as it stands today, there are requirements better met by the new architecture. As the application is due for a significant number of feature additions, the timing is good to make these changes.

Challenges with monolithic architecture: complexity and scalability of cloud migration process

The existing architecture utilizes an arguably modern monolithic approach, an MVC (model view-control) framework, and a simple database back end. Though there is nothing wrong with that approach, it does require that any changes to any services be well understood by the majority of the development team. As they roll out more migration services and new feature additions, the team size will expand to help maintain those additions. The number of features and the internal complexity of each has and will continue to grow beyond the capacity of any one individual to understand, facilitating the need for a non-monolithic model completely.
The below diagram represents the existing architecture at a high level. Note that there is considerably more complexity within the code base if the individual URL paths and API entry points were to be mapped out, along with the various framework interactions and dependencies. For brevity, we will exclude these frames from the existing application but will showcase them in later articles.
The architecture is simple: two primary virtual machines running in an HA (highly available) pair, with a traffic load balancer between them. No session sharing is enabled so that active sessions would lose information in flight, and hotspots (“unbalanceness”) could occur in a cloud environment.

Figure 1: HLD (High-Level Architecture Diagram) of existing application

Capturing technical and business requirements for a complex User Management System

From our previous discovery steps we can categorize several captured requirements. Some of these may be technical in nature, and some of these may be business motivations. Together these will define our future solution and proposed architecture.
Given the nature of the application, there are numerous persona’s that need to be dealt with, which include significantly different permissions and views of the application. Although some of these can be grouped together in terms of general permissions – eg, customers/family groups, all agents, benefits employees and administrators, each will require its own complex permission handling and views. This will require a complex user management system capable of defining such roles and access policies.

Table 1: Users Personas & Cohorts

Technical requirements and feature characteristics for Airline Platform

The platform requirements for a new application involve several key features that are essential for modern cloud platform and its success:

• the platform must allow for fast prototyping and deployment of new page functionality
• the platform must allow for duplicating behavior between web and mobile applications without complete rewrites
• all pages must be API driven and able to load data from multiple internal and external sources
• updates to one API platform (eg, flight bookings) should be possible without affecting teams working in other areas (eg, benefits)
• the platform must utilize off-the-shelf solutions for common denominator features (eg, user management, page rendering, API’s) where appropriate, in order to cut down on developer burden, and maintenance
• there does not need to be a shared repository of data; communications between features (eg, bookings vs. rewards) will be via API’s, not direct access
• the platform must have the ability to easily send SMS and email notifications, as well as application push notifications (eg, flight rescheduled)
• the platform must be designed with the ability to store and utilize credit card information, and the associated PCI compliance impact
• the platform must support robust business intelligence and statistic visualizations
• allow for complex data lifecycle management rules, as data must be available to different personas and for different regulatory purposes at different time intervals but will ultimately be archived
• the platform must support functionality wise for passengers:
  • • ability to sign up for the rewards and booking platform
    • search for, book, modify, cancel, and display upcoming flights, including changing dates, fare class, and routing
    • display rewards, utilize or redeem rewards, convert rewards from partner airlines, receive rewards from partner airlines, and recognize bookings with partner airlines
    • Integration with partner airlines to send booking and reward utilization information, including sharing code-share, co-marketing, and split segments between partner airlines
    • track baggage, ideally via airport codes, mapping, and optional geolocator tags with 4g/5g enabled chips
    • allow users to manage profile information, linked accounts/family plans, billing information, discounts, and other relevant airline and rewards information
    • allow the platform to provide incentivized gaming travel, including geocache games within and around airports to select destinations, QR code “capture the flag” games, leader boards, and prizes
    • allow airline passengers to see progress in reward status, as well as statistics
• the platform must support various agent and reward employee functionality including the ability to:
  • • search, manage, and modify bookings, as well as all route, seating, cabin, and other information on a relevant booking/ticket/PNR
    • merge profiles, bookings, PNR’s, and other requests by passengers
    • reset, reclaim, create, and manually register passengers
    • take all user actions against a specific booking
    • provide discounts, refunds, and override booking costs
    • manage reward items and availability
• Administrators must have the ability to manage users and role assignments, as well as signup agents and employees of all types.

Hard Platform requirements:

• End-Use Ease of Use
• mobile functionality
• the ability to allow development teams to extend functionality on specific site features
• reducing complexity for development teams
• integration of 3rd party API’s

Philosophy of choosing characteristics for cloud migration and modernization

It’s important to understand and accept that you cannot solve all potential problems in one solution, at least not as primary drivers. Solutions need to cater firstly to a core set of principles that drive the discussion and overall design, after which individual components can be tweaked. There are
an endless number of ways to evaluate how to select this criterion and what those architectures may contain in terms of characteristics. In this article, we’ve focused on utilizing Mark Richard’s. Architectural characteristics, customizing the characteristics to our own specific use cases.

The intent of this exercise is to pick the most business-critical architectures as previously identified and then work to solve those as best we can given the trade-offs between technology choices in our
base architectural design.

Chosen architectural characteristics

a. Evolvability
Given the ever-present evolving nature of customer behavior and expectations, along with the uncertainty around travel, travel restrictions, and providing incentives to users, not to mention the ecosystem of partnerships this application must interoperate with, evolvability will be a primary consideration for this platform.

b. Servability
The platform must lend itself to a wide range of potential audiences, from both a technology standpoint (e.g., older devices, modern phones, and archaic API’s), through to languages, currencies, and users with disabilities. An API must drive any interface if a new consumption model arises. Ideally, any presentation layers must be completely abstracted to facilitate easier transitions existing applications to any display or technology need. The product extends the range of profiles, from extremely technically knowledgeable to extremely limited tech-savviness, and must therefore be simple enough to operate while providing advanced functionality for power users and frequent flyers.

c. Data security
The system handles and processes a significant amount of PII (personally identifiable information) of airline customers. From booking information, KTN’s (known traveler numbers), redress numbers, passport ID’s, and credit card information, the system is ripe for financial and identity theft. There are significant burdens and risks around cyberattacks, impersonation, bad actor employees, and simple data corruption that could have an extremely adverse impact on a customers’ life. Ensuring the security and integrity of the data center will be an overarching non-negotiable characteristic.

Secondary considerations for cloud migration and modernization

Though not primary considerations, we must consider that there are minimum thresholds for some interactions. As such, we’ve documented use cases that are not primary motivation decisions but, where possible and appropriate, should be accommodated.

a. Responsiveness
Since the application is user-facing, it must be responsive to user input. These include quick acknowledgments of long-running interactions (eg, flight searches for complex itineraries.) There is no expectation that requests must be fulfilled within the Doherty Threshold of 400ms, but all requests must show some action taking place far below that threshold.

b. Cost feasibility
Direct costs and the indirect costs of velocity are both motivating factors. The product has a budget and time constraints, but they are just that, constraints, not the primary motivation. A solution that costs more or takes longer for a better experience or faster development velocity later is an acceptable trade-off.

Proposed Solution Architecture: Base-level

The proposed solution below has a brief description, and more detail will follow in subsequent articles that lay out the various compromises and full descriptions of the components. Build upon this base architecture, adding components and detail as required for a fully fleshed-out solution.

For a base-level architecture, the design process focused primarily on finding a suitable platform that was microservices serverless based, as this would allow us to pick both modern components including SaaS (software as a service), PaaS (platform as a service), and DBaaS (database as a service) components at will, as we desired. This architecture could be optionally extended to support any number of different software components, from traditional VM’s (virtual machines) and containers to 3rd party API’s, and other serverless services without our chosen cloud provider – in this case AWS. A microservices serverless platform is strictly speaking borrowing from multiple architecture styles, but it suits this specific set of problem criteria well.

Proposed Solution Architecture: Initial component choices

The initial component choices allow for a very fast prototype and development, with a highly pluggable application that allows different teams considerable autonomy from one another when developing features.

Additionally, the use of amplify with Cognito also allows for the following:

• handling a significant number of overhead common denominator tasks, such as user and session handling,
• authentication, role mappings, and numerous other overheads that get wrapped up into a neat package for quick deployment,
• quicker facilitation of development cycles, increasing velocity, and decreasing human costs.

Additionally, the platform is both web and mobile friendly by default. The ability to quickly create multiple views and interfaces with content also solves a number of issues related to servability, including ADL (activities of daily living) interfaces for people with disabilities, including pages that are friendly to screen readers and other assistive products. Finally, the platform is very user-friendly, supporting multiple notification paths, including SMS in multiple countries, and allows users to authenticate with their preferred identity provider they already recognize, while travel agents and internal employees can make use of SAML and OpenID.

Proposed Solution Architecture: Resilience and security of the components & future directions

The components chosen are all:

• highly resilient and support multiple ways to vet and verify data integrity and access to data,
• have the capability to log and audit access, code, and data changes, as well as individual API and data accesses,
•  are secure by default, building on an existing trusted ecosystem supported by AWS and vetted via thousands of production installations. Coincidentally the cost footprint of this architecture can be relatively low, and it lends itself well to fast responsiveness.

We’ll talk more about the individual services in a future article in this series including the specific advantages and disadvantages of each in a number of important categories both from a development and operational perspective and how best to mitigate risks and shortcomings with each. This is by no means a complete architecture, and the components here today do not fulfill all requirements. It does provide a solid base upon which to build, however.

Figure 2: HLD (High-Level Architecture Diagram)

Note: A detailed breakout of the components and a styles mapping from the HLD will be provided in a follow on article.

Acknowledgments to:

• Mark Richards for resource references
• Neal Ford for inspired writing
• Marc Boudreau for knowledge and references
• Scott Lew for knowledge and sounding board
• Samira Barouti for knowledge and details

What’s next? Breaking down the Application Migration and Modernization journey: a comprehensive series

There is a lot to tackle along the application migration and modernization journey, from concept discussions to a full application plan, and they don’t all happen at once. Though not every application will require the full depth we dive into here, some will, and every application will use some bits and pieces from our methods presented here. As such, we’ll step through the journey using a series of articles so readers can pick and choose the topics most relevant and decide which bits to follow and which to discard. Putting them all into one article would produce a short book and still be incomplete.

1. Discovery & gathering business requirements (prequel: coming next)
2. Mapping captured requirements and existing solution to a high-level architecture (covered in this article)
3. Design processes, sequence, UX workflows & UI Wireframes
4. Design a coherent deployment process
5. Create C4 diagrams (System Context, Container diagrams)
6. Bolt-on Reporting & Business Intelligence (BI)
7. Identify Risks and Migrations (business & technical)
8. Create Architectural Decision Records (ADRs), discuss trade-offs, and gather feedback on decisions
9. Cost of Ownership breakdown (Implementation, ongoing operational, ongoing infrastructure & cloud, security, and risk costs)
10. Define common project definitions and glossary
11. Creation of project backlog (Milestones, Epics, non-functional information capture)
12. Operational and ongoing management considerations
13. A complete project ready-to-go project pseudo (GitHub repository)