Overview of Application Architecture and Emerging Trends

This article discusses contemporary application architecture trends, noting that organizations that do not leverage cloud, mobile, social, and big data forces will face significant business disadvantages.

Application Architecture Overview

Architects should consider adapting to these new trends.

Use Service‑Oriented Architecture (SOA), including Micro‑Service Architecture (MSA), to build applications and integrate commercial off‑the‑shelf (COTS) systems, legacy applications, partner applications, and cloud services.

Leverage SOA to provide loosely‑coupled connections between applications and services with differing budgets, schedules, requirements, and ownership 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 becomes more agile and incremental.

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

Follow best practices from large‑scale websites and look for opportunities to use in‑memory computing and transaction processing based on eventual‑consistency models.

Below is a chart showing the application architecture agenda.

Figure 1

Moving Beyond Three‑Tier Architecture

The layered approach of three‑tier architecture defines applications in only one dimension: data sources at the bottom, UI logic at the top, and everything else in between, which is overly simplistic.

Figure 2

Today's client applications must support a wide range of UI devices—including PCs, netbooks, tablets, smartphones, kiosks, automotive dashboards, GPS devices, and media players—and often need to integrate with social sites, partner applications, media company sites, and internal mash‑ups.

Figure 3

We now have multiple dimensions on both the access side and the data‑management side of applications. Business logic is often composed of one or more composite services that rely on multiple sub‑services, which may be internal or external (partner, vendor, or cloud‑hosted).

Figure 4

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

Figure 5

Abandoning Outdated Application Architecture Assumptions

Designers have long based applications on assumptions that conflict with the new paradigms introduced by mobile, social, cloud, and modern information management. It is necessary to discard these assumptions to accommodate the interplay of cloud, social, mobile, and data forces.

Discard the assumption that applications may rely on a homogeneous environment; design for highly dynamic, hybrid‑cloud infrastructures.

Discard the assumption that applications reside in a single location; design processes and data to be distributed across multiple locations.

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, accommodate multiple media types and data formats for similar purposes.

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

Adopting Application Patterns 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 patterns and use common patterns and models to design applications and define their architecture.

The most directly affected application characteristics include

Maintainability

Robustness

Versatility

Usability

Longevity

To better understand how to use application architecture to deliver applications with these characteristics, consider three components of architecture:

Paradigm

Model

Structure and Organization

Pattern

An architectural pattern (sometimes called a style) is a high‑level conceptual framework that influences how you design an application. A pattern helps ensure the application exhibits the qualities 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 aspects of a system, models help people understand complex systems. Designers, developers, and stakeholders create increasingly detailed models as they drill down into finer‑grained system aspects, improving understanding of component functional and non‑functional behavior 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 the work.

Structure and Organization

An application’s architecture is reflected in the structure and organization of its implementation. These architectural attributes 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.

Source: http://jiagoushi.pro/node/1056

Discussion: Please join the Knowledge Planet “Chief Architect Circle” or the editor’s small account “jiagoushi_pro”.