Application Architecture – Context

Luc Bories

- 6 minutes read - 1207 words

Are You Concerned with Application Architecture?

If you’re a developer, you want to understand how application components interact; how a particular application workflow should run and what results to expect; and how an end user should engage with an input or display screen.

If you’re an infrastructure specialist, you need to know the type and volume of data stored and transferred; the frequency and load each application process demands; and how different application solutions fit together within the information system (IS).

If you’re a security expert, you need visibility into where sensitive data resides, who can view or modify it, and how your applications interact with external systems.

If you’re a decision-maker, architect, or project manager, you want a holistic view of how the IS operates.

Yet too often, “architecture” isn’t documented, and no artifacts exist to describe the current state or the target vision. Some teams produce isolated diagrams for a narrow audience, but there’s no unified Application Architecture covering the whole system.

The solution? Apply the core principles of IT Architecture to document the Application Architecture for all—or part—of your information system.

Overview of IT Architecture

To grasp what Application Architecture really means, start by reviewing the various ways to depict IT Architecture.

Depending on the scope, the IS’s size and structure, and your organization’s culture and methods, the layers and terminology will vary. But the sequence typically begins with a business need.

That need is captured in use cases and user roles—that’s Business (or Domain) Architecture.

When the focus shifts to how applications are organized—functional blocks, intra- and inter-application data flows, user interfaces—you enter Application Architecture.

Drilling down into specific features and functions yields Functional Architecture.

Everything about the data—nomenclature, standards, tools, governance—is detailed in Data Architecture.

Designing the software components themselves, using logical models (modules, components, classes), is often called Logical Application Architecture or Software Architecture.

Finally, specifying servers, databases, middleware and other technologies is the realm of Technical Architecture.

Defining Application Architecture

As noted above, Application Architecture isn’t a one-size-fits-all blueprint. It’s a set of guiding principles applied within an architectural method or framework—typically established by Enterprise Architecture.

At its core, Application Architecture describes, at a high level, a hierarchy of applications, modules or components, features and business entities. Each element can interact with others, inside or outside its container.

Because application projects vary so widely, the principles are intentionally flexible, and multiple frameworks exist to support them.

All of these scenarios call for Application Architecture, even though they differ greatly:

  • Implementing an on-premises, off-the-shelf packaged solution and configuring it
  • Deploying an on-premise package alongside custom development
  • Integrating a SaaS offering with your existing application portfolio
  • Outsourcing a complete application process to a third-party provider
  • Developing a mainframe-based application
  • Building a 3-tier web application
  • Creating a microservices-based system
  • Designing a service-oriented application
  • Constructing an event-driven distributed application on an enterprise service bus
  • Assembling a fully cloud-native application by orchestrating online services
  • Developing a mobile app
  • Building a desktop application
  • Creating a connected-device (IoT) application
  • Engineering software for industrial machinery
  • Crafting a scientific computation application

In each case, Application Architecture provides the blueprint that ensures your solution fits the business need, aligns with technical standards, and integrates seamlessly into the broader IT landscape.

Variations of Application Architecture

Application Architecture can also encompass a set of sub-architectural domains that sometimes eclipse the very term “Application Architecture”:

  • Software Architecture
  • Integration Architecture
  • Data Architecture
  • Functional Architecture

Software Architecture focuses more on development, reflected in its terminology: components, modules, libraries, frameworks, data models, user experience, user interface, programming languages…

Integration Architecture describes how applications integrate with each other:

  • the nature, description, and format of exchanged data
  • the nature and format of synchronous and asynchronous communication flows
  • the definition of integration-specific elements

Data Architecture ensures consistency and traceability of the IS’s data. It covers logical data models, data definition models, and physical data models, and sets rules for choosing storage and exchange tools, best practices, anonymization, and processing optimization.

Functional Architecture often leads implementations because it translates business needs into functional specifications for designers and developers.

In general, Application Architecture delivers:

  • a global view of application elements
  • a precise description of each element’s expected behavior
  • a description of possible interactions between elements
  • a description of data used and exchanged by the elements
  • an implementation roadmap with key milestones
  • a guide for specification and implementation
  • reusable solution patterns (see Solution Architecture/[LINK])

Facets of Application Architecture

An application can operate in ways more or less visible to internal users or customers.

The visible part—the frontend—touches users directly. User experience (UX) is critical here: how the application feels in use. Although web and mobile apps dominate today, desktop and mainframe applications still matter.

Describing the frontend includes the user interface design, interactions among interface elements, and consumption of backend services.

The background part—the backend—processes data and runs workloads without direct user interaction. Security, resilience, performance, and scalability are the watchwords.

Backend documentation typically covers data schemas, data exchanges, application integration, batch processes, and application services.

Methods for Application Architecture

Application Architecture spans a wide variety of contexts and use cases.

Projects range from brand-new web or mobile apps to decades-old legacy systems from a pre-PC, pre-internet era. Organizational culture and industry drive very different needs around security, agility, and compliance.

Between an international financial institution and a mobile gaming startup, Application Architecture requirements differ drastically. Even within a single Enterprise Architecture, the nature of a given application may call for a different method.

Major architectural approaches include:

  • The Data/Processing approach (Zachman, Merise): a top-down, sequence-driven, often verbose methodology.
  • The Component approach (Zachman): suited for distributed, object-oriented systems; sometimes criticized as rigid and theoretical.
  • The Service-Oriented (SOA) approach: builds services for loose coupling with external consumers.
  • The Business Process approach: uses formal modeling (UML). While UML is a de facto standard, no single modeling norm exists—vendors often extend it. BPM and BPR tools (Mega, Erwin/Casewise) facilitate this approach.

Deliverables of Application Architecture

Deliverables vary by organization, architectural standards, and methodology. Key artifacts may include:

  • design and development environment specifications
  • list of required technical building blocks: libraries, packages, SaaS solutions, design patterns
  • modeling and design tool recommendations
  • development tool recommendations (IDEs)
  • development standards and practices
  • functional specifications
  • diagrams of data structures, processes, flows, and interfaces
  • user interface mockups
  • integration specifications
  • software design specifications

Role of the Application Architect

The Application Architect often holds a central position, with a comprehensive view of application behavior across functional, technical, and architectural realms.

They proceed iteratively—drafting a high-level overview, then refining components for implementation. Their primary responsibilities include:

  • gathering functional requirements, constraints, and business rules
  • defining and communicating guiding principles for the application architecture
  • specifying technical needs
  • contributing to technology selection
  • creating the Application Architecture
  • participating in or leading software design
  • supporting designers and developers
  • engaging in testing, integration, acceptance, and performance validation

Application Architecture Supporting IS Urbanization

Information system urbanization maps the IS’s components and their interactions without diving into design or implementation details. Its goal is to ensure overall system coherence.

Application Architecture maintains IS scalability and uniformity by enforcing the established rules and constraints, and by applying these practices at the appropriate level of granularity.

Thus, Application Architecture serves both designers and developers—enabling solution delivery while safeguarding overall system coherence, security, resilience, and scalability.