Modern Applications — Reference Architecture

Overview

Conventional methods to build and manage applications are no longer sufficient to meet contemporary business needs, making it impossible for businesses to succeed in the digital era. There comes Modern Applications, making the impossible possible, where speed meets with stability, innovation and efficiency go hand in hand, security and compliance are taken care of from the design stages, designing for operations is not an afterthought, teams strive to deliver value from the go, and the list can go on. Conventional apps are not simple but easy to create and manage. Whereas modern apps are simple but not easy to create and manage. Practitioners and stakeholders need to have a broader view while adopting modern applications. In this series of articles, I would like to highlight some of the important aspects of modern apps so that practitioners and stakeholders can strive for a lasting impact on their efforts.

Background

Before jumping to what modern applications are about, let us understand where they are used. The modern world around us is very complex, and demanding and comes with its own challenges and expectations. We all want to have rich experience with goods and services that we consume, with access to information about the same wherever we are, almost near real-time so that we are current with what’s going on and take informed decisions or actions. Few examples of the same…

As a consumer, we want to have a seamless digital experience about a good or service from the initial inquiry till the time we stop consuming it. We provide the feedback and expect that it is acted upon quickly.

As an enterprise, we want to respond to market dynamics and customer expectations at speed keeping the risks and costs low.

As a business leader, we want to leverage technology (IoT, cloud, ML/AI, chatbots, Metaverse, etc.) to be competitive and provide enriching experiences to customers.

As a developer, we want to build and ship products at speed with needed stability.

As a site reliability engineer, we want to have quick access to logs to troubleshoot a problem, and keep the system up and performing.

As an auditor, we want to see security violations to take necessary actions.

As a regulator, we want to have insights about a service to check that is in line with regulations.

and the list goes on …

Definition

Modern applications try to address the experience mentioned in the above examples for multiple user types, in a way that is economical and beneficial to all the stakeholders. It is a combination of modern technology, architectures, methods, software delivery practices, and operational processes that help teams and practitioners to deliver value more frequently, consistently, and safely at speed. These applications take the advantage of technology that allows the teams to offload the heavy lifting needed to develop and run so that they can have more time for delivering customer value.

Typical characteristics of a modern application include

• Speed/Agility — The app is developed/changed through small iterations and deployed frequently using CI/CD pipelines. Implies higher code pushes and higher velocity.
• Scalability — The app seamlessly scales up or down to accommodate the usage spikes during peak and off-peak times, from around the world.
• Portability — The app is easily deployable on different types of infrastructure; public cloud, private cloud, hybrid cloud, and on-premise.
• Resiliency — The app can elegantly fail over to the new computing resources spun up in new availability regions in cloud or data centers.
• Reduced risks and total cost of ownership — The app is built and run leveraging cloud, open technology, loosely coupled architecture, security best practices, and operations and security tooling so that risks and cost of ownership are minimal.

How they differ from conventional ones

A typical modern app is more like a buffet, comes with several things together and to be adopted together. When compared to a traditional app, modern app differs in many ways starting with the very context they are executed.

Objective

• Traditional App (TA)— Output/ urgency driven, generally carry short term view
• Modern App (MA) — Value/ outcome driven, generally carry a long term view while addressing short-term needs

Decision Making

• TA — Business centered
• MA — User/ customer centered

Execution

• TA — Project mode, mainly governed for delivery predictability and fixed scope
• MA — Product mode, mainly governed for value delivered to customers and the ability to respond to the needs

SDLC

• TA — Waterfall/ big bang development with very late/ no feedback loops from users
• MA — Agile/iterative development with early/ frequent feedback loops from users

Functional Scoping

• TA — Project context, possibility of multiple sources of truth, duplication of capabilities/ functionality
• MA — Capability-driven bounded context, domain-driven design, single source of truth, less duplication of capabilities

Architecture

• TA — Typically monoliths, with difficulty to change in isolation and scale up/ down
• MA — Typically micro-services/ distributed systems architecture. with the ability to scale up/ down quickly

Security

• TA — Security is usually an afterthought, addressed reactively and driven by the Information Security team
• MA — Designing for security is usually considered from the requirements stage following the shift left strategy. Defense in depth, and the principle of least privileges honored greatly

Operational Aspects

• TA — Designing for operations is usually an afterthought, and considered late when the app is handed over to the operations team
• MA — Designing for operations is usually considered from the requirements stage following the shift left strategy. Observability and monitoring are core to modern apps to address their distributed nature.

Technical Debt

• TA — Usually addressed reactively, prioritized only when it breaks the service
• MA — Usually addressed proactively, prioritized continuously

Culture

• TA — Passive, Center of excellence
• MA — Active, Communities of practice

Software Delivery

• TA — Organized for stability, a fixed number of releases in a year, scattered adoption of CI/CD, no or limited test automation, no or limited code maintainability measures, no or limited tracking of software delivery performance
• MA — Organized for speed and stability, on-demand/ very frequent releases, self-service app delivery, CI/CD, test automation, code maintainability, adherence to DORA (DevOps Research & Assessment) metrics maturity

Team Topology

• TA — Siloed teams for development, operations, and support
• MA — Promotes DevOps culture. Usually same team is responsible for dev and ops at the application level, while the platform team manages the infrastructure

Self serviceability

• TA — No or limited self-serviceability.
• MA — Higher levels of self-serviceability are at the core of modern apps, from requirements to solution architecture, from the use of development tools to using platform model for infra provisioning & DevSecOps, and self-service portals for developers & users.

Values, Principles, Laws

• TA — Function-driven and siloed values & principles, Lack of alignment and agility with changing business priorities.
• MA — CAP Theorem, Conway’s law, Scout24 engineering values, and principles.

Reference architecture

Micro-Services, Self-Contained System (SCS)

Modern applications are better with micro-services (loosely coupled) architecture. Self-Contained System (SCS) (https://scs-architecture.org/) is one such productive notion of a micro-services architecture that makes a good unit of software for a team to work on. One or few cohesive SCSs typically make a business capability. Such cohesive sets of SCSs together make a business process.

Design for operations, Containerisation

Designing for security, scale, resiliency, and operations is no more an afterthought for teams developing apps. Shifting all of them to left in the SDLC process is ideal for achieving greater productivity for the team. Combining SCS with container technology underpins the portability, scalability, and resiliency needed by modern apps.

Integration middleware

Integration middleware plays a significant role in modern app architecture allowing Self Contained Systems (SCSs) to interact with each other for fulfilling overarching user journeys. SCSs can minimize the coupling to others by integrating over their UI layer. Therefore simple hyperlinks, redirection, and dynamic inclusion of content can be used to navigate between SCSs, in both directions. To further minimize the coupling to other systems, SCSs should avoid synchronous remote calls in the business logic. Instead asynchronous communication should be used to reduce dependencies and prevent error cascades.

Tooling

Modern apps require tools, typically managed centrally within a portfolio or program, for the smooth functioning of the app in operations. These tools typically provide an environment to troubleshoot problems in a quick time, monitor the performance of the apps, and alert stakeholders when things don’t go as expected. These tools are offered in product mode so that the enabling team always prioritizes and course corrects their work towards the value and outcome the individual app teams are intended to create.

Security

Modern apps need a defense-in-depth security strategy to reduce vulnerabilities, contain threats, and mitigate risks. If a bad actor breaches one layer of defense, he/she might be contained by the next layer of defense. Identity and Access Management (IAM), network security, intrusion detection and prevention, patch management, endpoint security, multi-factor authentication, and key management are some notable security solutions that should be part of the architecture.

Conclusion

The adoption of modern applications requires a broader view and understanding of many aspects surrounding their creation and running. In the article I have attempted to highlight a bit about its background, definition, how they differ from the conventional ones, and the reference architecture. In the following article, I will focus on functional scoping and execution aspects. Looking forward to publishing the next article soon.