Architecture describes the fundamental structure, components, and relationships of a system and the principles guiding their design. It links business requirements with technical decisions, aligns quality attributes and interfaces, and provides a decision framework for scalability, security, and maintainability across organizational contexts.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
Architecture describes a system’s fundamental structure, its components and relationships, and the principles used to shape them so that technical and business decisions fit together.
In software engineering, architecture emerged as a response to the problem of keeping large systems understandable and changeable when many teams, components, and requirements meet. Rather than designing only features, teams decide early on structures, interfaces, quality goals, and choices that are costly to revise. This lets communication, maintainability, and technical constraints be managed together.
Think of architecture as a decision frame that orders a system from the outside in: What work should it do, which quality goals matter, where are the boundaries between components, and which interfaces keep change manageable? Good architecture intentionally leaves more options open than it locks down, and it makes the important constraints visible before code cements them at high cost.
Communication and team structure often shape the structure of the systems they build.
Related responsibilities stay together so modules remain clearer and easier to change.
Human abilities, limits, and working patterns influence how systems are partitioned and used.
Customer priorities guide the structure decisions and trade-offs that matter most.
A framework that structures enterprise architecture through process, terminology, and governance.
Architecture helps with new platforms, modernization, team boundaries, compliance, and major redesigns when many decisions depend on each other. It only works when maintained with the teams, operations, and product context; too little architecture leads to drift, while too much upfront design can slow delivery. Good architecture is therefore ongoing steering, not a one-time plan.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.