Overview of Application Architecture and Moving Beyond Traditional Three‑Tier Assumptions

Application Architecture Overview

Although some details are not the latest, the methods and ideas remain useful, and the newest Gantner application‑architecture trends will be introduced later.

With the emergence of inter‑connected forces such as cloud, mobile, social and big data, organizations that do not leverage these forces will face serious business disadvantages in the future.

Architects should consider adapting to these new trends.

Use service‑oriented architecture (SOA), including micro‑services (MSA), to build applications and integrate internal COTS, legacy systems, partner applications and cloud services.

Leverage SOA to provide loosely‑coupled connections among applications and services with different budgets, schedules, requirements and owner priorities.

Use SOA’s separation of concerns and encapsulation to integrate mobile, social and cloud data sources with variable structured and unstructured data models.

Employ event‑driven architecture (EDA), the most critical form of loose coupling.

Ensure development work is more agile and incremental.

Consider open computing through open‑source products, open standards and open data.

Follow best practices and precedents of large‑scale sites; look for opportunities to use in‑memory computing and transaction processing based on eventual‑consistency models.

Below is a diagram showing the application‑architecture agenda.

Figure 1

Abandoning the Three‑Tier Architecture

The problem with the layered approach of three‑tier architecture is that it defines the application in only one dimension (Figure 2). All different data sources reside at the bottom, all UI logic at the top, and everything else in between, creating a linear, one‑dimensional view.

Figure 2

Today’s client applications must support a wide range of UI devices—PCs, netbooks, tablets, smartphones, kiosks, car dashboards, GPS devices and media players. The list keeps growing. These applications are often called by other systems such as social sites, partner applications, media‑company sites or internal mash‑ups (Figure 3). In this context, the notion of a single client program invoking business logic becomes odd.

Figure 3

We now have multiple dimensions on both the access side and the data‑management side of applications. Many new applications compose their business logic from one or more composite services, which in turn depend on multiple sub‑services. Sometimes these services run internally; other times the application must access partner or vendor services, possibly hosted in the cloud.

Figure 4

Given these observations about real‑world application complexity, we can summarize that a well‑described application architecture should assume many client programs and devices accessing many business‑logic services, which themselves may call other business‑logic services and multiple data‑access/management services.

Figure 5

Discarding Outdated Application‑Architecture Assumptions

Application designers have long based their designs on assumptions that now conflict with the new paradigms introduced by mobile, social, cloud and modern information management. It is necessary to abandon these assumptions to accommodate the inter‑connections of cloud, social, mobile and data.

Discard the assumption that applications depend on a homogeneous environment; design systems assuming they run in a highly dynamic, hybrid‑cloud infrastructure.

Discard the assumption that an application resides in a single location; build applications where processes and data can be distributed across multiple locations, with jurisdictional segmentation as part of the design.

Discard the assumption that databases enforce process integrity; instead, create applications that are integrity‑aware and manage business outcomes.

Discard the assumption that applications use only structured data; instead, applications must accommodate different media types and multiple data formats for similar purposes.

Discard the “record‑centric” pattern assumption; instead, design applications around interpersonal and social communication.

Adopting Application Paradigms and Models

The term “application architecture” refers to the structure and organization of an application, including its components and the interaction/dependency model among them. Application architects apply architectural paradigms and use common patterns and models to design applications and define their architecture.

The most directly affected application attributes include:

Maintainability

Robustness

Versatility

Usability

Longevity

To better understand how to use application architecture to deliver these qualities, it helps to consider three architectural components:

Paradigm

Model

Structure and Organization

Paradigm

An architectural paradigm (sometimes called an architectural style) is an overall conceptual framework that influences how you design an application. A paradigm helps ensure the application exhibits the characteristics that best meet the owner’s goals.

Model

A model is an abstract description and symbolic specification of certain aspects of the real world. By abstracting complexity into a high‑level representation of the most visible system aspects, models help people understand complex systems. Designers, developers and stakeholders then create increasingly detailed models to better understand component functionality, non‑functional attributes and inter‑dependencies.

Solution architects model four related aspects of a system:

Business capability model – what the organization needs to be able to do.

Business process model – how the organization accomplishes tasks.

Information model – the information the organization uses, processes or creates.

Service model – the software components that perform work.

Structure and Organization

The architecture of an application is reflected in the structure and organization of its implementation. These architectural traits affect performance, scalability, robustness, flexibility, maintainability and total cost of ownership.

To assess the quality of an application’s architecture, consider the following aspects of its structure and organization:

Decomposition and granularity of services and composites.

Topology used to define and describe the solution.

Inter‑dependencies among solution components.

Interface specifications and contracts.

Frameworks defined or leveraged.

Implementation details.

Thank you for following, sharing, liking and viewing.