arc42 section 3: Context and Scope

Business and technical context, external interfaces

• The conceptual data model contains entities, attributes, relationships and business rules. → Conceptual Data Model
• The model lists entities and their attributes without data types or storage details. → Conceptual data model building method
• The document gives an overall view of data repositories, their relationships and their owners. → Data Architecture
• Analytical data that domains provide is treated as a product with a standardized interface. → Data reusability and standardized access
• The data architecture describes data entities, not logical or physical storage design. → Define Target Data Architecture Method Phase
• A gap matrix is created using the TOGAF Gap Analysis technique. → Define Target Data Architecture Method Phase
• External data sources the system uses appear as external systems in the context view. → Use of external and open data
• For each open data source, the document states that the data is machine-readable and how it can be obtained. → Use of external and open data
• Every diagram has a legend explaining the notation, including line styles. → Architectural Overview Antipattern
• The overview diagram includes all external interfaces to human users and other systems. → Architectural Overview Diagram
• Architectural assumptions are recorded and, where possible, drafted as decision records. → Architecture Canvas
• The business context shows the system as a black box with its domain interfaces to each communication partner. → Business and Technical Context
• Business context arrows show data flows, not dependencies. → Business and Technical Context
• Business and technical context are kept as separate views. → Business and Technical Context
• Diagrams are organized by zoom level (context, containers, components, code), and each level zooms into the previous one. → C4 Model
• Every container is an application or a data store that must be running for the system to work. → Container Diagram (C4 Level 2)
• Every arrow carries a label naming the data that flows, and a legend explains the notation. → Context View Antipatterns
• The diagram shows the system as a black box with no internals. → Context View Antipatterns
• The system boundary is explicit and separates the system from its environment. → Context View Antipatterns
• The business context shows data flows between the system and its partners, not only dependencies. → Data architecture documentation in arc42
• Diagrams are stored as plain text in version control, not only as binary or hard-to-compare files. → Diagrams as Code
• The context view shows the system as a black box with its communication partners and external interfaces. → Essential Architecture Views (Context, Component, Runtime, Distribution)
• Every diagram carries a legend explaining its notation. → Modeling Method
• Every diagram has a title that states its type and scope. → Rules of Thumb for Modeling
• Every diagram carries a legend or key. → Self-Invented Notation Drawback
• Each view or viewpoint states which stakeholders’ concerns it serves. → Stakeholder Questions Addressed in Views
• The diagram shows the system as one box surrounded by its users and the external systems it interacts with. → System Context Diagram
• The diagram focuses on people and software systems, not technologies. → System Context Diagram
• Neighbouring systems are drawn outside the system boundary, so the scope is clear. → System Context Diagram
• Elements shown in the context view have a short name and business relevance, with detail kept elsewhere. → Undetected Duplication Antipattern
• The runtime view uses scenarios chosen for architectural relevance, not a large number of scenarios. → arc42 Architecture Documentation Template
• The context diagram shows the system as a black box with its communication partners around it. → arc42 Context and Scope
• The domain data exchanged with each partner is stated, so all stakeholders can understand it. → arc42 Context and Scope
• The technical context maps each domain input or output to the channel that carries it. → arc42 Context and Scope
• The document lists its bounded contexts and states which subdomain model each one holds. → Bounded Context
• The glossary lists the key domain and technical terms that stakeholders use when discussing the system. → Business Domain Understanding
• Where meanings differ between parts of the organization, the document separates them into bounded contexts. → Business Domain Understanding
• The document includes a context map that shows the relationships between bounded contexts. → Context Map
• Each relationship is labeled with a named pattern such as Shared Kernel, Open Host Service or Published Language. → Context Map
• External systems sit behind a translating wrapper that separates them from own components. → Deriving System Components from the Domain Model
• Each story states whether it describes the current process (as-is) or a future one (to-be). → Domain Storytelling
• The model uses one shared vocabulary that developers and domain experts both understand. → Domain-Driven Design of the Data Model
• The document states which bounded context each term and model belongs to. → Ubiquitous Language
• The document describes applications as logical groups of capabilities, not as specific computer systems. → Application Architecture
• The application portfolio is kept as a catalog in the architecture repository. → Application Architecture
• The documentation includes a list of all enterprise applications that is agreed and used to define a standard application set. → Application Architecture Artifacts
• Interfaces between applications are labeled with the technology used, such as REST or FTP. → Application Interface Diagram
• The view is scoped to the application landscape, not to the internals of one software system. → Application Interface Diagram
• Capability maps and value stream diagrams are kept as separate artifacts. → Business Architecture
• Applications are linked to the capabilities they support. → Business Architecture Artifact
• The capability map breaks capabilities into levels, each more detailed than the one above. → Business Capability
• The map has about seven to ten level-1 capabilities and uses three levels or fewer. → Business Capability Map
• The document states the purpose of the capability map and ties it to strategic decisions. → Capability Map Development Method
• No two capabilities overlap; each business function has one home. → Capability Map Development Method
• Capability names use nouns or gerunds, not verb-first phrases. → Capability identification and naming
• The capability map and the process map are separate and linked by relationships, not nested in each other. → Capability versus process
• A target (future-state) architecture is described and used to steer decisions. → Enterprise Architecture
• The document names the layers or domains it uses (business, data, application, technology). → Enterprise Architecture Layers
• Stage names use a verb and a noun, such as “Process Payment”. → Operational Value Stream
• Baseline and target application architectures are both described, and a gap analysis between them exists. → TOGAF Phase C: Application Architecture
• Each story’s role matches the primary actor of its use case. → Consistency of User Story and Use Case
• Every important black box in the building block view has a described responsibility. → Goal Hierarchy to Component Mapping
• Steps are ordered left to right, and vertical placement shows priority. → Story Mapping
• Each use case is written as a structured description of how the system responds to requests from external actors. → Use Case
• Each use case is marked with its goal level. → Use Case
• Extensions are listed separately for each use case. → Use Case Completeness Check
• User-goal use cases each have one actor, one sitting and one measurable outcome. → Use Case Goal Level
• The main success scenario is a numbered list of simple actor-system interaction steps. → Use Case Template
• Use cases in the document are detailed enough to be understood without the author. → User Stories vs. Use Cases
• Functional requirements are kept apart from quality requirements and constraints. → Working with Functional Requirements (method phase)
• The most important stakeholder quality goals are stated, for example the top three. → Architect’s Four Key Work Products
• The document states whether a piece of work belongs to solution scope or enterprise scope, and does not leave the boundary implicit. → Architecture Disciplines
• The document does not describe security as home-built technology when established solutions exist. → Common Architect Mistakes
• The architecture is communicated to stakeholders through views and patterns. → Software Architect
• Quality goals are few, tied to major stakeholders, and kept separate from project goals. → Software Architecture Basic Concepts
• The document states whether one enterprise-wide model or several canonical models with translation between overlaps are used. → Canonical Data Model
• The document states which integration style connects each pair of applications (messaging, file transfer or shared database). → Enterprise Integration Patterns
• Where a messaging exchange imposes format requirements such as header fields, the document states that application data is wrapped in a compliant envelope. → Envelope Wrapper
• The document states the retention period of the event log and what that means for replay. → Event Sourcing with Distributed Event Log
• The document states the file format used between each producer and consumer, such as text, XML, or a mainframe feed. → File Transfer
• The document states where the format identifier is carried (for example, payload prefix or header) and why. → Format Indicator
• The document names the integration style used between each pair of systems (file transfer, shared database, remote procedure call or messaging). → Integration
• Each integration point names the integration style used and why it was chosen over the others. → Integration Styles
• The document states which channels are point-to-point (one consumer per message) and which are publish-subscribe (a copy to each receiver). → Messaging
• The document names each wire protocol that clients use to reach the broker. → Messaging Protocol Support in Message Brokers
• The document states which subscribers need durable subscriptions so they do not lose messages while disconnected. → Publish/Subscribe Channel
• The document states how callers handle remote call failures caused by network problems. → Remote Procedure Call
• The document names which applications share the database and states that all of them are coupled to its schema. → Shared Database
• For each integration, the document states whether the exchange is synchronous or asynchronous. → Software Connector Classification
• Conversations are drawn as hexagons with a single thin line. → BPMN Conversation Diagram
• Sub-conversations carry a small square marker with a plus sign. → BPMN Conversation Diagram
• Conversation links use double thin lines. → BPMN Conversation Diagram
• Each gateway type matches its routing intent: exclusive picks one path, parallel takes all, inclusive takes all whose condition is true. → BPMN Core Elements
• A diagram meant as a topic overview omits internal process steps and does not imply message order. → BPMN Diagram Types
• Where message order between participants matters, a collaboration diagram is used rather than a conversation diagram. → BPMN Diagram Types
• Each participating organization in a cross-company process appears as its own pool. → BPMN Focus on Connected Businesses
• Each process model states whether it is a high-level descriptive model for stakeholders or a more detailed analytical model. → Capturing Business Behavior via Process Modeling
• Where a process is meant to be executed, the BPMN model and its XML are identified as the executable level. → Capturing Business Behavior via Process Modeling
• Tasks are named with an object and an infinitive verb. → Process Analysis
• Process models use a named, standard notation such as BPMN 2.0 or EPC. → Process Analysis and Modeling
• All actors are drawn outside the system boundary box. → Common Use Case Diagram Errors
• Actor names describe roles, not job titles. → Common Use Case Diagram Errors
• No database, API, or server appears as an actor or use case. → Common Use Case Diagram Errors
• Required interfaces are drawn as sockets on the component that depends on them. → Provided and Required Interface
• Each interface shown in a component diagram is drawn as a ball (provided) or socket (required), or as a class box with the interface stereotype. → UML Interface
• Each diagram has a title naming its type and scope. → UML Modeling Anti-Pattern
• The diagram draws a system boundary, so it is clear which functionality is in scope and which is not. → Use Case Diagram
• Extend relationships are used with care, and their meaning is made clear to readers. → Use Case Diagram
• Each include arrow starts at the base use case and points at the included use case. → Use Case Goal Hierarchy with Include Relationships
• Behavior shared by several use cases, such as Authenticate, is factored out into one included use case. → Use Case Goal Hierarchy with Include Relationships
• The document states which other products a component exchanges information with, and what it shares with them. → Compatibility
• The document states which formats or representations each interface uses, and how the parties agree on them. → Interoperability
• The system appears as a black box with its communication partners around it. → Context View
• The domain interfaces state which data are exchanged with the environment. → Context View
• Technical interfaces and channels to neighboring systems are documented. → Context View
• Every external neighbor with two-way exchange shows both directions, as two arrows or one annotated arrow. → Context View Antipattern: Forgetting Bidirectional Data Flows
• Each flow is labeled with the data exchanged, and a legend states what arrows mean. → Context View Antipattern: Forgetting Bidirectional Data Flows
• The business context shows data flows, not dependencies. → Context View Antipattern: Forgetting Bidirectional Data Flows
• The top-level context diagram shows the system as a black box and stays an overview without excessive detail. → Refining Complex Context Views
• Where many external systems exist, they are clustered by explicitly stated criteria. → Refining Complex Context Views
• The business context covers all communication partners, users and IT systems, and shows data flows rather than dependencies. → Refining Complex Context Views
• The business context lists all communication partners and is understandable by all stakeholders. → System Idea and Vision Elements