Glossary

A

Agile. Agile is the ability to create and respond to change. Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. Many different frameworks exist that espouse to be “agile” including frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).

Aggregate root. An aggregate defines a boundary that separates the entities inside it from the rest of the application. The entity representing the central business concept in the aggregate will act as the aggregate root. Good domain driven design specifies that a bounded context should have only one aggregate root.

Anchoring (cognitive bias). The tendency to rely heavily on the first piece of information encountered when making decisions.

Architecture realization. A concrete implementation of the high level architecture model, intended to demonstrate how the abstract model will be specifically implemented. Typically not drawn to encompass the entire system, it is usually a subset to establish an implementation pattern. (See: High-level architecture model).

Artifact. Any asset or piece of information that contributes to a project’s outcome, including, for example, designs, drawings, templates, architectural stereotypes, models, documentation, source code, and other information that is required to deliver the end product.

B

BDD (Behavior Driven Development). An extension of TDD that expresses tests as plain-language scenarios describing expected behavior from the user’s perspective. It emphasizes collaboration between developers, testers, and business stakeholders through shared, readable specifications. (See: How to fix a $25 bug before it becomes a $37,500 problem).

Boss Logic. The organization behind Customer Obsessed Engineering, and a company I originally co-founded back in the mid-1990s.

Bounded context. A bounded context is what knits together a collection of related entities, data, behaviors and their ubiquitous language into a related model. It creates a boundary inside of which we want consistency: Everything inside the boundary needs to be closely related, and share the same ubiquitous language. (See: 2.5 Context mapping).

Business capabilities. Business capabilities define a concrete list of business functions or product features. They have a degree of similarity to “business domains,” such as fraud prevention, order processing or warehousing. Throughout the playbook, business capabilities are further defined by enumerating use cases the define specific functionality within the capability. (See: 1.4 Business capabilities and functions).

Business objectives. Business objectives define high-level initiatives that establish your long-term strategic goals. An initiative encompasses a whole business outcome or capability, such as “deliver a modern, accessible user experience that surpasses our competitors.” (See: 2.1 Business strategy).

C

Ceremony (sprint ceremonies). Activities proscribes by the sprint, project, or methodology, specifically for the purpose of maintaining the health of the project and communication among the stakeholders.

CI/CD (Continuous Integration/Continuous Deployment). Automated practices for building, testing, and deploying code frequently.

Code Scanning. See: Static Application Security Testing (SAST).

Component map. A project-level overview of all the different project capabilities you need to plan for (such as testing, deployment, release management, automation, data management, security, business agility, and more). (See: 2.6 Target state architecture).

Context. The setting in which a word or a statement appears that determines its meaning. (See: 2.5 Context mapping).

Context map. A visual map of your bounded contexts that clearly indicates how each context depends upon and communicates with other contexts. Relationships between contexts (“interfaces”) are shown, along with additional detail (such as where anticorruption layers are needed, and whether an interface is upstream or downstream). (See: The 30-minute guide to Domain Driven Design).

Control process. Any activity or process that checks for errors or outlying conditions and defines corrective action to compensate for them. For example, a control process around bank account withdrawals is to verify that sufficient funds are present before making the withdrawal.

Cryptographic shredding. A technique for data protection and compliance where data is encrypted and can be “forgotten” by deleting the encryption key, making the data permanently unreadable.

Customer Obsessed Delivery Playbook (or Delivery Playbook). A technique for making sure customer value is identified, protected, and realized throughout delivery. No customer misunderstandings or disappointments. Paid subscribers can access the Customer Obsessed Delivery Playbook online.

Customer personas. A persona fills in a picture of a specific customer, the customer’s needs, and obstacles or drivers that might motivate them. Personas are used throughout user journeys to capture how different users interact with systems.

D

Data Loss Prevention (DLP). Tools that protect sensitive information by applying security policies based on content and context.

Declarative programming. A programming and design paradigm focused on expressing intent (“what”) rather than implementation steps (“how”). Common examples include SQL (you declare what data you want, not how to retrieve it), HTML (you declare the structure of a page, not how to render it), and functional programming languages like Haskell and Elixir.

Definition of Done (DoD). A “Definition of Done” is a shared understanding among team members of what it means for work to be considered complete. Any criteria that are deemed important are included, such as, “the work has been fully reviewed by another team member.” (See: A "Definition of Done" is only half the story).

Definition of Ready (DoR). A “Definition of Ready” outlines the criteria required in order for the team to begin work on an item. Having this criteria in place protects the effort of the team, for example, by preventing the team from working on something that still has external dependencies. (See: A "Definition of Done" is only half the story).

Dependency scanning. Scanning third-party libraries and dependencies for known vulnerabilities.

DevOps. A set of practices that unifies software development (“dev”) and IT operations (“ops”) to shorten the development lifecycle and deliver software continuously. It emphasizes automation, collaboration between teams, and rapid feedback loops through continuous integration and continuous deployment (CI/CD) pipelines.

DevSecOps. An extension of DevOps that integrates security practices throughout the entire software development lifecycle rather than treating security as a final gate before release. It emphasizes shifting security “left” by making it a shared responsibility with development.

Domain. A domain is a collection of related concepts, relationships, and workflows.

Domain Driven Design (DDD). A software design approach focusing on modeling software to match a business domain according to input from domain experts. It involves concepts such as ubiquitous language, strategic design, tactical design, entities, value objects, aggregates, and more. (See: The 30-minute guide to Domain Driven Design).

Domain logic. The unique value of your application — the purpose and rules that implement your processes. It’s how your business processes are codified, defining how data is handled.

Domain model. A system that describes the selected aspects of a domain and that is often used to solve problems related to that particular domain.

E

Elixir. A functional, concurrent programming language built on the Erlang virtual machine (BEAM). It was created by José Valim in 2011 and combines Erlang's strengths in fault-tolerant, distributed systems with a more approachable Ruby-like syntax and modern tooling. Elixir is particularly well-suited for building scalable web applications and real-time systems.

Endpoint Detection and Response (EDR). Security tools for detecting and responding to threats on endpoint (e.g., edge or external) devices.

Entity. Entities are the unique and identifiable representation of things in our business domain or bounded context: A combination of behavior and data. A customer, an account, and a merchant are all good examples of entities.

Entity Relationship Diagram (ERD). A diagram specifically for modeling relational database systems and their entity relationships (e.g., joins between tables).

Ephemeral environments. Ephemeral environments are lightweight and often short-lived replicas of your production environment. Except for scale, they mirror your production configuration and provide consistency guarantees. They’re used for on-demand experimentation, validation, testing and release management. (See: Ephemeral environments are the best way to fight “‘waste gremlins”).

Event storming. A workshop-based method to quickly find out what is happening in the domain of a software program. Compared to other methods it is extremely lightweight and intentionally tries to avoid introducing technology limitations by focusing on business events. The result is often expressed in sticky notes on a wide wall. (See 2.3 Strategic event storming; Strategic event map).

Event streaming. An architectural pattern where systems communicate through a series of events oriented messages (typically using a persistent event store). Events are treated as immutable records of what has happened in the past.

F

Feature flags. Techniques for enabling and disabling experimental features in production without requiring code deployment.

Functional architecture. A typically simplified view of the target state architecture that elaborates on specific technologies and design decisions. It clearly express the technologies (languages, frameworks, tools, libraries) that will be used for each architecture component. (See 2.9 Functional architecture).

Functional programming. A style of programming that applies and composes functions, rather than a sequence of imperative statements which update the running state of a program. Functions are treated as first-class citizens. They can be bound to identifiers, passed as arguments, and returned from other functions, just like any other data type. This allows programs to be written in a declarative and composable style, where small functions are combined in a modular manner. (See also: Declarative programming).

Fuzz testing. Testing technique that provides invalid or random data inputs to find vulnerabilities.

G

GDPR (General Data Protection Regulation). European Union regulation on data protection and privacy, including the “right to be forgotten.”

Gherkin. A structured, plain-language syntax used to write BDD scenarios. It uses keywords like Feature, Scenario, Given, When, and Then to express expected behavior in a format that is both human-readable and machine-parseable.

H

Haskell. A purely functional programming language known for its strong static typing, lazy evaluation, and emphasis on mathematical correctness. It was named after logician Haskell Curry and was first released in 1990.

High-level architecture model. A generic, simplified drawing representing a target state architecture. It sets the context of how components fit into your product ecosystem and what patterns you’ll use to glue it all together. (See: Architecture realization).

HIPAA (Health Insurance Portability and Accountability Act). A US federal law enacted in 1996 that establishes standards for protecting sensitive patient health information. Its purpose includes ensuring people can maintain health insurance coverage when changing jobs (portability) and setting requirements for how healthcare organizations handle patient data (accountability).

I

IAM (Identity and Access Management). Systems for managing user identities and controlling access to resources.

Immutable. An immutable object is an object that can’t be modified after it’s created. Conversely, a mutable object is one that can be modified after it’s created.

Increment. The smallest amount of work that delivers a high-value feature into your customer’s hands.

Infrastructure as Code (IaC). Infrastructure as Code (IaC) is the practice of building and integrating provisioning, configuration and deployment into tools and workflows by identifying places where control processes, tests, and infrastructure provisioning may be implemented using automation.

Integration testing. Testing that verifies different components work together correctly.

INVEST. Criteria for well-formed user stories: Independent, Negotiable, Valuable, Estimable, Small, Testable.

IV&V (Independent Validation and Verification). An independent evaluation to ensure correctness and compliance with established policies, practices and standards.

K

Kanban (“kanban”). A scheduling system for lean manufacturing (also called just-in-time manufacturing, abbreviated JIT). Taiichi Ohno, an industrial engineer at Toyota, developed kanban to improve manufacturing efficiency. The system takes its name from the cards that track production within a factory. In kanban, problem areas are highlighted by measuring lead time and cycle time of processes. One of the main benefits of kanban is establishing an upper limit to work in process.

KPIs (Key Performance Indicators). Quantifiable metrics that demonstrate progress toward business objectives.

L

Lambda. An anonymous function — a function defined without a name, typically written inline where it’s used. Lambdas are commonly passed as arguments to other functions, returned from functions, or assigned to variables. The term comes from lambda calculus, a mathematical formalism developed by Alonzo Church in the 1930s.

M

Magic estimation. An estimation technique using visual placement of story cards based on relative sizing. The goal is to choose whether a given feature represents “more” or “less” effort than other features and thereby avoid anchoring bias and estimation inaccuracy. (See: The “magic” of just enough estimation).

Marble diagram. A technical, visual diagram that represents behavior. They align well with event modeling because they model streams of information using a timeline-based format. They use symbols to depict the emission of values, completions, and errors. (See: Technical drawings that actually work).

Mean Time to Detect (MTTD). Metric measuring how quickly security incidents are detected.

Mean Time to Respond (MTTR). Metric measuring how quickly teams respond to incidents.

Methodology. A body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry; a set of working methods (American Heritage dictionary). Specifically, in this context, a software delivery methodology such as Scrum or Kanban that focus on the mechanics of team organization, collaboration, and ceremony around software delivery.

Microservices. An architectural approach that decomposes a large system into smaller, independently deployable services, each independent and responsible for managing its own data.

Minimum Viable Product (“MVP”) or Minimum Loveable Product (“MLP”). The simplest version of a product that can still deliver enough value to early customers to validate your core business idea and gather meaningful feedback. It has the minimum features needed to meet the core needs, without any extra bells and whistles.

Mobile Device Management (MDM). Tools for managing and securing mobile devices connecting to enterprise resources.

Multi-Factor Authentication (MFA). Authentication requiring multiple forms of verification beyond a password.

Mutable. A mutable object is an object that can be modified after it’s created. Conversely, a immutable object is one that cannot be modified after it’s created.

N

Non-value add (non-value add effort). Any activity or effort that does not add to or create value. In the context of a waste walk activity, indicates those activities that do not contribute directly to the current sprint, specifically toward the goals of the sprint (or project outcomes).

North Star (North Star vision). An overarching representation of a system’s intended realization, typically including conceptual high-level models, some example level of concrete architectural implementation, and delivery standards. The intended outcome of a North Star vision is to establish clear boundaries and guardrails for technical implementation. It usually demonstrates how architectural concepts are realized into actual implementation. It also provides design pattern standards, for example, by defining that a given architecture is service based and that services communicate using an event stream architecture. (See: 2.9 Functional architecture).

P

Penetration testing. Security testing that attempts to exploit vulnerabilities in a computer system, network, or application to identify weaknesses before malicious attackers can find them.

PHI (Protected Health Information). Healthcare data protected under HIPAA. (See also: HIPAA).

PII (Personally Identifiable Information). Data that can identify a specific individual.

Planning fallacy. The cognitive bias where humans systematically underestimate task duration.

Planning poker. An estimation technique using cards where team members vote on relative effort.

Playbook. A set of rules, suggestions, or methods that are considered to be suitable for a particular activity, industry, or job. (See: Delivery Playbook).

Product increment. A working, deployable release that represents functional, although potentially incomplete, set of product features. The release is intended to meet goals and acceptance criteria defined for the increment. (See: 3.3 Identify product increment).

Product mindset. An approach to product development that creates product oriented teams (as opposed to project oriented teams). Product oriented teams are cross disciplinary and fully enabled to deliver a product, from ideation to operations. (See: Moving away from the Monolith: faster, better with a product mindset).

Product vision. A statement that establishes an overarching long term direction for your product and serves as a guidepost for all involved stakeholders. Vision statements define why you are creating the product and what the company’s intended outcome is. (See: 1.3 Product vision).

Q

Quality Assurance (QA). A systematic process of ensuring that solutions meet defined standards and requirements. It focuses on preventing defects through processes, guidelines, and checks in the solution lifecycle and encompasses planning, documentation, audits, and continuous improvement efforts. Often confused with testing activities, QA actually does not perform the test function, although it may set forth standards for testing. (See also: Testing, IV&V).

Quality gate. A milestone in a project that requires predefined criteria be met before the project can proceed to the next phase. Typically, these are verifications you can implement in the software development pipeline to prevent artifacts from moving forward if they don’t meet specified quality criteria.

R

RACI. A responsibility assignment matrix or linear responsibility chart. It provides a model describing the participation by various roles in completing tasks or deliverables for a project. RACI is an acronym derived from the four key responsibilities most typically used: responsible, accountable, consulted, and informed.

Referential transparency. An expression is said to be referentially transparent when it can be replaced with its corresponding value without changing an application's behavior.

Regression. A bug introduced into previously working functionality as a side effect of a change made elsewhere in the codebase.

Regression testing. Refers to re-running existing tests after changes to verify that previously working features still work. This is where TDD and BDD provide significant value — an automated test suite catches regressions within seconds of introducing them, rather than discovering them days or weeks later in production.

Review apps. Automatically deployed preview environments created for each code branch, typically created (“spun up”) and destroyed (“spun down”) based on branch lifecycles.

Risk management. The process of identifying, assessing, and prioritizing potential threats or uncertainties, then applying strategies to minimize their likelihood or impact. It involves deciding whether to avoid, mitigate, transfer, or accept each risk based on its severity and the cost of addressing it. (See: My boss wants a risk management plan; what is it and how do I get one?).

ROI (Return on Investment). A financial metric that measures the profitability or efficiency of an investment relative to its cost.

RPC (Remote Procedure Call). A protocol for executing code on a remote system.

S

Scrum. An agile framework that provides just enough structure for people and teams to integrate into how they work, while adding the right practices to optimize for their specific needs. The Scrum framework is made up of a Scrum team consisting of a Product Owner, a Scrum Master and developers, each of which have specific accountabilities. Scrum defines the events that the team participates in, and the artifacts produced by those events.

Secret detection. Tools and practices for finding and managing secrets (passwords, API keys) in code and infrastructure.

Security as Code (SaC). Security as Code (SaC) is the practice of building and integrating security into tools and workflows by identifying places where security checks, tests, and gates may be included and implemented as configuration or software, in an automated fashion.

Service catalog. Much like a restaurant menu, a service catalog provides a menu of available technology choices — services, hardware, software, products and support options — available to use in delivery. It is the “toolbox” of the development team. Some commercial service catalogs may also offer a way to propose, reviewing and adopt new technologies. (See: 2.6 Target state architecture).

Sequence diagram. A technical diagram that illustrates how objects or components interact over time. It highlights message order between discrete components. (See: Technical drawings that actually work).

Shift left. The practice of moving validation and verification, quality, security, some operations activities and testing earlier in the development lifecycle.

Side effect. Mutating data can cause unintended side effects. A side effect is a change of system state or observable interaction with the outside world that occurs during the calculation of a result. For example, modifying any external variable or object property (a global variable or higher scoped variable), or writing to the network.

Smoke testing. Basic tests to verify critical functionality before more extensive testing.

Stakeholder. Individuals or organizational units that have an interest in and may be affected by the outcomes of the project.

Static Application Security Testing (SAST). Automated analysis of source code to find security vulnerabilities.

Steel thread. A development technique that achieves an architecturally complete feature delivery to production very rapidly by aggressively controlling risk. It deals with risk and complexity up-front, while also focusing on a proof of architecture during the first few working sprints. (See Plagued with problems getting to delivery? Solve them with a “steel thread.")

Stereotype (architecture stereotype). A standardized mental picture that is held in common by members of the team and that represents a simplified, opinionated approach to realizing the specific design, providing overarching guardrails and definitions regarding the key elements and standards of the architecture. Often expressed as design prints that model the key components of a system.

Strategic event map. A visual representation of the business processes within a specific domain. Developed during event storming, the “map” is usually a series of commands and events that take place over time. Often expressed in sticky notes on a wide wall. (See 2.3 Strategic event storming; Event storming).

SWOT. A strategic planning and strategic management technique used to help a in identifying Strengths, Weaknesses, Opportunities, and Threats related to business competition or project planning.

Systems Development Life Cycle (SDLC). Also referred to as an application development life cycle, an SDLC is a process for planning, creating, testing, and deploying an information system. (See: SDLC, also related to software development process).

T

Tactical event map. A visual representation of the detailed activities that support a business process (hence “tactical,” versus “strategic.”) Developed by extending a strategic event map, adding underlying operations (such as external calls, persistence operations, read models and state change). Often expressed in sticky notes on a wide wall. (See 2.3 Strategic event storming; Strategic event map).

Target state. Also “future state.” An imagined or planned evolution of an existing system that realizes an as-yet unimplemented set of features.

Target state architecture. A framework that enables the necessary shared understanding, planning and actions needed to reach a desired target state. (See: 2.6 Target state architecture; Target state).

TDD (Test Driven Development). A development practice where you write a failing test before writing the code that makes it pass, then refactor. The cycle is often summarized as “red, green, refactor.” (See: How to fix a $25 bug before it becomes a $37,500 problem).

Template. A document or file having a preset format, used as a starting point for a particular application, component, or document, so that the format does not have to be recreated each time it is used.

Test batteries. Collections of automated tests that must pass before code can move to higher environments (e.g., from a development sandbox to a staging environment).

Testing. In software development, the process of evaluating a system to verify that it works correctly, meets requirements and is free of defects. It involves executing code under controlled conditions to compare actual behavior against expected outcomes. (See also: Quality assurance).

Three amigos. A collaborative practice in agile development where three stakeholders (usually customer, developer, and business analyst) discuss a feature before implementation begins. The goal is to clarify requirements, identify edge cases, and establish acceptance criteria — while reducing misunderstandings that would be costly to fix later. (See: How to fix a $25 bug before it becomes a $37,500 problem).

U

Ubiquitous language. Ubiquitous Language is a Domain Driven Design term describing a common, rigorous language between developers and users. It is based on the domain model and needs to be rigorous, since software doesn't cope well with ambiguity. Using ubiquitous language in conversations with domain experts tests the model, and creates common understanding between stakeholders. (See: Do you understand your customer?).

Use case. Use cases are descriptions of how a customer (or user) interacts with a system. (See: What are use cases?).

User journey. User journeys tie together different use cases or “user stories” that a customer has with a system, following a user through different stages. Together, a collection of use cases make up the user journey. (See: What about “user journeys?”).

V

Value add (value add effort). Any activity or effort that creates value. In the context of a waste walk activity, indicates those activities that are creating value within the current sprint, specifically attributed toward the goals of the sprint (or project outcomes).

Value drift. When a team inadvertently moves away from the core product value, breaking their value stream (e.g., introducing “non-value add” activities, adding inefficiency and waste to a project). (See: How to deliver more customer value than your competitors).

Value mapping (value-stream mapping). Value-stream mapping, also known as material- and information-flow mapping, is a lean management method for analyzing the current state and designing a future state for the series of events that take a product or service from the beginning of the specific process until it reaches the customer. (See: 3.1 Value mapping).

Value object. Small, immutable objects that represent a concept in our domain. They don’t implement identity and typically won’t implement business logic. Two value objects are considered equal if their properties are equal.

Value Stream Engineering. A set of practices that improve the way teams deliver high-quality customer experiences. It focuses on how quickly customer requested features or updates are delivered and whether the customer realizes the intended value from those features. (See: How to deliver more customer value than your competitors).

Velocity. A measure of how much work a team completes, on average, over a fixed period of time.

W

Waste walk. A tool or technique to identify and eliminate waste, ultimately optimizing operational efficiency. By conducting waste walks, businesses can uncover hidden opportunities for improvement, streamline processes, and enhance overall productivity. (See: Context switching is killing your gains (part 2)).

Waterfall. A widely used project management method with a linear approach, having its roots in industrial design process. In a waterfall methodology, each stage of workflow is completed before moving on to the next step. While there are different types of project management methodologies, waterfall is well suited for projects where the objectives are clearly outlined from the beginning. (See: Context switching is killing your gains (part 2)).

Wideband delphi. An estimation technique using anonymous input to avoid anchoring bias.

Z

Zero Trust Architecture (ZTA). A security model based on “never trust, always verify,” where every access request is fully authenticated, authorized, and encrypted regardless of network location. (See: Why you need a Zero Trust Architecture (and how to get one).