Skip to content
Software Architecture Guide

Relationship between Enterprise Architecture and Application Architecture

Explanation

Section titled “Explanation”

Enterprise architecture (EA) looks at the structure of many applications across an organization. Application architecture looks at one software system. The iSAQB Foundation curriculum treats the structure of application landscapes as a related domain outside its own focus on individual systems.

From EA to the application

EA reaches an application team mainly through constraints. arc42 defines a constraint as a requirement that limits architects’ freedom in design and implementation decisions. Some constraints go beyond one system and apply to a whole organization. Teams must always deal with them, although some can be negotiated. See the articles on arc42 Constraints and Architectural Constraint.

Technology standards are a common case. In larger enterprises, an architecture committee often sets standards for technology choices. These become technical constraints for the team. A mandated framework for single-page web applications is one example.

EA also supplies content. The iSAQB EAM curriculum lists architecture principles and reference models or reference architectures as EA content. Architects must recognize and account for these EA specifications in their work.

From the application back to EA

Influence runs both ways. iSAQB teaches that software architecture decisions, and changes to applications, influence the enterprise architecture and the business and IT strategy. EA is not a one-way order from the top.

Governance

The iSAQB EAM module also covers governance and compliance. It includes methods to monitor and assess whether architectures comply, for example according to TOGAF.

Sharing responsibility

Some concerns affect several applications, such as aspects that cut across systems. The iSAQB EAM curriculum expects architects to decide how responsibility for these is divided between EA and the individual applications.

Freedom of the team

The arc42 canvas notes that organizational and technical constraints determine how much decision freedom an engineering team has. The more EA constrains, the less the team can decide alone.

Example

Section titled “Example”

A company’s architecture committee decides that all new web front ends use one approved framework. A product team starting a new application records this as a technical constraint. Later the team finds the framework handles offline use poorly. They report this to the committee, which can then revisit the standard.

Trade-offs

Section titled “Trade-offs”

Constraints from EA limit team freedom, as the arc42 canvas notes. Teams gain shared direction but give up some choices. Constraints may be negotiable, so teams can raise problems. Dividing responsibility for cross-application concerns between EA and applications must be decided case by case.

Influence flows in both directions between enterprise and application architecture.

Diagram source 
flowchart LR
  EA[Enterprise architecture] -->|constraints, principles, reference models| APP[Application architecture]
  APP -->|decisions and change needs| EA

Checks

Section titled “Checks”
  • Constraints that originate in enterprise-wide standards, such as mandated technologies, are listed as constraints.
  • For each organizational constraint, the document states whether it is fixed or negotiable.
  • Responsibility for concerns that affect several applications is assigned between EA and the application.
  • The document records how compliance with EA specifications is monitored or assessed.
Section titled “Related”

Sources

Section titled “Sources”