GLOSSARY
API (application programming interface): a description and specification for how to interact programmatically with software.
application monolith: a single, large application with many dependencies and responsibilities that possibly exposes many services and/or different user journeys.
bounded context: a unit for partitioning a larger domain (or system) model into smaller parts, each of which represents an internally consistent business domain area.
Brooks’s law: law coined by Fred Brooks which states that adding new people to a team doesn’t immediately increase the capacity of a team.
cognitive load: the amount of working memory being used.
collaboration mode: team(s) working closely together with another team.
complicated-subsystem team: responsible for building and maintaining a part of the system that depends heavily on specialist knowledge.
Conway’s law: law coined by Mel Conway that states that system design will copy the communication structures of the organization which designs it.
domain complexity: how complex the problem is that is being solved via software.
Dunbar’s number: coined by anthropologist Robin Dunbar, which states that fifteen is the limit of people one person can trust; of those, only around five can be known and trusted closely.
enabling team: team(s) composed of specialists in a given technical (or product) domain; they help bridge the capability gap.
extraneous cognitive load: relates to the environment in which the task is being done (e.g., “How do I deploy this component, again?” “How do I configure this service?”).
facilitating mode: team(s) helping (or being helped by) another team to clear impediments.
flow of change: a stream of related updates or alterations to a software service or system, usually aligned to user goals or other core focus of the business.
fracture plane: a natural “seam” in the software system that allows it to be easily split into two or more parts.
germane cognitive load: relates to aspects of the task that need special attention for learning or high performance (e.g., “How should this service interact with the ABC service?”).
intrinsic cognitive load: relates to aspects of the task fundamental to the problem space (e.g., “What is the structure of a Java class?” “How do I create a new method?”).
joined-at-the-database monolith: composed of several applications or services all coupled to the same database schema, making them difficult to change, test, and deploy separately.
monolithic build: uses one gigantic continuous integration (CI) build to get a new version of a component.
monolithic model: software that attempts to force a single domain language and representation (format) across many different contexts.
monolithic release: a set of smaller components bundled together into a “release.”
monolithic thinking: “one-size-fits-all” thinking for teams that leads to unnecessary restrictions on technology and implementation approaches between teams.
monolithic workplace: a single office layout pattern for all teams and individuals in the same geographic location.
organizational sensing: teams and their internal and external communication are the “senses” of the organization (sight, sound, touch, smell, taste).
platform team: enables stream-aligned teams to deliver work with substantial autonomy.
reverse Conway maneuver: organizations should evolve their team and organizational structure to achieve the desired architecture.
stream-aligned team: a team aligned to a single, valuable stream of work.
team API: an API surrounding each team.
Team Topologies: model for organizational design that provides a key technology-agnostic mechanism for modern software-intensive enterprises to sense when a change in strategy is required (either from a business or technology point of view).
thinnest viable platform: a careful balance between keeping the platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building on the platform.
X-as-a-Service mode: consuming or providing something with minimal collaboration.