Skip to content

Software & Systems Architecture

← Back to Domain-Specific Families

Abstractions about structuring and governing engineered software and IT systems, covering modular design principles (single-responsibility principle, interface-based programming, functional design), infrastructure and enterprise-scale architectures (enterprise architecture, software-defined data centers, IaaS), and operational practices like patch management.

29 abstractions in this family — domain-specific abstractions that sit near one another in structural-signature space (k-means over structural-signature embeddings). Each is shown with its short description.

  • Abstract Factory Pattern — A software design pattern in which a client uses one abstract factory interface to create several related product kinds from a selected concrete implementation family.
  • Autonomic Computing — A computing architecture in which monitored components use policies and feedback loops to configure, heal, optimize, and protect themselves with minimal direct administration.
  • BIM Collaboration Format — The BIM Collaboration Format (BCF) is a structured file format suited to issue tracking with a building information model.
  • Break/Fix — An IT support arrangement in which a customer requests restoration after a fault or failure and pays the provider for the resulting incident-specific labor, parts, or service rather than for continuous management.
  • Convention over Configuration — A software-tool policy that infers documented defaults from recognized artifact patterns while reserving explicit configuration for exceptions.
  • Enterprise Architecture — Model an enterprise's business, information, application, and technology layers as one governed baseline-to-target transformation so strategy, investments, and implementation remain aligned.
  • Failure Analysis — A retrospective engineering investigation that uses a failed physical item's evidence and service context to test explanations of how and why it failed.
  • Fallacy of One Administrator — Reason about a deployed system as though one authority governs every node it depends on, when it actually crosses many independently-governed administrative domains — so failures concentrate at the unmodeled seams between them.
  • Function (engineering) — A capability assigned to or realized by an engineered system: the process, action, or task it is required or able to perform, distinct from the physical or software means that realizes it.
  • Functional Design — A modular design discipline that assigns each component one coherent responsibility while minimizing its side effects and coupling to other components.
  • Infrastructure as a service — A cloud service model in which a provider supplies API-controlled compute, storage, networking, virtualization, and physical facilities on demand while the customer manages operating systems, deployed software, data, identities, and configuration under a shared-responsibility boundary.
  • Interface-Based Programming — A component architecture in which clients depend on abstract interfaces, obtain implementations through factories or registries, and avoid direct cross-component use of concrete classes so implementations can be substituted behind stable contracts.
  • Internationalization–Localization Interface — Separates shared software behavior from locale-specific resources and choices through a defined lookup or formatting interface.
  • N-Version Programming — Independently designed software versions perform one required function, and a cross-version decision uses their comparable results to tolerate some design faults.
  • Packing Problem — An optimization problem seeking an admissible arrangement of specified objects in containers while optimizing density, used extent, container count, or overlap under declared geometric or combinatorial constraints.
  • Patch management — The governed lifecycle for identifying, prioritizing, acquiring, testing, deploying, verifying, and monitoring software and firmware patches across an asset fleet.
  • Problem Frames Approach — The problem frames approach specifies a machine through its interfaces with world domains so that domain properties and machine behavior jointly satisfy a world-level requirement.
  • Process Layout — A facility arrangement that groups resources by the function they perform while letting each job visit the work areas its requirements call for.
  • Processor — Processor is a recurring computer architecture, digital electronics identity in which a digital processing unit fetches or receives data and performs a defined instruction or operation repertoire under physical constraints.
  • Reconfigurable Computing — Computing by mapping functions onto a reusable hardware fabric whose logic or processing interconnections can be retargeted.
  • Release Early, Release Often — A software project exposes usable intermediate versions repeatedly so tester and user feedback can shape later fixes and releases.
  • Segment Protection — A prearranged alternate path or resource between the ends of a working network-path segment, with a declared protection mode for faults covered in that segment.
  • Service Provider Interface — A service-provider interface lets interchangeable backend modules supply a shared service through a declared implementer contract and discovery or dispatch layer.
  • Single-Responsibility Principle — A module should have exactly one reason to change — read as one external change-driver, not one function — so that aligning each boundary with a single driver keeps every edit's blast radius contained.
  • Software Component — A bounded, deployable or integrable software unit that encapsulates a coherent responsibility and interacts with a larger system through declared provided and required interfaces.
  • Software Coupling — A dependency across software-module boundaries in which a relevant change to one module's contract, data, behavior, or mirrored logic can require coordinated change in another.
  • Software-defined data center — A data-center architecture concept in which compute, storage, networking, and security resources are virtualized, pooled, policy-controlled, and provisioned through software as services rather than configured mainly as isolated hardware.
  • Structure chart — A structure chart (SC) in software engineering and organizational theory is a chart which shows the smallest of a system to its lowest manageable levels.
  • Zero-Touch Provisioning — Automatically apply a preassigned initial configuration or management enrollment when an eligible device first starts, replacing manual per-device programming at deployment.