# Glossary

- [4+1 View Model](https://arc.fuet.ch/concepts/documentation/4-1-view-model.md): The 4+1 View Model describes a software system through several views at once. Each view speaks to different stakeholders. A fifth view, made of scenarios, illustrates how the architecture works.
- [Acceptance Criterion](https://arc.fuet.ch/concepts/functional-requirements/acceptance-criteria.md): An acceptance criterion is a condition a user story must meet before the product owner accepts it as complete. Each criterion belongs to one story, and clear ones can feed test cases.
- [Accidental Architecture](https://arc.fuet.ch/concepts/fundamentals/unsystematic-accidental-architecture.md): Accidental architecture is a structure nobody deliberately chose. It is merely implied, and it tends to erode through quick fixes and piecemeal growth until it ends as a Big Ball of Mud.
- [Accountability](https://arc.fuet.ch/concepts/quality-attributes/accountability.md): Accountability means you can trace each action to the one entity that did it. It is a security quality in ISO/IEC 25010, next to authenticity, non-repudiation, and confidentiality.
- [Active Redundancy](https://arc.fuet.ch/concepts/tactics/active-redundancy.md): Active redundancy keeps spare components running alongside the working ones, all processing the same inputs. A spare can take over within milliseconds. This gives the fastest recovery, but it costs the most.
- [Adaptability](https://arc.fuet.ch/concepts/quality-attributes/adaptability.md): Adaptability is how well a product can be adapted to changes in its requirements, contexts of use, or system environment, including different or evolving hardware and software. ISO 25010 places it in the group now called Flexibility.
- [Additional Architecture Viewpoints (Security, Information, Operational, Development, Process, Evolution)](https://arc.fuet.ch/concepts/documentation/additional-architecture-views-and-perspectives.md): Besides the basic structural views, a project can add viewpoints for information, development, operations, deployment, security and evolution. Each covers a specific kind of concern that stakeholders raise.
- [ADR Common Mistakes and Review Checklist](https://arc.fuet.ch/concepts/forces-decisions/adr-common-mistakes-and-remediations.md): Weak decision records often hide their criteria, skip alternatives, give no real "why," or leave out downsides. A short review checklist helps catch these gaps before the record is accepted.
- [Advantages and Drawbacks of ATAM](https://arc.fuet.ch/concepts/evaluation/advantages-and-drawbacks-of-atam.md): ATAM brings early risk detection, clearer quality requirements, better documentation and more stakeholder discussion. The price is effort: a full evaluation takes days and many people, so lighter variants exist.
- [Aggregate](https://arc.fuet.ch/concepts/domain-driven-design/aggregate.md): An aggregate is a group of related domain objects treated as one unit. One object, the root, is the only entry point from outside, and it keeps the whole group consistent.
- [Aggregate Tactic](https://arc.fuet.ch/concepts/tactics/aggregate-tactic.md): The aggregate tactic follows the bulk idea: handle many items in one operation instead of one by one. At service level, the same idea appears as a request bundle. It is unrelated to the DDD aggregate and the Aggregator pattern.
- [Aggregation vs. Composition](https://arc.fuet.ch/concepts/modeling-uml/composition-versus-aggregation.md): Aggregation and composition are UML ways to show that something is made of parts. Composition is strict: a part belongs to one whole. Aggregation is loose and adds little beyond a plain association.
- [Agile Architecture](https://arc.fuet.ch/concepts/fundamentals/agile-architecture.md): Agile architecture means doing just enough architecture, guided by the biggest risks, and revisiting it as the product changes. It avoids both big upfront design and no design at all.
- [Agile Enterprise Backlog Model](https://arc.fuet.ch/concepts/functional-requirements/agile-enterprise-backlog-model.md): The Agile Enterprise Backlog Model arranges requirement work items in levels: themes, epics, features, stories and tasks. Tests show when items are done and whether the system meets its nonfunctional requirements.
- [Analysability](https://arc.fuet.ch/concepts/quality-attributes/analysability.md): Analysability is how easily people can judge the effect of a change, diagnose a failure, and find the parts to modify. ISO/IEC 25010 lists it as one of five maintainability sub-characteristics.
- [Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture.md): Application architecture is the enterprise-level view of which applications an organization uses and how they relate. It stays logical and does not cover the internal design of any single application.
- [Application Architecture Artifacts](https://arc.fuet.ch/concepts/enterprise-architecture/application-architecture-artifacts.md): Application architecture artifacts document an enterprise's application layer. A catalog lists the applications. Interface, interaction, technology and migration views add connections, platforms and change over time.
- [Application Interface Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-interface-diagram.md): An application interface diagram shows how an organization's applications connect to each other. Each connection is labeled with its technology, such as REST or FTP. This makes integration dependencies visible.
- [Application Landscape Evolution Drivers](https://arc.fuet.ch/concepts/enterprise-architecture/patterns-for-the-evolution-of-application-landscapes.md): Application landscape evolution drivers are the business and IT goals that push a company to change its applications. Typical drivers are cost, agility, resilience and AI. They guide choices such as retire, replace, rehost or refactor.
- [Application Lifecycle Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-lifecycle-diagram.md): An application lifecycle diagram is a Gantt chart that shows when each application is planned to start and stop supporting the business. It helps teams spot retirement and replacement needs early.
- [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md): Section 9 of arc42 records important, expensive, large-scale or risky architecture decisions with their reasons. It points back to section 4 for the most fundamental decisions instead of repeating them.
- [arc42 Architecture Documentation Template](https://arc.fuet.ch/concepts/documentation/arc42-documentation-template.md): arc42 is a free template that gives architecture information a fixed place across twelve sections. Teams tailor it to their needs and use it in agile, lean or formal projects.
- [arc42 Constraints](https://arc.fuet.ch/concepts/documentation/arc42-constraints.md): Chapter 2 of arc42 lists every requirement that limits how architects may design and build a system. It shows where the team is free to choose and where it must comply.
- [arc42 Context and Scope](https://arc.fuet.ch/concepts/documentation/arc42-context-and-scope.md): Context and Scope is the arc42 chapter that shows the system as a black box and what it exchanges with its environment. The business view covers the data exchanged. The technical view covers the channels.
- [arc42 Glossary](https://arc.fuet.ch/concepts/documentation/arc42-glossary.md): The arc42 glossary is section 12 of the template. It lists the key domain and technical terms stakeholders use, so everyone means the same thing by the same word.
- [arc42 Introduction and Goals](https://arc.fuet.ch/concepts/documentation/arc42-introduction-and-goals.md): Section 1 of arc42 gives a short overview of what the system must achieve. It lists the top three to five quality goals and a table of stakeholders with their expectations.
- [arc42 Quality Requirements](https://arc.fuet.ch/concepts/documentation/arc42-quality-requirements.md): Chapter 10 of arc42 turns quality requirements into concrete quality scenarios, so readers can decide whether each requirement is met. It points to the top goals from section 1.2 and adds lower-priority ones.
- [arc42 Quality Requirements Chapter](https://arc.fuet.ch/concepts/documentation/arc42-quality-chapter.md): Chapter 10 of arc42 turns quality requirements into concrete scenarios. A quality tree gives the overview, and each scenario lets you decide whether a requirement is met.
- [Architect's Four Key Work Products](https://arc.fuet.ch/concepts/fundamentals/architect-s-four-key-work-products.md): The architect's four key work products are a vision, a context view, an architecture overview and an operational model. Together they cover goals, environment, main parts and how the system runs.
- [Architectural Approach Identification](https://arc.fuet.ch/concepts/evaluation/architectural-approach-identification.md): Architectural approach identification is Step 4 of ATAM. The architect names the approaches used in the system. The team only lists them here and analyzes them later.
- [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md): An architectural constraint is a requirement that limits how freely architects can design and build a system. Teams must always deal with constraints, though some can be negotiated. Writing them down shows where the design is free and where it is not.
- [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md): An architectural decision is a choice of one option from several, made against stated criteria. Writing down the reasons lets others understand and retrace the choice later.
- [Architectural Decision Definition of Ready](https://arc.fuet.ch/concepts/forces-decisions/definition-of-ready-for-architectural-decisions.md): The Architectural Decision Definition of Ready is a checklist of five START criteria: stakeholders, time, alternatives, requirements, template. Teams check it before deciding, so they do not decide without the key inputs.
- [Architectural Decision Making Fallacies](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-fallacies.md): Architectural decisions often fail through familiar flawed reasoning, such as copying the crowd or leaning on one story. Each fallacy has a countermeasure. Naming them helps teams decide consciously and record decisions durably.
- [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md): Architectural decision management is a set of habits for choosing which decisions to record, deciding them at the right time, justifying them well, and following through on them.
- [Architectural Decision Management Cycle](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-cycle.md): The cycle has five logical steps for each architectural decision: identify it, evaluate options, decide, record the outcome in an ADR, and check that the problem is solved. Teams may repeat steps for the same decision.
- [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md): An Architectural Decision Record (ADR) is a short document that captures one design decision and the reasons behind it. It answers "why this design?" and helps teams avoid reopening settled decisions.
- [Architectural Decision Record Example](https://arc.fuet.ch/concepts/forces-decisions/middleware-architectural-decision-example.md): An ADR example records one decision: the question, the quality goals behind it, every option with pros and cons, and the outcome with its consequences. It lets readers retrace why a choice was made.
- [Architectural Decision Records as Evaluation Prerequisite](https://arc.fuet.ch/concepts/evaluation/architectural-decision-records-as-evaluation-prerequisite.md): Writing down key architectural decisions, with the reasons for each choice, gives an evaluation something concrete to check against the quality goals. Reviewers can then see which decisions support which goals.
- [Architectural Decision-Making Process](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-in-project-development.md): Architectural decision-making is an ongoing, team-based activity. One decision triggers others, so it is never finished at once. Teams compare real alternatives, weigh trade-offs, and revisit their choices.
- [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md): Designing for availability means asking structured questions: which parts must stay up, how faults are detected, and how the system keeps working when something fails. The answers become design decisions.
- [Architectural Design Issue](https://arc.fuet.ch/concepts/forces-decisions/formulation-of-decision-issues.md): A design issue is one concern that needs an architectural decision. You phrase it as a short question, list the options, and pick one based on criteria. You then record why you chose it.
- [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md): Forces are pressures that pull an architectural decision in different directions, such as deadlines, cost, skill, and change. Architects weigh them against each other. Constraints, by contrast, must be dealt with.
- [Architectural Overview Antipattern](https://arc.fuet.ch/concepts/documentation/architectural-overview-antipatterns.md): An overview diagram fails when readers cannot tell what it shows. Common causes are unclear scope, cryptic labels, and unexplained notation. Fix it with a title, a legend, plain names, and several simpler diagrams.
- [Architectural Overview Diagram](https://arc.fuet.ch/concepts/documentation/architectural-overview-diagram.md): An architectural overview diagram shows the inside of a system at a high level, together with the users and other systems it talks to. It records the early, big solution decisions and gives a base that other diagrams refine.
- [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md): An architectural pattern is a proven, reusable solution to a problem that keeps recurring in systems. Its description covers context, problem, solution and consequences, so you can see the trade-offs before you choose.
- [Architectural Pattern vs. Design Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern-vs-design-pattern.md): An architectural pattern shapes the structure of a whole system. A design pattern solves a narrower problem in one subsystem. Architectural choices are costly to change later, so they deserve more upfront effort.
- [Architectural Perspective](https://arc.fuet.ch/concepts/quality-attributes/architectural-perspective.md): An architectural perspective is guidance for making sure a system has a group of related quality properties, such as security. You apply it to each architectural view, instead of adding a new view per property.
- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md): An architectural tactic is a design decision that affects how well a software architecture addresses a quality attribute. Tactics work by adjusting parameters of a quality attribute model, and architectural patterns are built from them.
- [Architectural Thinking](https://arc.fuet.ch/concepts/fundamentals/architectural-thinking.md): Architectural thinking is a repeated cycle of designing, checking and refining. It starts from requirements, quality goals and constraints, and ends in a documented architecture whose risks and trade-offs are understood.
- [Architectural View](https://arc.fuet.ch/concepts/documentation/purpose-of-views.md): An architectural view describes a system from the angle of one stakeholder group. Splitting the description into views keeps each part understandable and lets each reader find what matters to them.
- [Architecturally Evident Coding Style](https://arc.fuet.ch/concepts/fundamentals/architecturally-evident-coding-style.md): An architecturally evident coding style shows architecture rules in the code itself, through package layout and naming conventions. Automated tests, such as ArchUnit for Java, can then check that the code follows those rules.
- [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md): An architecturally significant decision is hard or costly to change, or carries high risk or cost. These decisions deserve careful review and a written record. Small, local choices do not.
- [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md): An architecturally significant requirement strongly shapes the architecture because it is hard to meet, costly to change later, or risky. Teams spot these with a qualitative seven-criterion test and keep a short list of about ten.
- [Architecture as Set of Design Decisions](https://arc.fuet.ch/concepts/forces-decisions/architecture-as-set-of-design-decisions.md): Architecture is the set of important design decisions about a system. These decisions shape quality and are costly to change later. Diagrams only show the results of those decisions.
- [Architecture Canvas](https://arc.fuet.ch/concepts/documentation/architecture-canvas.md): An architecture canvas is a one-page structured sheet for capturing the essentials of a software system quickly. It builds on ideas from the Business Model Canvas and comes in three arc42 variants.
- [Architecture Challenges at Project Start](https://arc.fuet.ch/concepts/forces-decisions/architecture-challenges-at-project-start.md): At project start, architects must make basic decisions with little certainty. Requirements change, constraints limit freedom, and early choices may prove wrong. Good timing and recorded decisions help teams correct course.
- [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md): Architecture decay is the slow divergence of a built system from its intended design. Small, unplanned changes pile up and erode the structure. Refactoring and conformance checks counter it.
- [Architecture Decision Documentation and Requirements Management](https://arc.fuet.ch/concepts/forces-decisions/decision-documentation-and-requirements-management.md): Architects write down important decisions with their context, reasons and consequences. That lets stakeholders retrace why the system looks the way it does, and see where constraints limited the choices.
- [Architecture Decision Rationale](https://arc.fuet.ch/concepts/forces-decisions/architecture-decision-rationale.md): Architecture decision rationale is the written reason behind a key design choice. It lets stakeholders later understand why one option won and retrace the decision.
- [Architecture Disciplines](https://arc.fuet.ch/concepts/fundamentals/architecture-disciplines.md): Architecture work happens at different scopes. A common picture compares enterprise architecture to city planning and solution architecture to a building design. Several specialist disciplines, such as network architecture, help shape one solution.
- [Architecture Level](https://arc.fuet.ch/concepts/fundamentals/architecture-levels.md): Architecture can be described at several levels of detail. In arc42's building block view, each deeper level zooms into selected parts of the level above, and you only zoom where it matters.
- [Architecture Means](https://arc.fuet.ch/concepts/fundamentals/architecture-means.md): Architecture means are the architect's toolbox: styles, patterns, tactics, reference architectures and modelling notations. More concrete means give more structure and reuse, but they also limit the architect's freedom.
- [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md): An architecture principle is a short statement of what an organization values. It narrows the options for design decisions without dictating the answer, so teams decide faster and more consistently.
- [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md): An architecture principle is written in four parts: a Name, a Statement, a Rationale and Implications. Together they show the rule, why it helps the business, and what it demands.
- [Architecture Style](https://arc.fuet.ch/concepts/styles-patterns/architectural-style.md): An architecture style is a set of design constraints: which elements may appear and how they may relate. Following the constraints gives a system certain desirable properties. Every style also has costs.
- [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md): ATAM is a method for checking a software architecture against its quality goals. It shows how those goals pull against each other and exposes risks that could block business goals.
- [Architecture View](https://arc.fuet.ch/concepts/documentation/architecture-view.md): An architecture view shows one side of a system's design. It shows how the architecture addresses the concerns of specific stakeholders, the people with an interest in the system.
- [Architecture View Model](https://arc.fuet.ch/concepts/documentation/architecture-view-model.md): An architecture view model is a ready-made set of viewpoints that fit together to describe a system. Reusing one, such as 4+1, avoids inventing views and avoids one overloaded model.
- [Architecture Viewpoint](https://arc.fuet.ch/concepts/documentation/architecture-viewpoint.md): An architecture viewpoint is a set of patterns, templates and conventions for building one type of view. It names the stakeholders whose concerns that view addresses. A perspective differs: it applies quality guidelines across views.
- [ARIS Process Views](https://arc.fuet.ch/concepts/modeling-bpmn/aris-process-views.md): ARIS describes a business and its information systems through several views, and each view is detailed in three levels. Process chain diagrams belong to its control view. ARIS mainly supports analysis and requirements definition.
- [AS-IS and TO-BE View](https://arc.fuet.ch/concepts/documentation/as-is-and-to-be-view.md): An AS-IS view shows the legacy system as it is. A TO-BE view shows the target. Temporary transition states between them may differ from both.
- [ATAM Application Phases](https://arc.fuet.ch/concepts/evaluation/atam-application-phases.md): ATAM works best early, before major implementation spending, because it shows whether an architecture can meet its quality goals. It also applies to legacy systems, once their real architecture has been recovered.
- [ATAM Evaluation Team and Stakeholder Selection](https://arc.fuet.ch/concepts/evaluation/atam-evaluation-team-and-stakeholder-selection.md): An ATAM evaluation needs an external evaluation team and a group of stakeholders. Both are chosen and briefed before analysis starts. The stakeholders supply the scenarios that drive the analysis.
- [ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points](https://arc.fuet.ch/concepts/evaluation/atam-findings-risks-non-risks-sensitivity-points-and-trade-offs.md): An ATAM review produces findings: risks, non-risks, sensitivity points and trade-off points. They come from analyzing architectural approaches against the highest-priority scenarios. Risks are then grouped into themes tied to business drivers.
- [ATAM Non-Risk](https://arc.fuet.ch/concepts/evaluation/atam-non-risk.md): A non-risk is a decision that an ATAM evaluation team analyzed and found sound for a specific quality goal. The team records it with its reasoning, next to the risks it finds.
- [ATAM Phase 1 and 2 Activities](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-and-2-activities.md): An ATAM evaluation is a short series of steps, usually three to four days. Participants present the method and the architecture, analyze it against scenarios, and end with a report of findings.
- [ATAM Phase 1: Architecture-centric Analysis](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-architecture-centric-analysis.md): Phase 1 of ATAM opens an architecture evaluation. The evaluation team, the architects and other participants start by learning how the method works. Phase 2 then widens the input to a larger stakeholder group.
- [ATAM Results](https://arc.fuet.ch/concepts/evaluation/atam-results.md): ATAM results are what an evaluation team hands to stakeholders at the end: documented architecture risks, plus risk themes showing which business goals those risks threaten.
- [ATAM Roles](https://arc.fuet.ch/concepts/evaluation/atam-roles.md): An ATAM evaluation involves three groups: a small external evaluation team, project decision-makers who can mandate architectural changes, and broader stakeholders who join only in the second phase.
- [Authenticity](https://arc.fuet.ch/concepts/quality-attributes/authenticity.md): Authenticity is the degree to which you can prove that a user, device, or resource is the one it claims to be. ISO/IEC 25010 lists it as a security sub-characteristic.
- [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md): Availability is the share of time a system is operational and usable when people need it. It is usually given as a percentage. Each extra nine cuts allowed downtime sharply but costs more to achieve.
- [Availability Scenario](https://arc.fuet.ch/concepts/quality-attributes/availability-scenario.md): An availability scenario describes one concrete failure and how the system should react, in six parts: source, stimulus, artifact, environment, response, and response measure. The measure makes the requirement testable.
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactic.md): Availability tactics are design measures that keep faults from turning into failures. They fall into three groups: detecting faults, recovering from faults, and preventing faults.
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md): An availability tactic is a design measure that controls how a system reacts to faults. Architects combine such measures to recover from faults, so the system keeps serving users.
- [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md): Availability tactics fall into three groups: detect faults, recover from faults, and prevent faults. Architects combine tactics from all three groups to meet an availability goal, and they weigh each choice against cost and complexity.
- [Barriers to UML Adoption](https://arc.fuet.ch/concepts/modeling-uml/barriers-to-uml-adoption.md): People disagree about what UML is for, which explains much of the resistance to it. UML 2 became bulkier for sketch users, and informal use drifts from the standard. Lighter options such as C4 exist.
- [Battlefield Control System ATAM Case Study](https://arc.fuet.ch/concepts/evaluation/battlefield-control-system-atam-case-study.md): The Battlefield Control System is the first worked case study of the ATAM, an architecture evaluation method, in the book Evaluating Software Architectures. It shows how risks, sensitivity points and trade-off points are found.
- [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md): A Big Ball of Mud is a system whose structure comes from quick fixes rather than design. It grows without control and is repaired again and again with expedient patches.
- [Blackboard Pattern](https://arc.fuet.ch/concepts/styles-patterns/blackboard-architecture.md): The blackboard pattern lets independent expert modules build a solution together through one shared memory. A control component decides which module runs next. It began in speech recognition and is now used for LLM agent teams.
- [Boundary Event](https://arc.fuet.ch/concepts/modeling-bpmn/attached-boundary-intermediate-event.md): A boundary event is attached to the edge of an activity and reacts while that activity runs. It can stop the activity or run alongside it. Typical uses are timeouts, reminders, and error handling.
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md): A bounded context is a boundary inside which one domain model applies. Large domains split into several contexts, each with its own model and vocabulary, so no single model has to fit everything.
- [Bounded Context Canvas](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context-canvas.md): The Bounded Context Canvas is a collaborative template for designing and documenting one bounded context. It captures name, purpose, importance, behavior, assumptions, and open questions.
- [BPM Life Cycle](https://arc.fuet.ch/concepts/modeling-bpmn/bpm-life-cycle.md): The BPM life cycle is a loop of stages for a business process: discovery, analysis, design, implementation and monitoring. A live process is measured and improved so it stays useful as goals, technology and rules change.
- [BPMN 2.0 Model Quality](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-model-quality.md): A BPMN process model is of high quality when it is free of control-flow errors such as deadlocks. Tools can check this in milliseconds, and guidelines such as 7PMG give advice on model quality.
- [BPMN 2.0 Notation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-notation-overview.md): BPMN 2.0 is an industry standard notation for modeling and running business processes. Its core elements are tasks, events, gateways, and sequence flow, which together show the order of work.
- [BPMN Activity](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-activity.md): A BPMN activity is a unit of work in a process. It can be a single task or a subprocess that groups further steps. Call activities reuse separate processes, and markers show repetition.
- [BPMN Ad Hoc Sub-Process](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-ad-hoc-sub-process.md): An ad hoc sub-process groups activities that have no fixed order. Each activity can run several times, in any order, or be skipped. The choice happens at runtime, not at design time.
- [BPMN Artifacts (Group and Text Annotation)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-artifacts-group-and-text-annotation.md): BPMN artifacts add extra information to a process diagram. A Group clusters elements visually. A Text Annotation attaches a note for human readers. Engines ignore the note.
- [BPMN as Modeling Language, Not Method](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-as-modeling-language-not-method.md): BPMN is a notation, a set of drawing conventions for business processes. It aims to be readable by business users and precise enough to translate into software process components.
- [BPMN Collaboration Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-collaboration-diagram.md): A BPMN collaboration diagram shows each participant's process in its own pool. Dashed message flows connect the pools, so interaction is explicit. Camunda recommends it over lanes for operational-level models.
- [BPMN Compensation Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-compensation-event.md): A compensation event lets a process undo work that already finished. You mark an activity as undoable, link it to an undo task, and trigger compensation later. Only successfully completed activities get undone.
- [BPMN Connecting Object](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-connecting-object.md): BPMN connecting objects are the lines that link elements in a process diagram. Sequence flow sets the order of steps inside a pool. Message flow links separate pools. Association is a dotted line.
- [BPMN Conversation Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-conversation-diagram.md): A BPMN conversation diagram gives a very high-level view of which participants exchange messages. It draws each group of exchanges as a hexagon called a conversation.
- [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-core-elements.md): BPMN is a standard notation for drawing business processes. Its core elements are tasks, sequence flow, gateways, events, data objects and swim lanes. Together they show what happens, in which order.
- [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-categories.md): BPMN describes a business process with a small set of building blocks. Events, tasks, and gateways are joined by flows. Pools and lanes show who does the work. Data objects show what information is used.
- [BPMN Data Element](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-data-element.md): BPMN data elements show the information a process uses or creates. Data associations link that data to activities. Data flows along these associations, not along sequence flows.
- [BPMN Diagram Types](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-diagram-types.md): BPMN offers collaboration diagrams, which show pools and the messages between them, and conversation diagrams, which give a high-level view of what participants talk about. Choreography diagrams are a newer third type.
- [BPMN Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-event.md): A BPMN event is something that happens in a process and affects its flow. Events either wait for something from outside (catch) or are raised by the process itself (throw).
- [BPMN Focus on Connected Businesses](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-focus-on-connected-businesses.md): BPMN can model processes that cross company borders. Each organization gets its own pool, and message flows show the messages passing between them. Business and technical people can both read the result.
- [BPMN Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-gateway-semantics.md): A BPMN gateway controls where a process path splits or joins. Splits send the flow down one, all, or some branches. Joins either pass flow on or wait for other branches.
- [BPMN Gateway Mismatch Antipatterns](https://arc.fuet.ch/concepts/modeling-bpmn/antipatterns-for-process-flows.md): A gateway mismatch means a BPMN split and its join have incompatible types. The result is a deadlock, where the process cannot finish, or a lack of synchronization, where an end event is reached more than once.
- [BPMN Layout Guideline](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-layout-guideline.md): A BPMN layout guideline is a set of drawing habits that make process diagrams easy to read: one flow direction, few crossings, no very long arrows, and clearly marked gateways.
- [BPMN Modeling Guidelines](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tips.md): BPMN modeling guidelines are simple naming and layout rules that keep process models readable. They cover page size, explicit start and end events, question-style XOR gateways, verb-object task names, and separate pools for partners.
- [BPMN Modeling Tool](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tools.md): A BPMN modeling tool is software for drawing process models. Camunda Modeler and bpmn.io are two examples. They differ in form, such as desktop or web, and viewer or editor. A free one suits first experiments.
- [BPMN Motivation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-motivation.md): BPMN is a standard process notation built on flowcharting. Diagrams are precise enough to become software process components and are stored as XML. OMG maintains it, and it is also ISO 19510.
- [BPMN Swimlane (Pool and Lane)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-swimlane-pool-and-lane.md): A pool is a box for one participant in a BPMN diagram. Lanes split a pool into parts. Separate pools talk only through message flows, never through sequence flow.
- [BPMN Task Marker and Task Type](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-task-marker.md): Task types say what kind of work a BPMN step is, such as service, script, or manual. Markers add repetition or compensation behavior. Tool support differs: Camunda 7 does not natively support the loop marker.
- [Broker Pattern](https://arc.fuet.ch/concepts/styles-patterns/broker-pattern.md): The broker pattern organizes a distributed system around one central component. Decoupled parts interact through remote calls, and the broker coordinates them. It forwards requests and returns results and errors. The whole system depends on it.
- [Business and Technical Context](https://arc.fuet.ch/concepts/documentation/business-and-technical-context.md): Business context shows which data a system exchanges with people and neighboring systems. Technical context shows the channels and protocols that carry that data. Documenting both, and linking them, helps stakeholders decide.
- [Business Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/business-architecture.md): Business architecture is a blueprint of an organization that gives everyone a common understanding of it. It is one of four enterprise architecture domains and centers on capabilities, value streams, information and organizational structure.
- [Business Architecture Artifact](https://arc.fuet.ch/concepts/enterprise-architecture/business-architecture-artifacts.md): Business architecture artifacts are maps and catalogues that describe an organization from the business side, such as strategy, capabilities, processes and customer journeys. They link strategy to the applications that support it.
- [Business Capability](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability.md): A business capability is an ability an organization has to reach a specific purpose or outcome. It describes what the business can do, not how the work is done. Capabilities form levels of detail.
- [Business Capability Map](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability-map.md): A business capability map lists what a business must be able to do, in a few levels, without saying how or by whom. It stays stable for years while processes, systems and teams change.
- [Business Domain Understanding](https://arc.fuet.ch/concepts/domain-driven-design/business-domain-understanding.md): Business domain understanding means architects and stakeholders share one clear picture of the business and its terms. Where meanings truly differ, bounded contexts keep each meaning in its own place.
- [Business Model Canvas](https://arc.fuet.ch/concepts/vision-stakeholders/business-model-canvas.md): The Business Model Canvas describes a business on one page in nine blocks: who it serves, what it offers, how it delivers, what it costs and what it earns. Architects read it to understand the business behind a system.
- [Business Object Lifecycle](https://arc.fuet.ch/concepts/modeling-bpmn/business-object-lifecycle.md): A business object lifecycle describes the states an object passes through, drawn as a state machine. Processes change those states. This data-centric view is an alternative to modeling only the activities of a process.
- [C4 Component Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-3-component-diagram.md): A C4 component diagram opens up one container and shows the components inside it, with their responsibilities and technology. Teams draw it only when it adds value.
- [C4 Level 4: Code Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-4-code-diagram.md): The code diagram is the fourth and most detailed C4 level. It shows the code elements inside one component. It is optional, and tools usually generate it, so teams rarely draw it by hand.
- [C4 Model](https://arc.fuet.ch/concepts/documentation/c4-model.md): The C4 model describes software architecture with four levels of diagrams: system context, containers, components, and code. Each level zooms into the one before it, so each audience can pick the level it needs.
- [Canonical Data Model](https://arc.fuet.ch/concepts/integration/canonical-data-model.md): A Canonical Data Model is one shared, application-independent data format that systems translate to and from. It cuts translation paths from n×n to n, but it is overkill for small integrations.
- [Capability Heat Map](https://arc.fuet.ch/concepts/enterprise-architecture/capability-heat-map.md): A capability heat map colors a map of business capabilities by assessment scores, such as maturity or strategic importance. It shows where to act and supports decisions about roadmaps.
- [Capability identification and naming](https://arc.fuet.ch/concepts/enterprise-architecture/capability-identification-and-naming.md): A business capability says what a business does, not how it does it. Identify capabilities that stay stable over time, and name them with nouns or gerunds, not verbs.
- [Capability Map Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/capability-map-development-method.md): Build a capability map in steps: set its purpose, keep it shallow, name owners, and describe what the business does rather than how. Capabilities should not overlap and should stay stable for years.
- [Capability Map Use Cases](https://arc.fuet.ch/concepts/enterprise-architecture/capability-map-use-cases.md): A capability map shows what a business does. Teams use it to plan strategy, find gaps and overlaps, set investment priorities, and decide where to focus resources and projects.
- [Capability versus process](https://arc.fuet.ch/concepts/enterprise-architecture/capability-versus-process.md): A capability says what an organization can do. A process says how the work gets done, step by step. Keep the two apart and link them, because capabilities stay stable while processes change.
- [Capturing Business Behavior via Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/capturing-business-behavior-via-process-modeling.md): Process models describe business behavior at different levels of detail. A high-level model explains a process to stakeholders. A more detailed one supports analysis. A BPMN model can also be run by a workflow engine.
- [Card, Conversation, Confirmation](https://arc.fuet.ch/concepts/functional-requirements/card-conversation-confirmation.md): A user story has three parts: a short card that names it, conversations that work out the details, and confirmation tests that show when the story is done as agreed.
- [Cargo Shipping Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/cargo-shipping-domain-model-example.md): The cargo shipping model is a worked example of a domain model for booking, routing and tracking cargo. It shows how naming business concepts clearly, such as plan versus actual handling, gives a model that experts can discuss.
- [Characteristics of a Good View](https://arc.fuet.ch/concepts/documentation/characteristics-of-a-good-view.md): A good view serves a named stakeholder and a clear purpose. It shows only the detail readers need, and it lets them check that their concerns are covered.
- [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md): Choosing tactics means picking design decisions that serve quality requirements you already captured. You then build patterns from them and handle the side effects each choice has on other qualities.
- [Circuit Breaker](https://arc.fuet.ch/concepts/tactics/circuit-breaker.md): A circuit breaker sits between a caller and a service it depends on. After repeated failures it fails calls at once instead of waiting. It later tests the service and resumes when the service recovers.
- [Claim Check](https://arc.fuet.ch/concepts/integration/claim-check.md): Claim Check keeps large data out of messages. The sender stores the data in an external store and sends only a small reference. The receiver uses that reference to fetch the data.
- [Clean Architecture](https://arc.fuet.ch/concepts/styles-patterns/clean-architecture.md): Clean Architecture arranges code in circles. Source code dependencies point only inward, toward the business rules. Web, database, and frameworks stay on the outside, so the rules can be tested without them.
- [Code Smell](https://arc.fuet.ch/concepts/evaluation/code-smell.md): A code smell is a surface sign in code that often points to a deeper design problem. Smells such as long methods or large classes show where refactoring may be needed.
- [Color Coding in BPMN Models](https://arc.fuet.ch/concepts/modeling-bpmn/color-coding-in-bpmn-models.md): Color coding adds a second visual layer to a BPMN diagram, on top of the standard shapes. It works best with few colors, a legend, and a diagram that still reads in grayscale.
- [Command Query Responsibility Segregation](https://arc.fuet.ch/concepts/data-architecture/command-query-responsibility-segregation.md): CQRS splits a system into a write side (commands) and a read side (queries), each with its own model. Teams can tune and scale each side separately, at the cost of extra complexity and possibly stale reads.
- [Common Architect Mistakes](https://arc.fuet.ch/concepts/fundamentals/common-architect-mistakes.md): Architects repeat the same mistakes: weak scoping, narrow stakeholder lists, a focus on functions, vague platform details, and self-built security. A published list of ten such mistakes works as a self-review checklist.
- [Common Class Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/common-class-diagram-modeling-mistakes.md): Class diagrams often repeat the same errors: impossible multiplicities, shared parts in a composition, missing multiplicity, and wrong arrows. Knowing them helps you review diagrams, even though tools catch some automatically.
- [Common Component Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/component-diagram-modeling-mistakes.md): Two common component diagram mistakes are leaving artifacts unlinked to the components they embody, and letting components depend on each other in a cycle. Both are avoidable with manifestation links and acyclic dependencies.
- [Common Features of Architecture Frameworks](https://arc.fuet.ch/concepts/enterprise-architecture/common-features-of-architecture-frameworks.md): An enterprise architecture framework defines how to create and use an enterprise architecture. Zachman and TOGAF differ in purpose, but TOGAF shows common traits: architecture levels, linked artifacts, and tailoring.
- [Common Sequence Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/common-sequence-diagram-modeling-mistakes.md): Many sequence diagram errors come from arrow styles. Replies, asynchronous messages, and lost or found messages are the usual trouble spots. Knowing what each arrowhead and line style means helps you catch them.
- [Common Use Case Diagram Errors](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram-modeling-mistakes.md): Use case diagrams often go wrong in repeatable ways: actors inside the boundary, actors named after job titles, technical parts shown as actors, and include or extend used without purpose. Fixing these makes the diagram clear.
- [Comparing Architectural Alternatives with ATAM](https://arc.fuet.ch/concepts/evaluation/comparing-architectural-alternatives-with-atam.md): To compare candidate architectures with ATAM, judge each against the same requirements and scenarios. Tally the risks, sensitivity points and trade-off points per draft. Then weigh them by business impact, not by count alone.
- [Compatibility](https://arc.fuet.ch/concepts/quality-attributes/compatibility.md): Compatibility is how well a product exchanges information with other products and does its job while sharing an environment and resources with them. Version numbers and tolerant reading help keep interfaces working as products change.
- [Complexity Reduction](https://arc.fuet.ch/concepts/principles/complexity-reduction.md): Complexity reduction means keeping a system as simple as its problem allows. Needless complexity makes software harder to understand, change and debug, so architects avoid whatever the problem does not require.
- [Component Connector (Assembly and Delegation)](https://arc.fuet.ch/concepts/modeling-uml/component-connector-assembly-and-delegation.md): A connector links parts inside a component design. An assembly connector joins parts so some provide services and others use them. A delegation connector links a component's outer contract to the inner parts that realize it.
- [Component Design Principles](https://arc.fuet.ch/concepts/principles/component-design-principles.md): Component design principles guide how to build parts of a system so they stay loosely coupled and easy to change. They hide internals, depend on stable interfaces, and keep wiring separate from use.
- [Component View](https://arc.fuet.ch/concepts/documentation/component-view.md): A component view shows how a system is built from parts. In arc42 it is the mandatory building block view: a hierarchy of black boxes and white boxes that makes source code structure understandable through abstraction.
- [Component View Antipattern: Lifting Code to Model Level](https://arc.fuet.ch/concepts/documentation/component-view-antipattern-lifting-code-to-model-level.md): Lifting code to model level means copying code packages, such as Facade, Service or Dto, into the architecture view. The diagram then mirrors the source code instead of abstracting it into meaningful building blocks.
- [Component View Refinement Levels](https://arc.fuet.ch/concepts/documentation/component-view-refinement-levels.md): A building block view is built in levels. Each level zooms into chosen blocks of the level above. Only important, risky, complex or volatile blocks get refined. Simple or standard parts are left out.
- [Composed Message Processor](https://arc.fuet.ch/concepts/integration/composite-message-processor.md): A Composed Message Processor keeps the overall message flow intact when one message holds several elements that may need different processing. An Aggregator gathers the results and decides when the combined answer is ready.
- [Composite State](https://arc.fuet.ch/concepts/modeling-uml/composite-state.md): A composite state is a state that contains inner states in one or more regions. With two or more regions, the regions run at the same time. Each region can have its own start and end.
- [Conceptual Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model.md): A conceptual data model is a high-level description of the business information an organization needs. It leaves out database details. Logical modeling later turns it into a structured database design.
- [Conceptual data model building method](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-building-method.md): A conceptual data model is built step by step: understand the business, find entities, add attributes and relationships, validate with stakeholders, then document. It describes what data is needed, not how to store it.
- [Conceptual Data Model Preparation for Logical and Physical Models](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-preparation-for-logical-and-physical-models.md): Preparing a conceptual data model means checking that it covers the business needs and defines its entities, attributes and relationships clearly. The checked model then becomes the basis for the logical and physical models.
- [Conceptual, Logical and Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-vs-logical-vs-physical-data-model.md): Data models come in three levels. The conceptual level describes the business domain. The logical level shapes it for a chosen kind of data technology. The physical level describes how one specific database stores the data.
- [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md): A concern is something a stakeholder cares about in a system, such as performance, security or maintainability. Concerns shape architecture, can conflict, and must be explicitly addressed in the architecture description.
- [Concurrent Region](https://arc.fuet.ch/concepts/modeling-uml/concurrent-region.md): A concurrent region is one of several parts of a composite state. An object in such a state sits in all its regions at once. Each region has its own start and end.
- [Confidentiality](https://arc.fuet.ch/concepts/quality-attributes/confidentiality.md): Confidentiality means only authorized parties can read data. It is one part of security. Teams achieve it with access controls, encryption and data classification, inside defined trust boundaries.
- [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md): Architecture principles such as simplicity, separation of concerns and low coupling each favor some qualities and cost others. They are guidelines, not absolute rules, so architects weigh them against business context and record the trade-offs.
- [Connect or Disconnect](https://arc.fuet.ch/concepts/principles/connect-or-disconnect.md): Connecting components creates dependencies between them. Disconnecting them avoids that but can hide dependencies. Good design keeps few, narrow, explicit dependencies, and the right amount depends on how much control you have.
- [Connector Cardinality](https://arc.fuet.ch/concepts/fundamentals/connector-cardinality.md): Connector cardinality is the number of components a connector links. A point-to-point connector links two. A multicast connector delivers to several components through one shared channel.
- [Connector Transparency (Direct vs Indirect Connection)](https://arc.fuet.ch/concepts/integration/connector-transparency.md): An indirect connector puts a channel between components, so a sender does not need to know who receives its data. This lowers coupling, but it makes the overall flow harder to follow.
- [Connectors and Distribution](https://arc.fuet.ch/concepts/fundamentals/connectors-and-distribution.md): A monolith can only be copied and run as several identical instances. Splitting a system into separate processes adds a new risk: a call to another process may be slow or fail while the rest keeps running.
- [Consistency of User Story and Use Case](https://arc.fuet.ch/concepts/functional-requirements/consistency-of-user-story-and-use-case.md): A user story and a use case describe one goal at different levels of detail. Keep them consistent so they never contradict each other. Treat the story as the brief, early form.
- [Constraining Associations](https://arc.fuet.ch/concepts/domain-driven-design/entity-relationship-clarification.md): Constraining associations means limiting how objects in a domain model can reach each other. You impose a direction or add a qualifier, so each remaining link needs less implementation.
- [Container Diagram (C4 Level 2)](https://arc.fuet.ch/concepts/documentation/c4-container-diagram.md): A container diagram zooms into one software system and shows its separately running parts: applications and data stores. It also shows the main technologies and how the parts talk to each other.
- [Content Enricher and Content Filter](https://arc.fuet.ch/concepts/integration/content-enricher.md): A Content Enricher adds data that a receiver needs but the sender lacks. A Content Filter does the opposite and removes data the receiver does not need. Both reshape messages to fit the receiver.
- [Content Filter](https://arc.fuet.ch/concepts/integration/content-filter.md): A Content Filter removes unimportant data items from inside a message and keeps only the important ones. It helps when a message is large and the receiver needs just a few items.
- [Content-based Router](https://arc.fuet.ch/concepts/integration/content-based-router.md): A Content-Based Router reads each message and sends it to a channel chosen from data inside the message. It lets one logical function span several systems. Its fixed rules need careful upkeep.
- [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md): A context map shows how bounded contexts relate in strategic DDD. It records who provides and who consumes, using named relationship patterns. DDD has no fixed notation, so each map must explain its arrows.
- [Context View](https://arc.fuet.ch/concepts/vision-stakeholders/context-view.md): A context view shows the system as a black box and the world around it. It focuses on what data the system exchanges with its environment, so everyone can see where the system starts and ends.
- [Context View Antipattern: Forgetting Bidirectional Data Flows](https://arc.fuet.ch/concepts/vision-stakeholders/context-view-antipattern-forgetting-bidirectional-data-flows.md): A context diagram goes wrong when it draws one-way arrows for exchanges that run both ways. The missing direction hides what data the system must send, receive and handle, so interfaces end up under-specified.
- [Context View Antipatterns](https://arc.fuet.ch/concepts/documentation/context-view-antipatterns.md): A context diagram shows one system as a black box, with its direct neighbors and the data exchanged. Common mistakes blur this view: unlabeled arrows, system internals, unclear boundaries, or too much detail.
- [Continuous Architecture Principles](https://arc.fuet.ch/concepts/principles/continuous-architecture-principles.md): Continuous Architecture rests on principles that guide design reasoning. The facts here cover four: focus on quality attributes, delay decisions until facts exist, architect for change with small elements, and organize teams after the system design.
- [Core BPMN Element Subset](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-usage-frequency.md): Most BPMN models need only a small part of the notation. A study of 120 diagrams found that analysts share a small set of constructs. Using that core set eases modeling and reading.
- [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md): A Correlation Identifier lets a requester match a reply to the request that caused it. The replier copies the request's unique ID into a correlation ID field of the reply.
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md): Coupling describes how strongly modules depend on each other. Cohesion describes how well the parts inside one module belong together. Low coupling often goes with high cohesion.
- [Crosscutting Concept](https://arc.fuet.ch/concepts/documentation/arc42-crosscutting-concepts.md): A crosscutting concept is a practice, pattern, or rule that applies in several parts of a system. arc42 section 8 documents each one once, so the system stays consistent.
- [Data Architecture](https://arc.fuet.ch/concepts/data-architecture/data-architecture.md): Data architecture describes how an organization's data is sourced, stored, managed, integrated and protected so it supports business goals. It gives business and technical teams one shared view of data repositories, relationships and ownership.
- [Data Architecture Artifact](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-artifacts.md): Data architecture artifacts are the catalogs, matrices and diagrams that document an organization's data. Each one answers a different question: what data exists, who uses it, how it relates, and where the master copy lives.
- [Data Architecture Diagram Type](https://arc.fuet.ch/concepts/data-architecture/data-architecture-diagram-types.md): Data diagrams work at different levels of detail. A conceptual diagram names core business entities. A logical diagram adds keys and attributes. A physical model fits one specific database.
- [Data architecture documentation in arc42](https://arc.fuet.ch/concepts/documentation/data-architecture-documentation-in-arc42.md): In arc42, data topics have several homes. Data flows go in the business context, data structures can appear as building blocks, and domain terms go in the glossary. A domain data model can also sit in the crosscutting concepts.
- [Data Architecture Inputs](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-inputs.md): Data architecture inputs are the materials TOGAF's Phase C gathers before designing the target data architecture. The facts here name the project scope document, reference materials, and data principles.
- [Data Architecture Principle](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-principle.md): A data architecture principle is a short, high-level rule for how an organization treats its data. Typical examples: data is shared, accessible, and secure, and each data element has an accountable trustee.
- [Data Entity/Business Function Matrix](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-business-function-matrix.md): A Data Entity/Business Function Matrix links data entities to business functions. Each cell uses CRUD codes (create, read, update, delete) to show how a function uses an entity. It helps spot unclear ownership.
- [Data Entity/Data Component Catalog](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-data-component-catalog.md): A data entity catalog is a master list of an organization's data entities. Each entry records the entity's definition, owner, classification and system of record, so teams share one view of the data.
- [Data Exchange between BPMN Processes](https://arc.fuet.ch/concepts/modeling-bpmn/data-exchange-between-bpmn-processes.md): Separate BPMN processes sit in separate pools. They exchange data in two ways: messages sent across pools, or a shared data store that one process writes and another reads. The store keeps writer and reader independent.
- [Data reusability and standardized access](https://arc.fuet.ch/concepts/data-architecture/data-reusability-and-standardized-access.md): Systems should expose their data in a shared, standardized form so other teams can reuse it without heavy cleanup. Common tools are data products, agreed identifiers, and a canonical data model.
- [Datatype Channel](https://arc.fuet.ch/concepts/integration/datatype-channel.md): A Datatype Channel gives each type of data its own message channel. The sender picks the channel that matches the data. The receiver knows the type from the channel it reads.
- [DDD Building Blocks (Tactical Patterns)](https://arc.fuet.ch/concepts/domain-driven-design/ddd-modeling-elements.md): DDD building blocks are modeling elements: entities, value objects, aggregates, domain events, domain services and repositories. They align code with business problems and share business vocabulary.
- [Dead Letter Channel](https://arc.fuet.ch/concepts/integration/dead-letter-channel.md): A Dead Letter Channel is a side queue for messages a messaging system cannot deliver or process. Failed messages wait there to be inspected, fixed and resubmitted instead of being lost.
- [Deadlock in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/deadlock-in-process-models.md): A deadlock is a control-flow error in a process model. A parallel join waits for a token that never arrives, so the instance stalls and never finishes. Matching split and join gateway types prevents it.
- [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md): Architectural decisions depend on each other. One decision can trigger or split into others. Recording these links helps teams see which decisions to make early and where follow-on work comes from.
- [Decision Model and Notation](https://arc.fuet.ch/concepts/modeling-bpmn/decision-model-and-notation.md): DMN is a standard for modeling business decisions. It pairs a graphical notation with an expression language, so business users can read decisions and a decision engine can run them alongside a BPMN process.
- [Define Target Data Architecture Method Phase](https://arc.fuet.ch/concepts/data-architecture/define-target-data-architecture-method-phase.md): This phase defines the major data types and data sources a business needs. It works at the level of data entities, not storage design. Its results feed matrices, gap analysis and arc42 documentation.
- [Definition of Done for Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/definition-of-done-for-architectural-decisions.md): A Definition of Done for architectural decisions lists the conditions that must hold before a team calls a decision finished. The ecADR proposal uses five: evidence, criteria, agreement, documentation, and realization and review.
- [Degrees of BPM Maturity](https://arc.fuet.ch/concepts/modeling-bpmn/degrees-of-bpm-maturity.md): Processes can be automated to different degrees, from steps with people involved to straight-through processing with no human at all. RPA and AI agents help move a process along, and each degree needs matching support in the architecture.
- [Delegation Connector](https://arc.fuet.ch/concepts/modeling-uml/delegation-connector.md): A delegation connector passes a component's external port inward to an internal part that does the real work. Outsiders see one contract, and the internal structure stays hidden.
- [Deployment Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/deployment-diagram-modeling-mistakes.md): Deployment diagrams go wrong in a few repeated ways: deploying the wrong kind of element, mixing up node types, leaving connections unnamed, and leaving configuration unattached. Each has a simple fix.
- [Deployment View](https://arc.fuet.ch/concepts/documentation/distribution-view.md): The deployment view shows which hardware and environments run the system's building blocks. arc42 documents it because infrastructure affects the system, and it suggests UML deployment diagrams.
- [Deriving System Components from the Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/deriving-system-components-from-the-domain-model.md): Building blocks can be found by studying the domain model. Concepts that belong together form a component, and cohesion guides the grouping. Parts owned by other teams are kept apart and marked as external.
- [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md): Design for change means making the parts of a system that are likely to change easy to modify. Apply it only where change is foreseeable, because flexibility costs effort and can make other changes harder.
- [Diagram Metadata in PNG (drawio.png)](https://arc.fuet.ch/concepts/documentation/diagram-metadata-in-png-drawio-png.md): A .drawio.png file is a normal PNG image that also carries its own draw.io diagram source. You can show it in documentation and reopen it for editing. Plain XML or SVG files suit Git better.
- [Diagrams as Code](https://arc.fuet.ch/concepts/documentation/diagrams-as-code.md): Diagrams as code means writing architecture diagrams as plain text. A toolchain renders the text into pictures. Teams can then store, compare, and build diagrams like source code.
- [Differences between Class, Component and Package Diagrams](https://arc.fuet.ch/concepts/modeling-uml/class-component-and-package-diagram-differences.md): Component and package diagrams both show building blocks and can express hierarchies, because components and packages can be nested. Each one connects or groups blocks in a different way. Both fit the arc42 building block view.
- [Distribution View Antipatterns](https://arc.fuet.ch/concepts/documentation/distribution-view-antipatterns.md): A deployment view shows how software maps onto hardware and infrastructure. Reviewers should check three things: the mapping, the environments covered, and whether infrastructure nodes appear.
- [Documentation as Code](https://arc.fuet.ch/concepts/documentation/documentation-as-code.md): Documentation as code means writing documentation with the same tools and workflows as software: plain-text markup, Git, code review, and automated builds. Docs become versioned, reviewable, and publishable by tools.
- [Domain Event](https://arc.fuet.ch/concepts/domain-driven-design/domain-event.md): A domain event records something that happened in the business and that other parts of the domain need to know about. It is named in the past tense, never changes, and can trigger reactions in other aggregates or bounded contexts.
- [Domain Layer Separation](https://arc.fuet.ch/concepts/domain-driven-design/domain-layer.md): Domain layer separation keeps business logic in its own layer, apart from the user interface, the application layer, and technical infrastructure. Several front ends can then reuse the same logic.
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md): A domain model is a system of abstractions that describes selected aspects of a business domain. Software is built on it, and teams evolve it in code over the product's life.
- [Domain Service](https://arc.fuet.ch/concepts/domain-driven-design/domain-service.md): A domain service is a stateless object that holds business logic which does not fit naturally in one entity or value object. It often covers rules that span several entities or aggregates.
- [Domain Storytelling](https://arc.fuet.ch/concepts/domain-driven-design/domain-storytelling.md): Domain Storytelling lets domain experts describe how they work, while the group draws each story as a simple picture of actors, work objects, and activities. The drawings help business and IT people share one language.
- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md): Domain-Driven Design (DDD) is an approach for complex business software. It organizes messy domain logic into models built in software, evolved over time, and split into bounded contexts as the domain grows.
- [Domain-Driven Design of the Data Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-modeling-procedure.md): Domain-driven design of the data model builds data structures from business knowledge. Teams use business vocabulary to find entities, value objects, aggregates and bounded contexts, and they keep refining the result.
- [Dynamic Router](https://arc.fuet.ch/concepts/integration/dynamic-router.md): A Dynamic Router sends messages to recipients using rules it learns at runtime. Recipients tell the router what they want over a control channel, so the router needs no fixed list of destinations.
- [Encrypt Data](https://arc.fuet.ch/concepts/tactics/encrypt-data.md): Encrypting data scrambles it so only holders of the right key can read it. It protects stored data beyond access control and protects data moving over networks. Careful key management makes it work.
- [Energy Efficiency Tactic](https://arc.fuet.ch/concepts/tactics/energy-efficiency-tactics.md): Energy efficiency tactics are design moves that cut the energy software uses while it still does its job. They help you measure energy use, schedule work well across resources, and reduce the work each event causes.
- [Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-management.md): Enterprise architecture (EA) guides how an organization changes toward its business vision. It looks across many applications at once. Its goals are efficiency, lower cost and risk, and better alignment of business and IT.
- [Enterprise Architecture (Ross/Weill/Robertson definition)](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-ross-weill-robertson-definition.md): Enterprise architecture is the organizing logic for business processes and IT infrastructure. It follows from the company's operating model: how far its processes are integrated and standardized.
- [Enterprise Architecture Layers](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-structure-business-and-it-architecture.md): Enterprise architecture describes an organization in layers: business, data, application and technology. Higher layers use services of lower layers, and lower layers realize higher-layer elements. This lets you trace a business need down to its technical basis.
- [Enterprise Architecture Maturity Level](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-maturity-levels.md): An enterprise architecture maturity level shows how well the architecture function has developed. Judge it by the value the organization gains, and set a target that fits the organization's size and complexity.
- [Enterprise Architecture Maturity Stages](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-maturity-stages.md): Enterprise architecture maturity stages describe how a firm's architecture grows from business silos to standardized technology, optimized core, and business modularity, later extended to a digital ecosystem. Value depends on governance and learning, not stage alone.
- [Enterprise Architecture Meta Model](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-meta-model.md): An enterprise architecture meta model is a shared set of entity types and relationships for describing an organization. The TOGAF content metamodel is a key example. Teams also use it to configure EA tools and repositories.
- [Enterprise Architecture Strategy](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-strategy.md): An enterprise architecture strategy describes how an organization steers ongoing change. It starts from the current architecture, defines the desired future one, and helps architects guide others' choices as business strategy shifts.
- [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md): Enterprise Integration Patterns are named designs for connecting applications through messaging. Messaging is asynchronous, program-to-program communication with reliable delivery. Apache Camel supports most of these patterns.
- [Entity](https://arc.fuet.ch/concepts/domain-driven-design/entity.md): An entity is a domain object defined by its identity, not its attributes. Its attributes can change and it stays the same thing. Two objects with equal attributes can still be different entities.
- [Entity and Value Object](https://arc.fuet.ch/concepts/domain-driven-design/entity-vs-value-object.md): An entity is tracked by an identity that lasts even as its attributes change. A value object has no identity, is immutable, and equals another when all its values match.
- [Entity Life Cycle](https://arc.fuet.ch/concepts/domain-driven-design/entity-life-cycle.md): An entity life cycle is the path an entity follows over time, from the moment it gets an identity until it ends. Named, guarded transitions and invariants stop it from entering invalid states.
- [Envelope Wrapper](https://arc.fuet.ch/concepts/integration/envelope-wrapper.md): An Envelope Wrapper puts application data inside an envelope that the messaging system accepts. The receiver removes the envelope at the destination and gets the original data back.
- [Epic](https://arc.fuet.ch/concepts/functional-requirements/epic.md): An epic is a large user story that is too big to finish in one iteration. It holds a place for a wanted feature until the team splits it into smaller stories.
- [Errors in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/errors-in-process-models.md): Many real process models contain control-flow errors, such as deadlocks and lack of synchronization. A model counts as correct only if it has neither. A typical cause is merging parallel branches with the wrong gateway type.
- [Essential Architecture Views (Context, Component, Runtime, Distribution)](https://arc.fuet.ch/concepts/documentation/contemporary-essential-views.md): Essential architecture views show a system from four angles: its context, its building blocks, its runtime behavior, and its distribution onto hardware. Each view answers a different question for stakeholders.
- [Event Sourcing with Distributed Event Log](https://arc.fuet.ch/concepts/integration/event-sourcing-with-distributed-event-log.md): A distributed event log is a shared, append-only record of events that many applications use to exchange data. Writers add events. Readers pull them at their own pace and can replay older events until retention removes them.
- [Event-Based Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/event-based-gateway.md): An event-based gateway sends a process down one path depending on which event happens first, not on data. The first event wins, and the other events can no longer trigger.
- [Event-Driven Consumer](https://arc.fuet.ch/concepts/integration/event-driven-consumer.md): An Event-Driven Consumer waits until the messaging system hands it a message through a callback. It runs no polling loop. Arrivals set its pace, so a burst can overload it.
- [Exception Handling Tactic](https://arc.fuet.ch/concepts/tactics/exception-handling.md): Exception handling means the system reacts to a detected fault by reporting it or handling it. It is a recovery tactic for availability and follows fault detection.
- [Fault](https://arc.fuet.ch/concepts/quality-attributes/fault.md): A fault is a defect that can cause a failure. It may stay dormant until certain conditions trigger it. Teams prevent, tolerate, detect and recover from faults so users do not see failures.
- [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md): Fault detection tactics spot a problem before it grows into a failure users can see. Common techniques are ping/echo, heartbeat, monitors, time stamps, condition monitoring, voting and exception detection.
- [Fault Prevention Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-prevention.md): Fault prevention is one of three groups of availability tactics. Its tactics stop faults from happening or from turning into failures, instead of reacting afterward.
- [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md): Fault recovery tactics restore service after a fault is found. They prepare spares or retries, repair the problem, and bring repaired parts back into service.
- [Fault Tolerance](https://arc.fuet.ch/concepts/quality-attributes/fault-tolerance.md): Fault tolerance is how well a system keeps working as intended while hardware or software faults are present. It is separate from availability and recoverability, and it relies on detecting, recovering from and containing faults.
- [File Transfer](https://arc.fuet.ch/concepts/integration/file-transfer.md): File Transfer is an integration style where each application writes files of shared data and reads files that others wrote. Teams must agree on the file format and how often files are produced.
- [Fitness for Purpose](https://arc.fuet.ch/concepts/evaluation/fitness-for-purpose.md): An architecture is rarely good or bad on its own. It is fit or unfit for a purpose, and that purpose comes mostly from the context where the system will live.
- [Flexibility](https://arc.fuet.ch/concepts/quality-attributes/flexibility.md): Flexibility is a product's ability to adapt to changed requirements and contexts of use. ISO 25010:2023 splits it into adaptability, scalability, installability and replaceability.
- [Format Indicator](https://arc.fuet.ch/concepts/integration/format-identifier.md): A Format Indicator is a tag on each message that names its data format. It helps a message format cope with future change, and it is an alternative to giving every data type its own channel.
- [Foundation for Execution](https://arc.fuet.ch/concepts/enterprise-architecture/foundation-for-execution.md): A foundation for execution is the automated, digitized core of a company: IT infrastructure plus digitized business processes. It rests on an operating model, an enterprise architecture and an IT engagement model, and grows through ongoing projects.
- [Frequent Mistakes in Defining Acceptance Criteria](https://arc.fuet.ch/concepts/functional-requirements/frequent-mistakes-in-defining-acceptance-criteria.md): Acceptance criteria go wrong when they replace conversation, hide the user's goal, or drift into technical detail. Good criteria stay user-focused and testable, and they support the team's discussion of the story.
- [Functional suitability](https://arc.fuet.ch/concepts/quality-attributes/functional-suitability.md): Functional suitability is the degree to which a product provides functions that meet stated and implied needs under specified conditions. It has three parts: completeness, correctness and appropriateness.
- [Gartner Hype Cycle for Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/gartner-hype-cycle-for-enterprise-architecture.md): Gartner's Hype Cycle for Enterprise Architecture places topics in phases of rising and falling expectations. Editions show topics rising, falling and maturing. Teams can use it as one input for timing investments.
- [GenAI Support for Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/genai-support-for-architectural-decision-records.md): Teams use generative AI to draft architectural decision records (ADRs) quickly and to explore options. The output can be wrong or invented, so humans must check every ADR before it enters the record.
- [Goal Hierarchy to Component Mapping](https://arc.fuet.ch/concepts/functional-requirements/goal-hierarchy-to-component-mapping.md): A use case can carry a goal level, and its scope can range from a whole organization down to one component. Matching goals to components of similar size gives each building block a clear responsibility.
- [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md): Graceful degradation keeps a system's most important functions working when parts fail. It drops or reduces less important features instead of failing completely.
- [Guidelines for Documentation](https://arc.fuet.ch/concepts/documentation/guidelines-for-documentation.md): Write only what readers will use. Match detail to their needs, describe each thing once and reference it elsewhere, and keep the text short so people actually read it.
- [Hazard Warning](https://arc.fuet.ch/concepts/quality-attributes/hazard-warning.md): Hazard warning is a Safety quality in ISO/IEC 25010. A product with it warns operations or internal controls about unacceptable risks, so they can react.
- [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md): Heartbeat is an availability tactic for spotting failures. One component sends a message at regular intervals and another listens. If the messages stop, the listener assumes the sender failed and triggers fault correction.
- [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md): High cohesion means the parts of a module belong together and serve one focused responsibility. A change to that responsibility then stays inside one module. It works best together with low coupling.
- [History of BPMN](https://arc.fuet.ch/concepts/modeling-bpmn/history-of-bpmn.md): BPMN began at an industry group, BPMI, and reached the public as version 1.0 in May 2004. OMG took over in 2005. Version 2.0 arrived in January 2011. Version 2.0.2, from January 2014, is the latest.
- [Idempotent Receiver](https://arc.fuet.ch/concepts/integration/idempotent-receiver.md): An idempotent receiver handles the same message more than once without repeating its effect. A common way is to record the IDs of processed messages and ignore any repeat.
- [Implicit Architecture](https://arc.fuet.ch/concepts/fundamentals/architecture-facts-and-challenges.md): Every system has an architecture, even if nobody planned, documented or understood it. An unplanned architecture tends to pile up technical debt and makes the system harder to maintain.
- [Increase Cohesion](https://arc.fuet.ch/concepts/tactics/increase-cohesion.md): Increase Cohesion is one of three groups of modifiability tactics. It keeps related responsibilities together and separates unrelated ones, so future changes cost less.
- [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md): Incrementality means building and changing an architecture in small steps, with feedback after each step. It replaces designing everything at once, because requirements keep moving and not every issue can be foreseen.
- [Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md): Information hiding means splitting a system into modules that each conceal one hard or change-prone design decision. Clients use only the module's interface, so the inside can change without breaking them.
- [Installability](https://arc.fuet.ch/concepts/quality-attributes/installability.md): Installability describes how well a product can be installed and removed in a specific environment. In the 2023 wording of ISO/IEC 25010, it sits under Flexibility, next to adaptability, scalability and replaceability.
- [Instance Specification](https://arc.fuet.ch/concepts/modeling-uml/instance-specification.md): An instance specification is a UML model element that stands for one instance in a modeled system. It gives a concrete example, with attribute values, of something a class describes in general.
- [Insufficient ATAM Application](https://arc.fuet.ch/concepts/evaluation/insufficient-atam-application.md): An ATAM review is weak when its findings are not tied to specific architectural decisions, quality attributes and scenarios. Vague risks and unproven non-risks cannot be acted on or trusted.
- [Insufficient Quality as Driver of Change](https://arc.fuet.ch/concepts/quality-attributes/insufficient-quality-as-driver-of-change.md): Quality goals shape a system as much as features do. Changing one quality goal can force a different solution, so architects should state quality goals concretely and early.
- [Integrability, Deployability, Testability and Reliability Tactics](https://arc.fuet.ch/concepts/tactics/integrability-deployability-and-testability-tactics.md): Tactics are design decisions grouped by the quality goal they serve. This article covers a few: heartbeat for fault detection, plus rollback, blue/green deployment and feature toggles for safe releases.
- [Integration](https://arc.fuet.ch/concepts/integration/integration.md): Integration makes separate applications work together to deliver one unified set of functionality. Teams choose a style, keep dependencies low, and often add a translation layer where systems differ.
- [Integration Pattern vs. Middleware Technology](https://arc.fuet.ch/concepts/integration/integration-patterns-vs-middleware-technology.md): An integration pattern describes a solution without tying it to any product. Middleware is the concrete product or protocol that carries it out. Keeping the two apart lets you ask separate questions about each.
- [Integration Style](https://arc.fuet.ch/concepts/integration/integration-pattern.md): An integration style is the basic way separate applications are connected so they can share data and behavior. The classic options are file transfer, shared database, remote procedure call and messaging. Teams choose one deliberately.
- [Integration Styles](https://arc.fuet.ch/concepts/integration/integration-styles-overview.md): Applications can be connected in four basic ways: exchanging files, sharing a database, calling each other's procedures remotely, or sending messages. Each style has its own strengths and weaknesses, so you choose per integration point.
- [Integrity](https://arc.fuet.ch/concepts/quality-attributes/integrity.md): Integrity means a system protects its state and data from unauthorized modification or deletion. It is one of several security sub-characteristics in ISO/IEC 25010, alongside confidentiality, non-repudiation, accountability and authenticity.
- [Interface Segregation Principle](https://arc.fuet.ch/concepts/principles/interface-segregation-principle.md): The Interface Segregation Principle says code should not depend on methods it does not use. Teams split large interfaces into smaller ones, each fitted to one role.
- [Intermediate Event](https://arc.fuet.ch/concepts/modeling-bpmn/intermediate-event.md): An intermediate event sits inside a process flow, between start and end. Throwing events (filled icon) fire a trigger. Catching events (white icon) make the process wait until a trigger occurs.
- [Interoperability](https://arc.fuet.ch/concepts/quality-attributes/interoperability.md): Interoperability is how well separate systems can exchange information and then use it. It depends on shared formats and shared meaning. Open standards help, and translators bridge the gaps that remain.
- [Interoperability Scenario](https://arc.fuet.ch/concepts/quality-attributes/interoperability-scenario.md): An interoperability scenario is a fixed template that describes how one system asks another to exchange information, and what should happen next. It turns a vague goal into a testable requirement.
- [Invalid Message Channel](https://arc.fuet.ch/concepts/integration/invalid-message-channel.md): An Invalid Message Channel is a dedicated channel where a receiver puts messages it cannot process. The receiver handles bad messages gracefully, and people can inspect them later.
- [INVEST Applied to Architectural Work](https://arc.fuet.ch/concepts/functional-requirements/invest-applied-to-architectural-work.md): INVEST is a checklist for writing good user stories. Applied to architectural work, it fits unevenly: value and testability carry over well, while independence is doubtful because architectural goals and components depend on each other.
- [INVEST Criteria](https://arc.fuet.ch/concepts/functional-requirements/invest-criteria.md): INVEST is a six-point checklist for judging a user story: Independent, Negotiable, Valuable, Estimable, Small, Testable. Teams use it to check a story before planning, and to check the story they are about to split.
- [ISO/IEC 25010 Product Quality Model](https://arc.fuet.ch/concepts/quality-attributes/iso-iec-25010-quality-model.md): ISO/IEC 25010 is a standard that sorts software product quality into named characteristics and subcharacteristics. The 2023 edition has nine characteristics. It gives teams a shared vocabulary for specifying quality.
- [ISO/IEC 25010 Quality Models and Their Target Entities](https://arc.fuet.ch/concepts/quality-attributes/quality-models-and-their-target-entities.md): ISO/IEC 25010 and its sibling standards give separate quality models for different targets: an ICT product, data, or an IT service. Pick the model that matches what you are judging.
- [ISO/IEC 25010:2023 Product Quality Model Revision](https://arc.fuet.ch/concepts/quality-attributes/iso-25010-2023-revision.md): The 2023 revision of ISO/IEC 25010 renames Usability to Interaction Capability. It also replaces some sub-characteristics and adds others, such as Resistance under Security and Scalability under Flexibility.
- [ISO/IEC/IEEE 42010 Architecture Description Model](https://arc.fuet.ch/concepts/documentation/iso-iec-ieee-42010-architecture-description-model.md): The 42010 conceptual model separates a system's architecture from the document that describes it. The description is built from views. Each view follows a viewpoint, and each viewpoint frames stakeholder concerns.
- [ISO/IEC/IEEE 42010 Architecture Description Standard](https://arc.fuet.ch/concepts/documentation/iso-iec-ieee-42010-architecture-description-standard.md): ISO/IEC/IEEE 42010 is an international standard for describing architectures. It separates a system's architecture from its description, and it builds the description from views and viewpoints.
- [IT Component Catalogue](https://arc.fuet.ch/concepts/enterprise-architecture/it-component-catalogue.md): An IT component catalogue lists the technology components a company uses and gives each a status. Linking components to applications shows which to keep, approve, or retire.
- [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md): Iterative and incremental development builds a system in complete pieces and refines it over repeated cycles. Teams deliver value early, get feedback, and adapt. Continual refactoring keeps the growing system orderly.
- [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md): Iterative domain modeling means a domain model starts simple and improves over time. The team builds it in code, learns more about the domain, and revises model and code together.
- [Keep It Working](https://arc.fuet.ch/concepts/fundamentals/keep-it-working.md): Keep It Working means changing software in small, safe steps so a working version always exists. It suits systems that need maintenance but would be risky to overhaul in one go.
- [Kroki](https://arc.fuet.ch/concepts/documentation/kroki.md): Kroki is an open-source service that offers one HTTP API for creating diagrams from text, across many diagram libraries. You can use the free public service or run your own instance.
- [Lack of Synchronization](https://arc.fuet.ch/concepts/modeling-bpmn/lack-of-synchronization-in-process-models.md): A lack of synchronization happens when parallel branches are merged by an exclusive (XOR) join. Nothing waits for the other branches, so the work after the merge runs once per branch instead of once.
- [Lambda Architecture](https://arc.fuet.ch/concepts/styles-patterns/lambda-architecture.md): Lambda architecture sends incoming data down two paths. A slow batch path gives accurate results. A fast speed path gives quick, less accurate results. Queries combine both, at the cost of duplicated logic.
- [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md): The last responsible moment is the point where not deciding would remove an important option. Teams delay commitment until then. Waiting past the right moment is also harmful, so timing needs care.
- [Layered Architecture](https://arc.fuet.ch/concepts/styles-patterns/layered-architecture.md): Layered architecture splits a system into layers with separate responsibilities. A higher layer may use a lower one, never the reverse. This keeps dependencies orderly and makes parts easier to change, test and reuse.
- [Layers and Components Decomposition](https://arc.fuet.ch/concepts/styles-patterns/layers-and-components-decomposition.md): Layers and components split a system two ways. Layers stack by kind of work, and upper layers use lower ones. Components are vertical slices that each cover one function. Together they form a grid.
- [Layers Pattern](https://arc.fuet.ch/concepts/styles-patterns/layers-pattern.md): The Layers pattern splits software into layers with separate responsibilities. A higher layer may use a lower layer, never the reverse. This keeps dependencies under control, at the cost of some latency and pass-through work.
- [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md): Architectural decisions are made at several organizational levels. Higher levels decide less and mainly set guidelines. Development teams make most decisions, so sharing them openly keeps the architecture sound.
- [Levels of Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/levels-of-process-modeling.md): Process models work best in levels. The top level shows the big picture, the middle level breaks it into subprocesses, and the lowest level shows detailed activities. Each level suits a different audience.
- [Lightweight Approach for Software Reviews (LASR)](https://arc.fuet.ch/concepts/evaluation/lightweight-approach-for-software-reviews-lasr.md): LASR is a lightweight way to review a software system. A small team runs a short, game-like workshop. It checks the system against quantified quality goals and gives first results within hours.
- [Lightweight ATAM](https://arc.fuet.ch/concepts/evaluation/lightweight-atam.md): A lightweight ATAM is a shortened form of the full Architecture Tradeoff Analysis Method. It uses fewer people and simpler steps to deliver results in about a day, but it finds fewer risks.
- [Link Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-link-event.md): A link event pair replaces one sequence flow in a BPMN diagram. A throwing link is the exit, and a catching link with the same name is the re-entrance. It adds no business meaning and only keeps diagrams readable.
- [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md): A load balancer spreads incoming requests across several backend servers. It uses resources evenly, helps keep response times low, avoids overload, and can hide a failed server from clients.
- [Logical Data Model](https://arc.fuet.ch/concepts/data-architecture/logical-data-model.md): A logical data model defines the structure of business data (entities, keys, relationships) without naming any database engine. It sits between the conceptual model and the physical model.
- [Logical vs. physical data model](https://arc.fuet.ch/concepts/data-architecture/logical-vs-physical-data-model.md): A logical data model describes business data without tying it to any database. A physical data model refines it for one specific database, adding names, data types, keys and indexes. One logical model can yield several physical designs.
- [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md): Loose coupling means building blocks depend on each other as little as possible, so a change in one rarely forces a change in another. The right level depends on how much control you have over both sides.
- [Main Sequence (Balance of Abstractness and Instability)](https://arc.fuet.ch/concepts/principles/main-sequence.md): The main sequence is an ideal line on a chart that plots how abstract a software component is against how unstable it is. Components are judged by their distance from that line.
- [Maintainability](https://arc.fuet.ch/concepts/quality-attributes/maintainability.md): Maintainability is how effectively and efficiently people can modify a product to improve it, correct it, or adapt it to a new environment or new requirements.
- [Markdown Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/markdown-architectural-decision-records-madr.md): MADR is a short Markdown template for recording architecturally significant decisions in a structured way. Each decision is one file in docs/decisions. Full, minimal, and bare versions exist.
- [Matching Diagram Type to System Aspect](https://arc.fuet.ch/concepts/modeling-uml/matching-diagram-type-to-system-aspect.md): No single diagram shows every aspect of a system. Pick the diagram type that fits the aspect you want to show and the audience, then combine a few complementary diagrams.
- [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md): A message channel is a pipe between applications. One application writes messages into it, and another reads them out. The sender does not need to know the receiver. Channel types cover delivery, message types, errors, and durability.
- [Message Filter](https://arc.fuet.ch/concepts/integration/message-filter.md): A Message Filter checks each message against a condition on its content. Matching messages move on and the rest are discarded, so a component avoids receiving messages it does not care about.
- [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md): Message routing patterns decide where each message goes, so a sender does not need to know the final recipient. Examples are the Content-Based Router, Recipient List, Aggregator, Scatter-Gather and Routing Slip.
- [Message Sequence](https://arc.fuet.ch/concepts/integration/message-sequence.md): Message Sequence splits data that is too big for one message into several smaller messages. Each message carries a position, so the receiver can put the parts back in order and rebuild the whole.
- [Message Structure](https://arc.fuet.ch/concepts/integration/message-structure.md): A message has a body that carries the data and a header that carries information for the messaging system. Header fields such as a correlation ID and a return address let a reply find its way back to the right request.
- [Message Translator](https://arc.fuet.ch/concepts/integration/message-translator.md): A Message Translator is a special filter that converts messages from one data format to another. It lets systems with different formats communicate through messaging.
- [Message Types in Sequence Diagrams](https://arc.fuet.ch/concepts/modeling-uml/message-types-in-sequence-diagrams.md): A message in a sequence diagram is one step of communication between participants. The key distinction is whether the sender waits: a synchronous sender waits until the work is done, an asynchronous sender keeps going.
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md): Messaging connects applications through a shared messaging system. Applications exchange small messages instead of calling each other directly, and sender and receiver need not be running at the same time.
- [Messaging Protocol Support in Message Brokers](https://arc.fuet.ch/concepts/integration/messaging-systems-and-protocols.md): Message brokers speak different wire protocols, the formats clients use to talk to them. Some brokers support several protocols natively or through plugins. Protocol support decides which clients can connect.
- [Microkernel Pattern](https://arc.fuet.ch/concepts/styles-patterns/microkernel-pattern.md): A microkernel keeps only the most basic mechanisms in a small core. Everything else runs outside it as ordinary programs. This can help stability, but it costs performance.
- [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md): Microservices split a system into small services, each built around one business capability and deployable on its own. The style gains team autonomy and flexibility, but it adds network, data, and operations costs.
- [Model vs. View](https://arc.fuet.ch/concepts/documentation/model-vs-view.md): A model is structured data holding the elements of an architecture and how they relate. A view is a diagram built on top of that model. Each view serves the concerns of certain stakeholders.
- [Model-View-Controller Pattern](https://arc.fuet.ch/concepts/styles-patterns/model-view-controller-pattern.md): MVC splits an interactive application into a model (the domain), views (output) and controllers (input). Keeping presentation apart from the domain lets several views show the same data.
- [Modeling Method](https://arc.fuet.ch/concepts/documentation/modeling-method.md): A modeling method is a short set of team agreements on how to draw architecture models. It keeps diagrams consistent, readable, and limited to what matters.
- [Modeling Tool vs. Drawing Tool](https://arc.fuet.ch/concepts/modeling-uml/modeling-tool-vs-drawing-tool.md): A modeling tool keeps one shared model and draws diagrams from it. A drawing tool makes separate pictures. The choice decides how much work it takes to keep diagrams consistent and correct.
- [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md): Modifiability describes how well a system can be changed. Architects steer it by adjusting coupling, cohesion, and cost, using architectural tactics.
- [Modifiability Scenario](https://arc.fuet.ch/concepts/quality-attributes/modifiability-scenario.md): A modifiability scenario turns a vague wish like "easy to change" into one concrete change request with a measurable limit, such as effort in person-weeks. You can then check whether the architecture meets it.
- [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md): Modifiability tactics are design decisions that keep the cost of changes low. They fall into three groups: increase cohesion, reduce coupling, and defer binding.
- [Modifiability Tactics in SOA](https://arc.fuet.ch/concepts/tactics/modifiability-tactics-in-soa.md): In service-based systems, intermediaries such as message buses, publish-subscribe channels, and registries sit between providers and consumers. Each side can then change without breaking the other, at some cost to performance and security.
- [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md): Modularity means dividing a system into self-contained building blocks. The quality of the split depends on the criteria used to divide the system, so modularity is a design issue.
- [Module](https://arc.fuet.ch/concepts/domain-driven-design/module.md): A module groups related domain concepts so people can understand one group at a time. Choose modules by meaning, not by technical category, and give them names the whole team uses.
- [Motivation for Architecture Documentation](https://arc.fuet.ch/concepts/documentation/motivation-for-architecture-documentation.md): Code shows what a system does, but not why it was built that way. Architecture documentation records those reasons, so knowledge does not stay locked in a few people's heads.
- [Nested Components and Subsystems](https://arc.fuet.ch/concepts/modeling-uml/nested-components-and-subsystems.md): A component can contain smaller parts that work together inside it. Ports on its edge pass outside requests to those parts. This lets you describe a system level by level, from a coarse view to detail.
- [Nonrepudiation](https://arc.fuet.ch/concepts/quality-attributes/nonrepudiation.md): Nonrepudiation means actions can be proven to have happened, so an author cannot successfully deny a message or a contract. Digital signatures and trusted third parties are the usual tools.
- [Normalizer](https://arc.fuet.ch/concepts/integration/normalizer.md): A Normalizer handles messages that mean the same thing but arrive in different formats. A router sends each message to a matching translator, so later steps deal with only one format.
- [Open-Closed Principle](https://arc.fuet.ch/concepts/principles/open-closed-principle.md): A building block stays open to new behavior but closed to edits of its existing code. Other parts rely on a fixed interface, and new behavior arrives through new implementations of it.
- [Operating Model](https://arc.fuet.ch/concepts/enterprise-architecture/operating-model.md): An operating model describes how a company delivers value. It sets the needed level of process standardization and integration, and that level tells architects which process and IT capabilities matter most.
- [Operational Constraint](https://arc.fuet.ch/concepts/quality-attributes/operational-constraint.md): Operational constraint is a safety quality in ISO/IEC 25010. It describes a product that keeps its operation within safe parameters or states when it meets an operational hazard.
- [Operational Value Stream](https://arc.fuet.ch/concepts/enterprise-architecture/operational-value-stream.md): An operational value stream is a high-level, end-to-end set of stages. It starts when a stakeholder has a need and ends when that need is met. It shows how an organization delivers a product or service to a customer.
- [Package Diagram](https://arc.fuet.ch/concepts/modeling-uml/package-diagram.md): A package diagram groups related model elements into packages, each a namespace with unique names. It shows how packages depend on each other, so you can see a system's structure, such as its layers, at a glance.
- [Package Diagram Modeling Mistake](https://arc.fuet.ch/concepts/modeling-uml/package-diagram-modeling-mistakes.md): Package diagrams go wrong in a few typical ways: cycles between packages, unlabeled relationships, wrong containment, and misused merges. Avoiding them keeps the structure readable and easier to change.
- [Package Relationships (Import, Access, Merge, Use)](https://arc.fuet.ch/concepts/modeling-uml/package-relationships-import-access-merge-use.md): Package relationships are directed links between packages that show how their contents are shared. Import and merge are covered here. A dependency with no label is read as an import, so label every one.
- [Patterns for API Design](https://arc.fuet.ch/concepts/integration/patterns-for-api-design.md): Patterns for API Design is a pattern language for remote APIs. It sorts patterns into five categories and treats each choice as a decision with options and criteria. Its focus is the messages that APIs exchange.
- [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md): Performance efficiency is a workload's ability to handle rising load without hurting user experience, and to use fewer resources when demand is low. Teams should consider it from the start and verify it by measuring.
- [Performance Efficiency Scenario](https://arc.fuet.ch/concepts/quality-attributes/performance-scenario.md): A performance efficiency scenario turns a vague goal like "be fast" into a testable statement. Something triggers the system, the system reacts, and a measurable criterion says whether the reaction was good enough.
- [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md): Performance tactics are design decisions that help a system answer requests fast enough. They work in two ways: limiting the demand placed on the system, or managing the available resources better.
- [Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/physical-data-model.md): A physical data model describes how data is stored in one specific database product. It defines keys, indexes, and storage settings, and it may bend the logical design for speed.
- [Ping/Echo](https://arc.fuet.ch/concepts/tactics/ping-echo.md): Ping/echo checks whether a component is alive. One part sends a request and waits for a reply. If no echo arrives within a set time, the sender declares a failure.
- [Pipe-and-Filter](https://arc.fuet.ch/concepts/styles-patterns/pipe-and-filter-pattern.md): Pipe-and-Filter splits a big processing job into small, independent steps called filters. Pipes pass each step's output to the next. You can add, remove, or reorder steps, but all steps must agree on the data format.
- [Pipes and Filters](https://arc.fuet.ch/concepts/styles-patterns/pipes-and-filters.md): Pipes and Filters splits a large processing task into small, independent steps called filters. Pipes pass each step's output to the next. You can add, remove, or reorder steps, but the slowest step limits speed.
- [Placing ATAM Evaluation in arc42](https://arc.fuet.ch/concepts/evaluation/placing-atam-evaluation-in-arc42.md): arc42 section 11 normally lists risks and technical debt. An ATAM-based variant replaces it with an evaluation section that records the risks, sensitivity points and trade-off points found during an ATAM evaluation.
- [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md): A Point-to-Point Channel makes sure only one receiver gets each message. If several receivers share the channel, they compete, and each message goes to just one of them.
- [Polling Consumer](https://arc.fuet.ch/concepts/integration/polling-consumer.md): A Polling Consumer asks a channel for the next message when it is ready, instead of waiting to be handed one. The consumer starts every retrieval, so it decides when to take work.
- [Port](https://arc.fuet.ch/concepts/modeling-uml/component-port.md): A port is a named interaction point on the edge of a UML class, part, or component. It is where the owner offers services to its surroundings and makes requests of them.
- [Principles Influencing EAI Pattern Selection](https://arc.fuet.ch/concepts/integration/principles-influencing-eai-pattern-selection.md): Pick an integration style by asking how tightly it ties applications together. Prefer styles that keep mutual dependencies low, so one application can change without breaking the others.
- [Process Analysis](https://arc.fuet.ch/concepts/modeling-bpmn/process-analysis.md): Process analysis turns a business process into a BPMN model by working through ordered questions: where it starts and ends, what steps occur, which paths exist, who takes part, and what is exchanged.
- [Process Analysis and Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/purpose-of-process-analysis-and-modeling.md): Process analysis and modeling draws a picture of how work gets done. Notations such as BPMN and EPC make that picture shared and precise. BPMN models can also be turned into software.
- [Process Automation Magnifies Efficiency](https://arc.fuet.ch/concepts/principles/process-automation-magnifies-efficiency.md): Automation speeds up whatever process it is given, good or bad. Fix or remove wasteful steps first, then automate. Otherwise software only makes the waste run faster.
- [Process Manager](https://arc.fuet.ch/concepts/integration/process-manager.md): A Process Manager is a central component that tracks the state of a process and decides the next processing step. It fits cases where the needed steps are not known in advance.
- [Process Mining](https://arc.fuet.ch/concepts/modeling-bpmn/process-mining.md): Process mining is a family of techniques that analyze event data from information systems. It shows how a process actually runs, not how people believe it runs, and helps improve it.
- [Process Model Complexity](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-complexity.md): A process model can be correct and complete yet too complicated to read. Larger models are harder to understand. Splitting them into subprocesses, limiting data objects, and following guidelines help.
- [Process Model versus Process Instance](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-versus-process-instance.md): A process model is the blueprint of a business process. A process instance is one run of it, tracked by a token and identified by a unique key.
- [Process Notations Comparison (EPC, BPMN, UML Activity Diagram)](https://arc.fuet.ch/concepts/modeling-bpmn/process-notations-comparison.md): EPC, UML activity diagrams, and BPMN can describe the same process with different elements. Most EPC elements have a clear BPMN equivalent, so conversion follows rules, but the result usually needs manual cleanup.
- [Provided and Required Interface](https://arc.fuet.ch/concepts/modeling-uml/provided-and-required-interface.md): A provided interface lists what a component offers. A required interface lists what it needs from others. UML draws them as a ball and a socket, which makes the dependencies between building blocks visible.
- [Publish-Subscribe Pattern](https://arc.fuet.ch/concepts/styles-patterns/publish-subscribe-pattern.md): Publish-subscribe lets a sender announce events without knowing who receives them. A broker or event bus copies each event to every interested subscriber. Senders and receivers stay independent, at the cost of latency, weaker ordering, and harder tracing.
- [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md): A publish-subscribe channel gives every interested subscriber its own copy of each message. The sender does not know who the receivers are, so senders and receivers stay decoupled.
- [Publishing the conceptual data model](https://arc.fuet.ch/concepts/data-architecture/publishing-the-conceptual-data-model.md): Publishing the conceptual data model makes it available to everyone as a shared glossary. Someone must own it, and it must change as the team's understanding of the domain grows.
- [Quality Attribute](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute.md): A quality attribute describes how well a system meets stakeholder needs, such as speed or security. Teams write them as specific, measurable scenarios because they strongly shape architectural decisions.
- [Quality Attribute Coverage in Bass et al.](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-coverage-in-bass-et-al.md): The Bass et al. model of quality attributes is much smaller than ISO 25010, with 10 top-level areas. It covers topics the 2011 ISO standard lacks, such as deployability and safety, and it has no chapter on compatibility.
- [Quality Attribute Prioritization](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-prioritization.md): Teams cannot maximize every quality at once, so they pick the few that matter most and rank them. arc42 asks for the top three, at most five, shown with concrete scenarios.
- [Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/quality-attribute-scenario.md): A quality attribute scenario turns a vague quality wish into a specific, measurable statement. It lets a team decide whether the system meets the requirement.
- [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md): Improving one quality of a system usually costs another. Architects weigh these conflicts, rank what matters most to stakeholders, and improve the design step by step.
- [Quality attributes in use case descriptions](https://arc.fuet.ch/concepts/quality-attributes/quality-attributes-in-use-case-descriptions.md): Most quality requirements belong to one specific use case. Write them in that use case, then refine them into measurable quality attribute scenarios. This also shows which conditions the use case left unstated.
- [Quantifying Recovery and Availability Trade-offs](https://arc.fuet.ch/concepts/quality-attributes/quantifying-recovery-and-availability-trade-offs.md): You can estimate availability from how often a part fails and how fast it is repaired. Redundancy raises that estimate, but cost, takeover time, and slow responses pull the other way.
- [RACI Matrix](https://arc.fuet.ch/concepts/forces-decisions/raci-matrix.md): A RACI matrix lists, for each task or decision, who is Responsible, Accountable, Consulted and Informed. It shows who does the work, who answers for it, who gives input and who is told.
- [Reasons for Architectural Tactics](https://arc.fuet.ch/concepts/tactics/reasons-for-architectural-tactics.md): Patterns rarely fit a design context perfectly. Tactics are smaller building blocks that help architects adapt a pattern and reason about one quality goal at a time.
- [Recipient List](https://arc.fuet.ch/concepts/integration/recipient-list.md): Recipient List is a routing pattern for sending one message to a list of recipients that is decided dynamically. Apache Camel offers it, and Scatter-Gather can use it to send requests.
- [Recoverability](https://arc.fuet.ch/concepts/quality-attributes/recoverability.md): Recoverability is how well a system gets its affected data back after an interruption or failure. Teams express it with recovery-time and data-loss targets, and improve it by cutting recovery time, for example through failover.
- [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md): Reduce Coupling is a group of modifiability tactics. They lower the dependencies between modules, so a change in one module breaks fewer of the others.
- [Redundant Spare](https://arc.fuet.ch/concepts/tactics/redundant-spare.md): A redundant spare is a duplicate component that takes over when the primary fails. Hot, warm, and cold spares differ in how fast they take over. Faster recovery costs more and adds complexity.
- [Refactoring](https://arc.fuet.ch/concepts/fundamentals/refactoring.md): Refactoring changes the inside of software in small steps without changing what it does. It keeps the design easy to change and slows the decay that sets in when teams skip it.
- [Refining Complex Context Views](https://arc.fuet.ch/concepts/vision-stakeholders/refining-complex-context-views.md): A complex system context stays readable when the top-level diagram remains a simple overview. Many external systems are grouped by clear criteria, and the detail of each interface, business and technical, is described separately.
- [Reflecting the Business Domain in the Architecture](https://arc.fuet.ch/concepts/domain-driven-design/reflecting-the-business-domain-in-the-architecture.md): Architecture works better when it follows the business domain. Teams use the business's own words, let domain experts correct those words, and split large domains into bounded contexts instead of forcing one model.
- [Relationship between Enterprise Architecture and Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/relationship-between-enterprise-architecture-and-application-architecture.md): Enterprise architecture sets organization-wide constraints that limit application architects' choices. Influence also runs back: application decisions affect enterprise architecture. Concerns spanning several applications need a clear split of responsibility.
- [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.md): A tactic is a single design decision that influences one quality attribute response. A pattern is a solution to a recurring problem. Patterns are made of smaller tactic-level decisions, like molecules from atoms.
- [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md): Architecture principles support one another. Based on the verified facts: high cohesion tends to bring low coupling, and low coupling signals a well-structured system that avoids rigidity.
- [Reliability](https://arc.fuet.ch/concepts/quality-attributes/reliability.md): Reliability is how well a system performs its specified functions under specified conditions. ISO 25010 splits it into faultlessness, availability, fault tolerance and recoverability. The 2023 version adds a time period without interruptions and failures.
- [Remote Procedure Call](https://arc.fuet.ch/concepts/integration/remote-procedure-call.md): Remote Procedure Call lets one application run a procedure in another application across a network. It looks like a local call but behaves differently: it is slower, can fail, and needs careful interface design.
- [Replaceability](https://arc.fuet.ch/concepts/quality-attributes/replaceability.md): Replaceability is how well one product can take over from another specified product for the same purpose in the same environment. It lowers lock-in risk, but a replacement's equivalence must be tested, not assumed.
- [Request-Reply](https://arc.fuet.ch/concepts/integration/request-reply.md): Request-Reply lets a requestor send a message on one channel and get the answer on another. A correlation ID or a return address tells the requestor which reply belongs to which request.
- [Requirement Types and Documents (Wiegers/Beatty)](https://arc.fuet.ch/concepts/functional-requirements/requirement-types-and-documents.md): Requirements exist at different levels: business, user and system. Business requirements go into a vision and scope document. The SRS holds functional and nonfunctional requirements. arc42 sections 1, 2 and 10 reuse them.
- [Requirements and Means Influence Architecture](https://arc.fuet.ch/concepts/fundamentals/requirements-and-means-influence-architecture.md): Requirements shape architecture, and constraints limit the architect's choices. Architects need to know which decisions are free and which are bound, and they need to learn key stakeholders' quality goals early.
- [Requirements Difficulty and Customer Engagement](https://arc.fuet.ch/concepts/functional-requirements/requirements-difficulty-and-customer-engagement.md): Deciding exactly what to build is the hardest part of software work, and clients cannot specify it fully up front. Frequent customer contact, such as reviews and daily collaboration, corrects direction early.
- [Requirements Trawling](https://arc.fuet.ch/concepts/functional-requirements/requirements-elicitation.md): Requirements trawling means gathering requirements with several techniques, expecting that you will not find them all. Some requirements are overlooked and some only appear during building, so teams look actively and early.
- [Requirements-Decision Modeling for Cyber-Physical Systems of Systems](https://arc.fuet.ch/concepts/forces-decisions/requirements-decision-modeling-for-cyber-physical-systems-of-systems.md): ReDeMo is a formal model that links non-functional requirements (qualities such as sustainability) to architectural decisions for cyber-physical systems. It comes from the TaSSAreCt research project and is built into a SysML v2-based toolchain for architects.
- [Resistance](https://arc.fuet.ch/concepts/quality-attributes/resistance.md): Resistance is how well a system keeps operating while a malicious actor attacks it. ISO/IEC 25010 lists it as a security sub-characteristic. It is about withstanding attacks, not only blocking them.
- [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md): Responsibility allocation assigns tasks and knowledge to parts of a system. Functionality alone does not fix the design, so quality requirements steer which allocation the architect picks.
- [Retry](https://arc.fuet.ch/concepts/tactics/retry.md): Retry repeats a failed call after a delay, assuming the fault is temporary. It needs a cap on attempts, growing delays, and care with operations that are unsafe to run twice.
- [Return Address](https://arc.fuet.ch/concepts/integration/return-address.md): A Return Address is a reply destination carried inside the request message. The replier reads it and sends the answer there, so it never needs to know in advance who is asking.
- [Reusability](https://arc.fuet.ch/concepts/quality-attributes/reusability.md): Reusability is how well something you built, such as code or a design, can serve in more than one system. You can reuse by copying or by depending on shared code. Each way has costs and risks.
- [Risk Identification and Safe Integration](https://arc.fuet.ch/concepts/quality-attributes/risk-identification.md): Risk identification is a product's ability to spot events or operations that could put people, property or the environment at unacceptable risk. Safe integration is its ability to stay safe during and after joining with other components.
- [Risk Storming](https://arc.fuet.ch/concepts/evaluation/risk-storming.md): Risk storming is a quick, collaborative way to find and show risks in an architecture. The team rates each risk by probability and impact, then tackles the highest-priority ones first.
- [Role of the Software Architect](https://arc.fuet.ch/concepts/fundamentals/architect-knowledge-and-tasks.md): A software architect makes the big design decisions for a system and leads the teams that build it. The role needs technical skill, communication skill, and hands-on involvement in delivery.
- [Routing Slip](https://arc.fuet.ch/concepts/integration/routing-slip.md): A Routing Slip is a list attached to a message that names the processing steps it must visit, in order. Each step reads the slip and passes the message on, so every message can follow its own path.
- [Rules of Thumb for Modeling](https://arc.fuet.ch/concepts/documentation/rules-of-thumb-for-modeling.md): Readable diagrams follow a few habits. Give each diagram a title and a key, name each element's type, label every relationship specifically, and keep color coding consistent. These facts come from C4 guidance.
- [Runtime View](https://arc.fuet.ch/concepts/documentation/runtime-view.md): The runtime view shows how building blocks work together and talk to each other while the system runs. It covers a few chosen scenarios, picked for architectural relevance rather than completeness.
- [Runtime View Antipattern: Code-Level Activity Diagram](https://arc.fuet.ch/concepts/documentation/runtime-view-antipattern-code-level-activity-diagram.md): A runtime view that draws code-level steps, such as package or script names, repeats what the source code already shows. It leaves out which building blocks work together and who is responsible for what.
- [Safety](https://arc.fuet.ch/concepts/quality-attributes/safety.md): Safety is a system's ability to avoid states that endanger people, property or the environment. ISO/IEC 25010 splits it into five parts, from limiting operation to staying safe after integration.
- [Safety Tactic](https://arc.fuet.ch/concepts/tactics/safety-tactics.md): Safety tactics help a system stay in control of known hazards. They detect problems, contain them with barriers or redundancy, and fall back to a safe state when needed. Examples are interlocks, watchdogs, timeouts and fail-safe defaults.
- [Scalability](https://arc.fuet.ch/concepts/quality-attributes/scalability.md): Scalability is how well a system copes with growing workload by adding resources. A capacity limit always exists, and the bottleneck, often a stateful part like a database, decides how far scaling can go.
- [Scatter/Gather](https://arc.fuet.ch/concepts/integration/scatter-gather.md): Scatter-Gather sends one request to several recipients, then combines their replies into a single answer. The caller sees one response instead of many.
- [Scenario Weight Assignment and Prioritization](https://arc.fuet.ch/concepts/evaluation/scenario-weight-assignment.md): Stakeholders brainstorm many scenarios, then vote to rank them. In ATAM and the Quality Attribute Workshop, the voting involves the stakeholder group.
- [Scenario-based Questions from Tactics](https://arc.fuet.ch/concepts/tactics/scenario-based-questions-from-tactics.md): A questionnaire asks general, open questions that fit any architecture. A scenario describes a concrete sequence of steps in which the system is used or changed. Scenario-based questions lean on the second idea.
- [Security](https://arc.fuet.ch/concepts/quality-attributes/security.md): Security means protecting data from unauthorized access while still serving legitimate users, and keeping the system running under attack. It rests on confidentiality, integrity and availability, and it can pull against reliability.
- [Security Scenario](https://arc.fuet.ch/concepts/quality-attributes/security-scenario.md): A security scenario describes one concrete attack on a system and how the system should respond. It has six parts, and a measurable result shows whether the response is good enough.
- [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md): Security tactics are design decisions for protecting a system. They borrow ideas from physical security and fall into four categories. Patterns can realize them, and stakeholders can choose them together.
- [Selective Consumer](https://arc.fuet.ch/concepts/integration/selective-consumer.md): A Selective Consumer tells its channel which messages it wants. The channel delivers only matching messages, so the consumer does not have to sort through the rest itself.
- [Self-Documentation](https://arc.fuet.ch/concepts/documentation/self-documentation.md): Self-documentation means a system carries the information needed to understand it inside itself, mainly in its code. This cuts separate documents that fall out of date, but it cannot capture reasons or the full picture.
- [Self-Invented Notation Drawback](https://arc.fuet.ch/concepts/documentation/self-invented-notation-drawback.md): A self-invented notation is a set of diagram symbols the author made up. Readers cannot tell what the symbols mean without help. A legend, or a standard notation, reduces the problem.
- [Sensitivity Point](https://arc.fuet.ch/concepts/evaluation/sensitivity-point.md): A sensitivity point is a property of a system that one quality, such as speed or confidentiality, depends on strongly. Teams flag these points during evaluation so they know which decisions carry the most leverage.
- [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md): Separation of concerns means studying one aspect of a problem on its own while staying aware of the others. In software, it means splitting an application by responsibility so the code stays organized and manageable.
- [Service-Oriented Architecture](https://arc.fuet.ch/concepts/styles-patterns/service-oriented-architecture.md): Service-Oriented Architecture (SOA) organizes software as services that consumers reach through defined interfaces. Providers and consumers may belong to different organizations. The term is loose, and a central hub can become a bottleneck.
- [Seven Types of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/seven-types-of-architectural-decisions.md): A decision is architectural when its effects reach beyond one place. Technology choice, such as buy versus build, is one kind of such decision. Tactics are decisions too, and the reasoning behind all of them needs recording.
- [Shared Database](https://arc.fuet.ch/concepts/integration/shared-database.md): A shared database lets several applications exchange data by storing it in one common database. Information is shared quickly and consistently. The price is deep coupling to one schema, which is hard to design and risky to change.
- [Shearing Layers](https://arc.fuet.ch/concepts/principles/shearing-layers.md): Shearing Layers means grouping parts of a system that change at similar rates and keeping them apart from faster or slower parts. The boundaries between layers help lasting abstractions emerge.
- [SMART Requirements](https://arc.fuet.ch/concepts/functional-requirements/smart-requirements.md): SMART is a checklist for judging a requirement. It asks whether the requirement is specific, measurable, attainable, realistic and traceable, so teams can verify it, build it and follow it through their work.
- [Software Architect](https://arc.fuet.ch/concepts/fundamentals/software-architect-role.md): A software architect links business goals and technical work. They decide what matters, weigh trade-offs, talk with people at every level of the organization, and stay close to the building of the system.
- [Software Architecture](https://arc.fuet.ch/concepts/fundamentals/software-architecture.md): Software architecture is the set of fundamental choices about a system: its parts, how they relate, and the reasoning behind them. Definitions differ, but most stress structure, important decisions, and the cost of changing them later.
- [Software Architecture Analysis Method (SAAM)](https://arc.fuet.ch/concepts/evaluation/software-architecture-analysis-method-saam.md): SAAM is the first documented method for analyzing a software architecture. It uses scenarios to test how well a design handles change, and it came before ATAM.
- [Software Architecture Basic Concepts](https://arc.fuet.ch/concepts/fundamentals/software-architecture-basic-concepts.md): Software architecture is the set of design decisions about a system's overall structure and behavior. Business needs and quality goals drive it. A system has a boundary, and its building blocks are organized in levels.
- [Software Architecture Definition](https://arc.fuet.ch/concepts/fundamentals/implications-of-the-architecture-definition.md): Definitions of software architecture differ. One says it is the design decisions about a system's overall structure and behavior. Another calls it the important stuff, or the expert developers' shared understanding of the design.
- [Software Architecture Documentation Consensus](https://arc.fuet.ch/concepts/documentation/software-architecture-documentation-consensus.md): Teams that document software architecture increasingly agree on the basics: split the description into views, build views with a small set of diagram types, and write for stakeholders. Approaches like arc42 and C4 follow this pattern.
- [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md): Architecture evaluation examines a design for problems and risks before teams build on it. Its findings are qualitative, and it works best when done early.
- [Software Architecture in Its Context](https://arc.fuet.ch/concepts/fundamentals/software-architecture-in-its-context.md): Software architecture is shaped by its surroundings. The organization, its constraints and its stakeholders all influence which designs are possible. Architects need to know where they are free and where they are bound.
- [Software Connector](https://arc.fuet.ch/concepts/fundamentals/software-connector.md): A connector is the element of an architecture description that stands for an interaction between components. It plugs into component ports, and its interface is a set of roles, one per participant.
- [Software Connector Classification](https://arc.fuet.ch/concepts/integration/classification-of-integration-patterns.md): Connector classification compares integration styles on shared questions, such as synchronous or asynchronous and one-to-one or one-to-many. The answers show how each style behaves when a side is down or an interface changes.
- [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md): The solution a team delivers rarely matches the one imagined at the start. Business changes and decisions made along the way move it. Good practice plans for this drift instead of fighting it.
- [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md): The solution strategy is a short chapter of an arc42 document. It lists the fundamental decisions that shape the architecture and ties them to the problem, quality goals, and constraints.
- [Soundness of Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/soundness-of-process-models.md): A process model is sound when it has no deadlock and no lack of synchronization. Soundness is a basic correctness check, and tools can verify it automatically.
- [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md): Split Module breaks a module that mixes unrelated responsibilities into smaller modules, so each part changes for its own reason. The split must follow expected change, and it adds interfaces, so weigh it against joining.
- [Stakeholder](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder.md): A stakeholder is a person, team, organization, or class of such parties with an interest in a system being built. Architects must balance their different needs and make sure each class is represented.
- [Stakeholder Concern](https://arc.fuet.ch/concepts/forces-decisions/stakeholder-concern.md): A stakeholder concern is an interest that a person or group has in a system, such as performance, security, or maintainability. Concerns shape what the architecture must address and which views describe it.
- [Stakeholder Identification](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder-identification.md): Stakeholder identification means finding the people, teams and organizations with an interest in a system. It comes first, before you rank stakeholders or plan how to talk to them.
- [Stakeholder Perspective and Concern](https://arc.fuet.ch/concepts/documentation/stakeholder-perspective-and-concern.md): A stakeholder is a person, team or organization with an interest in a system. Their interests are called concerns. Architecture documentation must address these concerns, and the concerns decide which views you build.
- [Stakeholder Power Grid](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder-power-grid.md): The stakeholder power grid sorts stakeholders by their power over a project and their interest in it. The position on the grid tells you how closely to engage each group.
- [Stakeholder Questions Addressed in Views](https://arc.fuet.ch/concepts/documentation/stakeholder-questions-addressed-in-views.md): Stakeholders ask recurring questions about a system. Each question points to a view that should answer it. Picking views from these questions keeps documentation useful for its audience.
- [Stakeholder Readiness for Change Assessment](https://arc.fuet.ch/concepts/enterprise-architecture/stakeholder-readiness-for-change-assessment.md): A readiness assessment rates each stakeholder's understanding and commitment today against what the architecture work needs. The gap between the two levels shows where to focus effort.
- [Standard Quality Attribute List](https://arc.fuet.ch/concepts/quality-attributes/standard-quality-attribute-checklist.md): A standard quality attribute list is a ready-made checklist and shared vocabulary for quality needs. No list is complete, and names alone are ambiguous, so teams adapt the list and add scenarios.
- [State and Event](https://arc.fuet.ch/concepts/modeling-uml/state-and-event.md): A state machine describes a system as explicit states joined by transitions. Events are what the machine detects and processes, one at a time, and a guard can decide which transition fires.
- [State Entry, Exit and Do Behavior](https://arc.fuet.ch/concepts/modeling-uml/state-entry-exit-and-do-behavior.md): A state can carry its own entry, do and exit behavior. Entry and exit run every time the state is entered or left. The do activity runs in between and can be aborted.
- [State Machine Diagram](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram.md): A state machine diagram shows the states an object or behavior can be in. It also shows the events that move it between states, and what happens on each move.
- [State Machine Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram-modeling-mistakes.md): State machine diagrams go wrong when start and end markers are misused, when completion transitions compete, or when guards overlap. Knowing these errors helps you build models with one clear behavior.
- [State Machine Transition](https://arc.fuet.ch/concepts/modeling-uml/state-machine-transition.md): A state machine transition is the switch from one active state to another, triggered by an event. A guard can block it. Transitions can be external, local, or internal, which differ in whether they leave the state.
- [Story Mapping](https://arc.fuet.ch/concepts/functional-requirements/story-mapping.md): A story map shows how users reach a goal as a picture. Activities form a backbone from left to right. Stories hang below, higher when more necessary. Horizontal lines slice the map into releases.
- [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md): Story splitting breaks a large or uncertain user story into smaller ones that still deliver value. Teams use patterns such as workflow steps, operations, data, interfaces and spikes, then check the result.
- [Strategy Map](https://arc.fuet.ch/concepts/enterprise-architecture/strategy-map.md): A strategy map is a one-page diagram of roughly 12–20 strategic objectives in four perspectives. Arrows show how lower objectives are expected to drive higher ones. Each arrow is a hypothesis to test.
- [Stream Connector](https://arc.fuet.ch/concepts/integration/stream.md): A stream connector passes data from one step to the next while the data flows. Buffers absorb speed differences between sender and receiver. Pipes and filters use it to build processing chains.
- [Structured Process Modeling with Fragments](https://arc.fuet.ch/concepts/modeling-bpmn/structured-process-modeling-with-fragments.md): Structured process modeling builds a model from a simple sequence of steps and inserts parallel or alternative blocks. In BPMN, these blocks use parallel gateways (AND) and exclusive gateways (XOR) as splits and joins.
- [Sweeping It Under the Rug](https://arc.fuet.ch/concepts/fundamentals/sweeping-it-under-the-rug.md): Sweeping It Under the Rug is a pattern for tangled code you cannot remove. You fence the mess off from the rest of the system and put a clean interface in front of it.
- [Synchronous vs Asynchronous Connector](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-connector.md): A synchronous connector needs sender and receiver to be up at the same time. An asynchronous connector, such as a queue, lets them work at different times, which limits how failures spread.
- [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md): A synchronous call makes the caller wait for the answer. An asynchronous call lets the caller move on. The choice shapes how failures spread and how replies are matched to requests.
- [System Context Diagram](https://arc.fuet.ch/concepts/documentation/c4-level-1-system-context-diagram.md): A system context diagram shows one software system as a single box. Around it sit the people and other systems it works with. Technical and non-technical readers can both follow it, so it makes a good first diagram.
- [System Idea](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea.md): A system idea is an early, high-level answer to how a system will be built. In arc42, the solution strategy section is its closest counterpart. It reuses proven patterns and is driven by quality goals and constraints.
- [System Idea and Vision Elements](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea-and-vision-elements.md): A system's vision is built from linked parts: a vision statement, the target group, needs and value behind it, and the context. Each part is written with the others in mind, so requirements and context stay consistent.
- [Tactic Coverage of ISO 25010 Quality Categories](https://arc.fuet.ch/concepts/tactics/tactic-sources-by-iso-25010-quality-category.md): Tactic catalogs and ISO 25010 use different vocabularies. Catalogs cover terms the 2011 standard lacks, such as deployability and energy efficiency, so you must map one to the other before judging coverage.
- [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md): Tactics serve quality goals, and those goals can conflict. Balancing means ranking the goals, finding where they collide, and recording each choice with all its consequences.
- [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md): Technical debt means shortcuts in design or code that help in the short term but make later change more costly. A little deliberate debt can speed work if the team repays it promptly.
- [Technology Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/technology-architecture.md): Technology architecture describes the infrastructure a system runs on and the standards for choosing and operating it. It covers hosting options such as on-premises, cloud and hybrid, and it feeds the arc42 deployment view.
- [Testability](https://arc.fuet.ch/concepts/quality-attributes/testability.md): Testability is how well a system supports its own testing. High testability makes faults easier to find by testing. Low testability means more test effort.
- [Testability General Scenario](https://arc.fuet.ch/concepts/quality-attributes/testability-general-scenario.md): The testability general scenario is a template for writing concrete testability requirements. It covers who tests, how the system is controlled and observed, and how easily the system reveals its faults.
- [Timeout-based Delivery](https://arc.fuet.ch/concepts/integration/timeout-based-delivery.md): Timeout-based delivery hides a message from other consumers while one consumer works on it. The consumer deletes it when done. If the timeout runs out first, the message reappears and is delivered again, so duplicates are possible.
- [TOGAF](https://arc.fuet.ch/concepts/enterprise-architecture/togaf.md): TOGAF is an enterprise architecture framework first presented in 1995, based mainly on a US Department of Defense framework. Its core is the Architecture Development Method, supported by a content framework, a continuum and reference models.
- [TOGAF Architecture Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-architecture-development-method.md): The TOGAF Architecture Development Method (ADM) is a cyclic, repeatable method for developing an enterprise architecture. An organization can tailor it, move between phases, and adapt it to agile work with sprints.
- [TOGAF Phase C: Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-phase-c-application-architecture.md): Application Architecture in TOGAF Phase C designs the target applications that support the business architecture and vision. It compares today's applications with the target and turns the gaps into roadmap components.
- [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md): Traceability links requirements to the architecture that serves them. arc42 describes a full form, where every requirement is referenced, and a pragmatic form, where key decisions are explained by their requirements. It advises avoiding the full form when possible.
- [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md): A trade-off point is a property of the architecture that affects several quality attributes at once. Improving one attribute through it costs another. ATAM reports these points so teams can decide on a compromise knowingly.
- [Transactional Client](https://arc.fuet.ch/concepts/integration/transactional-client.md): A transactional client groups its message operations into one transaction. A sent message only enters the channel once the sender commits. The cost is slower performance in widely distributed systems.
- [Transfer Object Pattern as Package Template](https://arc.fuet.ch/concepts/modeling-uml/transfer-object-pattern-as-package-template.md): A Transfer Object bundles data so fewer remote calls are needed. In UML, you can document this pattern as a package template and reuse it by binding its parameters to concrete elements with a dashed «bind» arrow.
- [Transition Syntax (Trigger, Guard, Behavior)](https://arc.fuet.ch/concepts/modeling-uml/transition-syntax.md): A UML transition moves a state machine from one state to another. Its label can name a trigger (the event), a guard (a condition in brackets), and a behavior (what runs after the slash).
- [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md): The Twin Peaks Model treats requirements and architecture as two bodies of work that grow together. Both start rough and become detailed through repeated rounds, each informing the other.
- [Types of Cohesion](https://arc.fuet.ch/concepts/principles/types-of-cohesion.md): Cohesion describes how well the parts of a module belong together. Seven types exist, from functional (strongest) to coincidental (weakest). Each type names the reason the parts were grouped.
- [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md): A ubiquitous language is one shared vocabulary that developers and domain experts both use. It comes from the model and is tested in conversation. Its terms hold only inside one bounded context.
- [UML 2.5 Diagram Taxonomy](https://arc.fuet.ch/concepts/modeling-uml/uml-diagram-taxonomy.md): UML 2 defines 14 diagram types, grouped in a taxonomy. Structure diagrams show the static makeup of a system. Behavior diagrams show what it does at runtime. Interaction diagrams are a subgroup of behavior diagrams.
- [UML Association](https://arc.fuet.ch/concepts/modeling-uml/association.md): A UML association is a solid line between two classes. It shows that objects of one class refer to objects of the other. Ends can carry role names, multiplicity and navigability arrows.
- [UML Behavioral Diagram](https://arc.fuet.ch/concepts/modeling-uml/behavior-diagram.md): UML behavior diagrams show how a system works while it runs: how users interact with it, which steps happen, which messages flow, and how states change. Structure diagrams show only the static parts.
- [UML Class Diagram](https://arc.fuet.ch/concepts/modeling-uml/class-diagram.md): A UML class diagram shows classes and how they relate. Use it as a selective sketch of the interesting classes, not as a full specification of every class.
- [UML Class Diagram Relationship](https://arc.fuet.ch/concepts/modeling-uml/class-diagram-relationships.md): UML class diagrams use different relationship types to link classes. Pick the type that matches the real link: associations resemble fields, composition means single ownership, and aggregation adds no meaning beyond association.
- [UML Component Diagram](https://arc.fuet.ch/concepts/modeling-uml/uml-component-diagram.md): A UML component diagram shows the high-level structure of a software system. It shows the parts and the behavior they offer and use through interfaces.
- [UML Deployment Diagram](https://arc.fuet.ch/concepts/modeling-uml/deployment-diagram.md): A UML deployment diagram shows where software runs. It assigns software artifacts to system elements, drawn as boxes called nodes.
- [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md): Generalization links a specific class to a more general one. The specific class inherits the general class's characteristics and can add its own. Every instance of the specific class is also an instance of the general class.
- [UML Interface](https://arc.fuet.ch/concepts/modeling-uml/uml-interface.md): A UML interface is a contract that lists operations without implementing them. Classes or components realize it. Clients rely on the contract, not on the implementation behind it.
- [UML Modeling Anti-Pattern](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-anti-patterns.md): A UML modeling anti-pattern is a diagram that claims to be UML but breaks its rules or invents its own. Unexplained arrows and numbers are typical. Readers then guess the meaning, and the documentation loses value.
- [UML Modeling Best Practice](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-best-practice.md): Good UML practice means agreeing on shared modeling standards, modeling together, and sharing models openly. Match the precision to how you use UML: quick sketches need less than blueprints.
- [UML Perspectives: Conceptual, Specification, Implementation](https://arc.fuet.ch/concepts/modeling-uml/uml-views-conceptual-specification-implementation.md): UML diagrams can be read at three levels. Conceptual diagrams describe the real-world domain. Specification diagrams describe software through interfaces. Implementation diagrams describe code in a specific technology.
- [UML Sequence Diagram](https://arc.fuet.ch/concepts/modeling-uml/sequence-diagram.md): A UML sequence diagram shows how participants exchange messages over time, read from top to bottom. arc42 recommends it for runtime scenarios because it shows what each building block is responsible for.
- [UML Structure Diagram](https://arc.fuet.ch/concepts/modeling-uml/structure-diagram.md): UML structure diagrams show the static parts of a system and how they relate, without showing behavior over time. Different diagram types cover different levels, such as components and hardware.
- [Unclear Level of Abstraction Antipattern](https://arc.fuet.ch/concepts/documentation/unclear-level-of-abstraction-antipattern.md): An architecture diagram that mixes high-level and low-level elements confuses readers. The fix is to keep each diagram at one abstraction level and draw separate diagrams when both views are needed.
- [Undetected Duplication Antipattern](https://arc.fuet.ch/concepts/documentation/undetected-duplication-antipattern.md): The same function or element is listed twice in one overview, and nobody notices. The remedy is to describe each element once, where it is handled, and have other places point to that description.
- [Unified Modeling Language (UML)](https://arc.fuet.ch/concepts/modeling-uml/uml-unified-modeling-language.md): UML is a standard graphical modeling language for software. It defines 14 diagram kinds, split into structure and behavior diagrams. It is not a method, so teams use it with a development method.
- [Usability](https://arc.fuet.ch/concepts/quality-attributes/usability.md): Usability describes how easily and efficiently people get tasks done through a system's interface. It covers learning, speed, error handling and satisfaction, and it links to how cheaply the interface can be changed.
- [Usability Quality Attribute Scenario](https://arc.fuet.ch/concepts/quality-attributes/usability-scenario.md): A usability scenario describes a user action (the stimulus) and how the system should react (the response). Adding a number, such as a time limit, makes a usability requirement testable.
- [Usability Tactic](https://arc.fuet.ch/concepts/tactics/usability-tactics.md): Usability tactics are design choices that help users interact with a system well. Features such as cancel, undo and progress bars need architectural support, so teams must plan them early.
- [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md): A use case is a structured description of how a system responds to requests from outside actors. It organizes requirements around user goals and can be kept brief or written in detail.
- [Use Case Completeness Check](https://arc.fuet.ch/concepts/functional-requirements/use-case-completeness-check.md): A use case set is complete when it is not too small, not too large and not off target. Asking people for missing use cases is a start, but it needs a clearer measure.
- [Use Case Diagram](https://arc.fuet.ch/concepts/modeling-uml/use-case-diagram.md): A use case diagram gives an overview of what a system offers. It shows the actors who use it and which functions are in scope, without describing how the system works inside.
- [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md): An include relationship links a base use case to another use case whose behavior it always runs as part of its own flow. Shared steps such as Authenticate are written once and reused by many goals.
- [Use Case Goal Level](https://arc.fuet.ch/concepts/functional-requirements/use-case-goal-levels.md): Use case goal level describes how high or low a use case sits in a hierarchy of goals. The user-goal level, called sea level or blue, is the most important level for writing use cases.
- [Use Case Template](https://arc.fuet.ch/concepts/functional-requirements/use-case-template.md): A use case template is a fixed form for writing a use case as text. Every use case gets the same fields, so readers can compare and review them. Teams can use a full or a short version.
- [Use of external and open data](https://arc.fuet.ch/concepts/data-architecture/use-of-external-and-open-data.md): External data, especially open data, is a useful input for applications. Open data is public domain or openly licensed, free to access, and machine-readable. Architects should plan for it early.
- [User Stories vs. Use Cases](https://arc.fuet.ch/concepts/functional-requirements/user-story-vs-use-case.md): User stories are small, brief requirements that a team estimates and talks through. Use cases are more detailed and can be understood on their own. A story is roughly a use case at very low precision.
- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md): A user story is a short requirement written from a stakeholder's point of view. It is a reminder to talk, not a full specification. Details follow through conversation and acceptance tests.
- [User Story Role Formulation](https://arc.fuet.ch/concepts/functional-requirements/user-story-role-formulation.md): A user story names a specific user role, what that role wants, and why. The "so that" part states the benefit and helps the team judge how much the story matters.
- [Utility Tree](https://arc.fuet.ch/concepts/quality-attributes/utility-tree.md): A utility tree breaks the broad idea of "quality" into branches, down to concrete scenarios. Teams build it with key stakeholders and use it as a checklist of what the system must achieve.
- [Value Object](https://arc.fuet.ch/concepts/domain-driven-design/value-object.md): A value object is a small domain object with no identity of its own. Two value objects with the same attribute values are equal. Treat them as immutable: to change one, create a new one.
- [View Creation Method](https://arc.fuet.ch/concepts/documentation/view-creation-method.md): Every architecture diagram should say which notation it uses, who it is for and why it exists. The arc42 building block view and runtime view are two views where this applies.
- [Vision Statement](https://arc.fuet.ch/concepts/vision-stakeholders/vision-statement.md): A vision statement is a short, inspiring statement of the shared goal behind a product. It names the target customers, the value they get, and the few features that make the product stand out.
- [Voting](https://arc.fuet.ch/concepts/tactics/voting.md): Voting compares the outputs of several redundant units and uses the majority result. A disagreement reveals a fault, and with three units one faulty result is outvoted.
- [Warning Signs of Poor Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/warning-signs-of-poor-enterprise-architecture.md): Poor enterprise architecture shows up as duplicated capabilities, little reuse, fragile system connections, and workarounds. Typical causes are rewarded local optimization and no shared inventory of capabilities.
- [Waves of Business Process Management](https://arc.fuet.ch/concepts/modeling-bpmn/waves-of-business-process-management.md): Business process thinking has changed over time. In 1990, Hammer argued for removing work that adds no value instead of automating it. Reengineering then drew criticism for downsizing and high failure rates.
- [Why Use UML in Architecture Documentation](https://arc.fuet.ch/concepts/modeling-uml/why-use-uml-in-architecture-documentation.md): UML is a standardized diagram notation. arc42 authors favor it because tools support it and its meaning is clear. It does not guarantee a better architecture, and any notation works only if stakeholders understand it.
- [Workflow Pattern](https://arc.fuet.ch/concepts/modeling-bpmn/workflow-pattern.md): Workflow patterns are named, recurring ways a process controls its flow, such as sequence, parallel split, and simple merge. They help describe process models and compare process languages such as BPMN.
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md): Working with functional requirements means making clear what a system must do. A requirement is precise enough when developers have no more questions. Architects separate these from quality requirements, split large ones, and add detail iteratively.
- [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md): Working with principles means writing short rules that tie design decisions to requirements. A good principle has a name, a statement, a rationale and implications. Teams may break one only for a justified reason.
- [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md): Working with tactics means taking measurable quality scenarios and choosing small design decisions (tactics) that meet them. You record each choice with its reasoning and revisit it as knowledge grows.
- [Y-Statement](https://arc.fuet.ch/concepts/forces-decisions/y-statement.md): A Y-Statement records one architectural decision in a single sentence. It names the context, the concern, the chosen option, the rejected options, the quality gained and the downside accepted.
- [Zachman Framework](https://arc.fuet.ch/concepts/enterprise-architecture/zachman-framework.md): The Zachman Framework is a grid that sorts the descriptions of an enterprise. It is a structure, not a process. Each cell holds one kind of description for one audience.