Enterprise models
Status: Draft target views. Revised 2026-09-24.
This document models the intended Vektorprogrammet replacement through 4EM and ArchiMate viewpoints. It does not define a second business or architecture source.
- system.md defines business meaning and target behavior.
- architecture.md defines technical ownership and boundaries.
- operational-responsibility-map.md defines actors, end-to-end work, and replacement contracts.
- STATE.md alone records current implementation and acceptance.
The diagrams use Mermaid for review in the repository. They use method vocabulary, but they are not exports from a certified modeling tool.
Shared capability keys
These keys connect both views. They identify business capabilities, not packages or implementation status.
| Key | Capability |
|---|---|
CAP-ID | Identity, sessions, and profile |
CAP-REC | Recruitment and onboarding |
CAP-AFF | Volunteer affiliation and placement |
CAP-SVC | School-demand planning and teaching service |
CAP-SUB | Substitute coverage |
CAP-ORG | Organization administration |
CAP-ECO | Expense reimbursement |
CAP-SUR | Surveys and school feedback (Google Forms) |
CAP-PUB | Public content, contact, and events |
CAP-OPS | Audit, delivery, migration, and recovery |
4EM target model
The 4EM view uses its six connected submodels. The notation and submodel structure follow Overview of the 4EM Method by Sandkuhl, Stirna, Persson, and Wißotzki.
Goals Model
G-01 is the primary goal. G-06 is a migration goal, not evidence that cutover
has started or is authorized.
Business Rules Model
| ID | Rule | Source |
|---|---|---|
BR-01 | A Person is the stable human identity. Account, Profile, Appointment, Affiliation, and Placement remain separate. | Business facts |
BR-02 | Team membership must not imply volunteer affiliation. | Responsibility rules |
BR-03 | Recommendation, invitation, account claim, affiliation, and placement are separate decisions. | Recruitment and affiliation |
BR-04 | A coordinator confirms the roster and reviews its exceptions. A proposal does not create a placement or prove attendance. | School demand and placement |
BR-05 | Authority requires a usable account, active relationship, covered scope, and allowed capability at the given instant. | Authority model |
BR-06 | The backend denies access by default. A hidden frontend action is not enforcement. | Authority model |
BR-07 | One transaction records current state, immutable history, command receipt, audit, and required outbox work. | Durable effects |
BR-08 | External delivery starts after commit. Retry reuses the immutable first envelope and remains bounded. | Delivery and providers |
BR-09 | A report distinguishes current from historical, missing from unavailable, and recorded from inferred. | Reporting |
BR-10 | A file path, team label, menu role, or pool membership does not grant business authority. | Expense reimbursement and Authority model |
BR-11 | Receipt approval does not imply payment or bank-settlement authority. | Reimburse an expense |
BR-12 | Production data, providers, deployment, writer transfer, and destructive actions need explicit operator authority. | Cutover gates and authority |
BR-13 | An admission outcome is explicit: admitted, substitute, or rejected. A Kanskje recommendation implies no outcome. | Recruitment and affiliation |
Concepts Model
The model shows business concepts and their meaning-bearing links. It does not set cardinalities that the canonical domain model does not define.
The dated-service contract separates planned supply, dated commitments, terminal outcomes, and actual attendance. Cancellation creates no occurrence. Unfulfilled service records an occurrence only when actual attendance exists. Implementation and acceptance remain in STATE.md.
Business Process Model
Recruit and affiliate a volunteer
The sequence does not contain a generic accepted-applicant state. BR-13 records the
admission outcome separately. A substitute is admitted without a placement and is on call.
Plan and deliver school service
This target process covers CAP-SVC and CAP-SUB. A terminal decision records its evidence atomically.
Covered and Uncovered describe an absence, not the whole service outcome.
Completion requires actual attendance that meets demand. Attendance is the confirmed roster minus
absent assistants plus the people in coverage records. Cancellation records no attendance.
Certificates are outside the mandatory core path. State records unresolved operational obligations.
Reimburse an expense
BP-24 is outside the current product boundary. BR-11 prevents approval from
being treated as settlement.
Actors and Resources Model
A Person can hold several roles. Assignment depends on relationship, scope, and time. The arrows do not grant authority by themselves.
Technical Components and Requirements Model
| ID | Technical requirement |
|---|---|
TR-Q01 | Keep one modular backend until an observed operational need requires another deployment boundary. |
TR-Q02 | Keep business rules and capability requirements in the domain package. |
TR-Q03 | Derive HTTP, OpenAPI, and SDK artifacts from one contract. |
TR-Q04 | Encode every external or durable boundary with Effect Schema. |
TR-Q05 | Use PostgreSQL constraints, transactions, locks, and compare-and-set revisions for owned invariants. |
TR-Q06 | Enforce the same relationship-based authority for commands and queries. |
TR-Q07 | Commit business facts and outbox work atomically. Deliver external effects after commit. |
TR-Q08 | Make provider, credential, schema, and storage configuration explicit. Fail before production serving. |
TR-Q09 | Protect private files with ownership checks, no-follow traversal, restricted permissions, and lifecycle handling. |
TR-Q10 | Make one Foldkit Model own each stateful dashboard journey. |
TR-Q11 | Exercise the real browser, HTTP, and PostgreSQL path before accepting a journey. |
TR-Q12 | Fence legacy writers before native ownership starts. Prove backup, recovery, reconciliation, and rollback. |
The component graph comes from Product shape. The requirements derive from the remaining architecture sections and production gates.
4EM inter-model links
| From | Link | To |
|---|---|---|
G-01, G-02 | motivate | BP-10 through BP-18 and CAP-SVC |
G-03, G-08 | motivate | BR-01, BR-07, BR-09, and history resources |
G-04, G-07 | motivate | BR-05, BR-06, BR-10, TR-Q06, and TR-Q09 |
BR-03, BR-13 | govern | BP-01 through BP-09 |
BR-04 | governs | BP-12 through BP-14 |
| Human roles | perform within authority | Business processes |
| Business processes | create or use | Concepts and resources |
TR-C01 through TR-C09 | support | CAP-ID through CAP-OPS, except CAP-SUR |
G-06, BR-12, TR-Q12 | constrain | production migration |
ArchiMate target model
This section uses ArchiMate 3 vocabulary and relationship labels. It separates motivation, strategy, business, application, technology, and migration views.
Motivation and strategy viewpoint
The strategy capabilities are the shared CAP-* keys. They group the behavior
needed to achieve these goals. They do not map one-to-one to deployable components.
Business service viewpoint
Role assignment is conditional. The authority relationship remains a separate business fact and applies at the interaction time.
Application cooperation viewpoint
packages/domain, packages/database, packages/http-api, and packages/sdk are
implementation modules within these components and interfaces. Their exact
dependency graph remains authoritative in architecture.md.
Technology viewpoint
The target documents do not define a final production topology. This view therefore stops at runtime responsibilities and explicit external provider seams.
Implementation and migration viewpoint
MIG-PLT01 and the local observations in MIG-PLT02 are current facts from
STATE.md. All later plateaus are targets. MIG-WP05 requires new
operator authority and does not follow automatically from technical completion.
Cross-model traceability
| Capability | 4EM anchors | ArchiMate anchors | Canonical source |
|---|---|---|---|
CAP-ID | G-03, BR-01, AR-R01, TR-Q06 | MOT-GOL02, APP-FNC04 | Business facts, Identity and authority |
CAP-REC | BR-03, BR-13, BP-01–BP-09 | BUS-PRC01, BUS-SVC01 | Recruitment and affiliation |
CAP-AFF | BR-02, BP-07–BP-09, AR-R04 | BUS-PRC02, BUS-SVC02, BUS-OBJ02 | Return an existing volunteer |
CAP-SVC | G-01, G-02, BR-04, BP-10–BP-18 | MOT-GOL01, BUS-PRC03, BUS-SVC03 | Plan and deliver school service |
CAP-SUB | BP-17, AR-A04, AR-A07 | BUS-PRC04, BUS-SVC04 | Substitute coverage |
CAP-ECO | G-07, BR-10, BR-11, BP-20–BP-25 | BUS-PRC05, BUS-SVC05, BUS-OBJ05 | Expense reimbursement |
CAP-OPS | G-05, G-06, BR-07, BR-08, BR-12, TR-Q12 | MOT-GOL03, MIG-* | Cutover gates and authority |
Capabilities without detailed diagrams still remain in the shared key list. Their canonical behavior stays in the three source documents.
Open model decisions
- Define a coordinator admission decision only if it is a real business fact with named authority and lifecycle.
- Define payment and settlement ownership before adding a finance integration.
- Select the final production topology only after operational requirements justify it.
- Promote the ArchiMate draft to an exchange file only if a maintained modeling tool becomes part of the workflow.
Method references
- Sandkuhl, Stirna, Persson, and Wißotzki, Overview of the 4EM Method, 2014.
- The Open Group, The ArchiMate Enterprise Architecture Modeling Language.
- The Open Group, ArchiMate 3.2 Specification.
Maintenance rule
Change the canonical source document first. Update these views in the same change when the modeled meaning changes. Record implementation progress only in STATE.md. This prevents a target view from becoming false runtime evidence.