Which Application Architecture to Choose

Luc Bories

January 5, 2021 - 6 minutes read - 1257 words

Choosing an Application Architecture is a pivotal decision impacting team structure, workflows, technology choices, skill requirements, and interactions with internal users, clients, and partners. So, which application architecture in 2021?

Preface

This article focuses not on technology vendors or platforms but on architectural choices. Given the multitude of technical solutions across diverse scenarios, covering them all in one piece is impossible. Future posts will address specific technologies, which are equally important.

We’ll refer to “enterprises” for simplicity, but this applies equally to government organizations, non-profits, educational institutions, and any legal entity conducting activities.

Before selecting the application architecture best suited to your project and organization, you must clearly define your starting assumptions. That’s the goal of this article. Let’s explore the essential points for defining your Application Architecture.

Defining an Application’s Scope

First, understand what an application truly is—more than just code. A well-defined Application Architecture must encompass business requirements, domain rules, security, compliance, data management, performance, resilience, legacy integrations, user and partner interactions, roadmap alignment, and Enterprise Architecture directives.

Ask yourself: who will use our application?

Application Boundaries

Begin by mapping the application’s scope: internal users, customers, partners, and suppliers. What is the purpose? Serving a small internal team or providing a service to millions online?

These cases demand different approaches:

A purely internal application for a team, department, site, country, or region
An application for partners, suppliers, or distributors
A public application for a small or very large audience across one or multiple countries

User type influences security, privacy, and regulatory requirements. User location determines the need for specific optimization and availability strategies.

Interaction modes also drive architectural choices:

Web interface
Desktop client
Data exchange (files, web services, messages, APIs)
Mobile or tablet client
Automated systems (ATMs, factory robots)

Reaching a broad user base typically favors web or mobile interfaces, which tend to be simpler and more cost-effective than bespoke desktop solutions.

Business Requirements

Exhaustively cataloging business requirements is challenging. Listing required features and domain rules is never straightforward. Migrating or rewriting an existing application can be even harder.

Some systems have decades of history with undocumented functionality. You may need to dive into code to extract and adapt legacy business rules.

Additionally, every organization faces legal, contractual, and privacy constraints based on its industry. Data sensitivity affects compliance rules and the tools you choose. Even terminology can be domain-specific.

Key deliverables include:

Enterprise Architecture guidelines for defining and implementing the Application Architecture
Application roadmaps to inform architectural decisions and timelines
Business rules describing required behaviors for actions and processes
Validation rules detailing data-checking logic
Feature specifications outlining expected functional blocks
Business processes or use cases specifying application behavior
Component maps decomposing the application into functional modules

Application Architecture Budget

In an ideal world, business needs are reviewed holistically, then:

Define an Enterprise or Application Architecture blueprint.
Make architecture choices for each application or component.
Estimate budgets.
Launch projects.

In reality, individual business needs often arrive with fixed budgets. You then design an Application Architecture constrained by legacy systems and available funds. This compromise approach can yield an IT landscape of disparate apps requiring extensive integration.

Another scenario is breaking a large monolith into multiple collaborating applications. Functional slices, budgets, and team availability drive the decomposition. Without a strong, shared framework, divergent methods, technologies, and integrations emerge—resulting in unforeseen integration costs and complexity.

Once architecture decisions, processes, and methodologies are in place, consider their impact on your organization’s daily operations.

Choosing an Application Architecture is a pivotal decision that influences team organization, work methods, technology choices, required skills, and interactions with internal users, clients, and partners. So, which application architecture in 2021?

Impacts of Application Architecture Choices

Architectural decisions have far-reaching effects across multiple domains of the organization, not just at the application layer:

Existing systems must adapt. Rarely is an application fully autonomous—numerous integrations between systems are usually required.
Competencies need to be developed or acquired.
Methodologies must be communicated and enforced.
New vendors must be selected and existing contracts renegotiated.
Partners must be informed—or even involved—if they need to adapt.
Internal teams, end users, and IT staff must change habits or undergo training.
Integration between application modules, between distinct applications, or with external vendors and partners needs to be built or modified.
Annual budgets must be adjusted to account for technological and organizational changes.
Roadmaps must be synchronized: you can’t always overhaul one application while making significant changes to another simultaneously.

Having surveyed needs, budgets, and impacts, let’s turn to the practical factors that will guide your answer to “which Application Architecture in 2021?” We’ll start with the type of application.

Choosing the Application Type

Deciding on the type of application—on-premise packaged software, SaaS, in-house development, cloud-native, or hybrid—requires weighing:

Immediate and future business requirements (functional scope)
Projected processing load and user volume
Enterprise Architecture targets and strategic guidelines
Existing infrastructure, hosting, vendors, contracts, applications, skills, organizational setup, and commercial timelines
Available and forecasted financial resources
Expected return on investment
Economic, health, political, and regulatory environment considerations

With these factors in mind, you can identify which delivery model best fits your organization’s objectives and constraints.

Frontend Options

The application’s user interface often garners the most attention, even though the backend logic is equally vital. Organizations must balance cost, technology/vendor longevity, up-to-date UX expectations, security, and integration ease.

Common frontend choices include:

Web (HTML + JavaScript pages)
Web single-page apps (pure JavaScript frameworks)
Server-rendered web pages (HTML generated dynamically by the backend)
3270 terminal screens (mainframe)
Desktop Java clients
Native desktop (C, C++, C#…)
Desktop web wrappers (Electron…)
Mobile and tablet (iOS, Android)
Consumer kiosks (bank ATMs, ticketing machines)
Industrial controllers (factory robots, machine tools)
None—data exchange only (files, services, APIs)

In many cases, business requirements will quickly narrow the choices to a handful of suitable interfaces.

Backend Options

Behind the scenes, your application could take several architectural shapes and hosting models:

Monolithic
3-tier: frontend / backend / database
n-tier: highly distributed services
Serverless: no dedicated servers; functions and managed APIs run in the cloud
Microservices: independent, domain-focused services communicating via APIs, messages, or web services

Each component can be a commercial off-the-shelf package, custom in-house code, or a hybrid of both. Hosting may be on-premises, in the cloud, in a hybrid setup, or through SaaS offerings.

Data management is another key consideration: how to organize, store, back up, archive, query, and aggregate information. Business requirements—transaction volume, processing frequency, security and resilience needs, frontend choice, and user distribution—will drive the data architecture. Company culture, budget, forecasts, and team expertise will finalize the decision.

Integration Options

Applications seldom operate in isolation. They frequently exchange data with internal or external systems. Integration architecture choices determine capabilities, performance, security, and deployment speed.

No single integration technology covers all scenarios. You must inventory each data flow and assess:

Source and destination systems
Synchronous versus asynchronous exchange
Frequency and volume of messages
Data types and formats
Retry and error-recovery requirements
Acceptable latency between send and receive
Transactional integrity needs
Orchestration of multi-step workflows
Data transformation, mapping, and protocol bridging

Answering these questions guides you to the right integration patterns and technologies.

Conclusion

Choosing “which Application Architecture in 2021” means considering every factor above. Resist the urge to over-emphasize familiar aspects—like technology stacks or user interfaces—at the expense of equally essential elements. An Application Architecture only makes sense when viewed holistically within its ecosystem.

In large organizations, governance frameworks often constrain architectural freedom. But in mid-sized or smaller enterprises, you still have the flexibility to define comprehensive requirements and make the right strategic choices. Now it’s your turn to act!