Application Architecture
Application architecture defines how a software system is structured internally: its layers, components, communication patterns, and boundaries. It determines how code is organized, how concerns are separated, and how the system evolves as requirements change.
itEnterprise architecture and integration | OpenSkills.info
Intro
Application Architecture
Application architecture is the set of important decisions about an application's structure and behavior. It identifies the major parts, the responsibilities each part owns, and the relationships that let the parts work together.
The word important carries weight. A local function name is usually a code-design choice. A decision that shapes deployment, data ownership, security boundaries, or change cost is architectural. You invest more care in decisions that are expensive to reverse.
Application architecture sits between two neighboring scopes. Enterprise architecture coordinates capabilities, information, and technology across an organization. Detailed software design shapes classes, functions, and algorithms inside a component. Application architecture focuses on one application and its surrounding systems.
The mental model: a set of boundaries and flows
Start with the work the application performs, not a diagram style or a product list. Trace one useful flow from an actor to an outcome:
actor or system
|
v
entry point -> business capability -> state change or query
| | |
v v v
identity integrations data store
\_______________ runtime platform ______/
The boxes matter because they own responsibilities. The arrows matter because they create dependencies. Every arrow needs a contract, a failure model, and an owner.
You then inspect the same application through three views:
- Static structure — applications, data stores, components, and their dependencies.
- Runtime behavior — requests, messages, events, data movement, retries, and failures over time.
- Deployment structure — processes, nodes, networks, trust boundaries, and release units.
One view cannot answer every question. A product owner needs a different view from an operator or a security reviewer. ISO/IEC/IEEE 42010 treats this explicitly: stakeholders hold concerns, viewpoints frame those concerns, and views express the architecture from those viewpoints.
Begin with drivers, not styles
An architecture is fit only in a specific context. Collect the drivers before selecting a style.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.sei.cmu.edu/software-architecture/
Supports
- Architecture as decisions about overall system structure and behavior
- Architecture analysis against modifiability, availability, and security
- Documentation of architectural elements and interrelationships
- Repeated evaluation against business and mission goals
- Deployed-system conformance analysis and continuous evolution
- https://www.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/
Supports
- Structured architecture evaluation against competing quality attributes
- Interactions among modifiability, security, performance, and availability
- Candidate architecture analysis, risk mitigation, and refinement
- Quiz answers about measurable qualities and quality trade-offs
- https://www.sei.cmu.edu/library/an-introduction-to-software-architecture/
Supports
- Architecture as organization of systems built from many components
- Common architectural styles and their combination in one design
- Architectural representations as aids to understanding complex systems
- https://www.iso-architecture.org/ieee-1471/cm/
Supports
- Stakeholders as holders of concerns
- Viewpoints as conventions that frame concerns
- Views as expressions of architecture from stakeholder perspectives
- Architecture descriptions containing multiple architecture elements
- https://www.iso-architecture.org/ieee-1471/ads/
Supports
- Architecture descriptions identifying stakeholders and fundamental concerns
- Coverage of concerns through viewpoints and views
- Consideration of users, operators, owners, developers, and maintainers
- Inclusion of architecture evaluation results
- https://c4model.com/
Supports
- Hierarchical abstractions of software systems, containers, components, and code
- System context, container, component, and code diagrams
- Supporting system landscape, dynamic, and deployment diagrams
- Notation-independent and tooling-independent use
- https://c4model.com/diagrams
Supports
- Different zoom levels for different audiences and stories
- Context and container diagrams as sufficient for many teams
- Scope and audience distinctions among architecture diagrams
- Quiz distinction between code and deployment representations
- https://learn.microsoft.com/en-us/azure/architecture/guide/
Supports
- Evaluation through reliability, security, cost, operations, and performance lenses
- Architecture styles and data models selected after business and quality requirements
- Compute, data store, and messaging as major technology decisions
- Design patterns as repeatable approaches to processing and data storage
- https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/
Supports
- Architecture styles as shared characteristics and design constraints
- N-tier separation into presentation, business logic, and data access
- Web-queue-worker separation of interactive and long-running work
- Independent service deployment, fault isolation, and private service data
- Event-driven producer and consumer decoupling
- Messaging challenges involving eventual consistency and duplicate messages
- Microservice communication and manageability costs
- Style selection from business drivers and prioritized quality requirements
- https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
Supports
- Event producers, consumers, and event channels
- Producer and consumer decoupling
- Distinction between broadcast events and mediator-dispatched commands
- Ordering, idempotency, error handling, observability, and schema evolution challenges
- Eventual consistency as an explicit architecture trade-off
- Combination of event-driven and other architecture styles
- https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations
Supports
- Private service data stores and avoidance of shared-schema coupling
- Shared schemas as a source of coordinated changes across services
- Single sources of truth and explicit consistency requirements
- Event schemas and propagation of changes across service boundaries
- Redrawing boundaries when services become chatty and tightly coupled
- https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html
Supports
- Architecture evaluation through consistent questions and best practices
- Operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability pillars
- Components working together to deliver workload requirements
- Quality trade-offs driven by business context
- https://martinfowler.com/bliki/ArchitectureDecisionRecord.html
Supports
- ADR as a short record of one consequential decision
- Decision, context, and significant ramifications as core content
- Accepted records preserved and linked to superseding records
- Decision records as aids to later understanding and current group reasoning