# IT & Systems Architecture

## Purpose

This folder contains the static **IT & Systems Architecture** for **HAV Seafood**, the fictional Faroese seafood manufacturer used in the synthetic business dataset.

The files define how HAV Seafood's technology environment is structurally designed: enterprise systems and technical application structure, integrations, identity and access, information security, IT infrastructure, endpoints, network architecture, backup and recovery, continuity requirements, IT services, incidents, changes, controls, authority and cross-domain technical relationships.

The architecture belongs to **Phase 1 — Business Architecture** of the project:

**1. Business architecture -> 2. Stories -> 3. Operational dataset**

It describes **what exists and how IT & Systems are designed**. It intentionally does **not** contain operational or historical IT activity such as user accounts, access grants, login events, incidents, service requests, changes, alerts, vulnerabilities, patch history, backup executions, outages, device failures, support tickets or security investigations.

---

## Core architecture principles

The IT & Systems Architecture follows these rules:

- Shared Enterprise remains authoritative for enterprise system identity, system purpose, shared identifiers, enterprise locations, external organizations and system/data ownership.
- IT extends the existing `ESYS-*` systems technically rather than creating a competing systems inventory.
- HR remains authoritative for employees, job roles, positions, position seats and incumbency.
- Production remains authoritative for machinery, equipment, work centers, factory areas, storage locations and other production-specific physical structures.
- Business domains remain authoritative for the business data and decisions supported by IT systems.
- IT owns technical architecture, identity/access design, infrastructure, technology services, technical controls and technology recovery requirements.
- Operating or supporting a system does not make IT the owner of the business data stored in that system.
- Role eligibility is separate from actual access.
- Access rules are separate from access grants.
- Security controls are separate from control executions.
- Backup requirements are separate from backup jobs.
- Recovery targets are separate from outage/recovery events.
- Incident, request, problem, change and exception definitions are separate from actual operational cases.
- Derived reference workbooks never override authoritative source workbooks.
- No deliberate Phase 2 business-story anomalies are seeded during Phase 1.

---

## Architecture scope at a glance

The current IT & Systems architecture includes:

- **13 existing enterprise systems** using the Shared Enterprise `ESYS-*` identifiers;
- **22 existing `SINT-*` integrations**, technically extended rather than redefined;
- **26 application components**;
- **21 technical environment definitions**;
- **54 integration-to-data-object relationships**;
- **20 significant system dependencies** in the Systems & Integration architecture;
- **70 system access roles**;
- **34 reusable access profiles**;
- access defaults for all **56 enterprise job roles**;
- **222 access-profile-to-system-role relationships**;
- security classification for all **132 governed enterprise data objects**;
- **22 security-control requirements**;
- **103 managed IT assets**;
- **8 endpoint profiles**;
- **8 network zones**;
- **20 network components**;
- **34 Production-to-IT bridges**;
- **14 infrastructure services**;
- **36 system-to-infrastructure dependency relationships**;
- backup, recovery, continuity, patching and monitoring architecture;
- **18 internal IT services**;
- **22 service-request types**;
- **14 incident categories**;
- **4 incident priorities**;
- **9 change types**;
- **32 core IT controls**;
- **10 IT-specific segregation-of-duties rules**;
- **13 IT exception types**;
- **14 IT service-level / metric definitions**;
- **24 IT processes** with **120 static process steps**;
- a complete **29-sheet derived IT & Systems reference layer** for AI navigation and cross-domain joining.

These values describe the current static synthetic architecture, not historical IT activity.

---

## Files in this folder

### `hav_seafood_it_systems_applications_integration_architecture_v1.xlsx`

Defines the authoritative **IT Systems, Applications & Integration Architecture**.

Contains:

- technical profiles for all 13 existing enterprise systems;
- application-component structure;
- environment definitions;
- the existing 22 `SINT-*` integrations with IT technical extensions;
- integration mechanisms, automation, frequency and criticality;
- integration-to-data-object relationships;
- system dependencies;
- reusable technical service classes;
- system support structures;
- maintenance/change windows;
- cross-domain system-use relationships;
- source precedence, architecture notes and data dictionary.

The principal model is:

`Shared Enterprise System -> IT Technical Profile -> Application Component / Environment -> Integration -> Data Scope / Dependent System`

The workbook deliberately preserves the existing somewhat fragmented enterprise landscape, including manual and file-based interfaces where already established, rather than redesigning HAV Seafood into a fully integrated enterprise.

Shared Enterprise remains authoritative for system identity and enterprise-level system/data ownership.

It does **not** contain integration executions, failed transfers, uptime history, application logs, deployments, support cases or system-performance history.

Companion reference:

`hav_seafood_it_systems_applications_integration_architecture_v1.md`

---

### `hav_seafood_it_identity_access_security_framework_v1.xlsx`

Defines the authoritative **Identity, Access & Information Security Framework**.

Contains:

- identity and account classes;
- authentication profiles;
- system access roles;
- 34 reusable access profiles;
- 222 profile-to-system-role relationships;
- default access architecture for all 56 enterprise job roles;
- privileged-access structures;
- joiner/mover/leaver rules;
- access approval and review rules;
- access segregation-of-duties requirements;
- information-security classifications;
- system security requirements;
- security mappings for all 132 governed enterprise data objects;
- 22 static security-control requirements;
- source precedence, architecture notes and data dictionary.

The core model is:

`Person / Non-person Identity -> Digital Identity -> Account Class -> Access Profile -> System Access Role -> Permission Scope`

with governance through:

`HR Role / Position -> Eligibility -> Approval -> Provisioning Rule -> Review`

Important distinctions include:

`Employee != Digital Identity`

`Identity != Account`

`Account != Access Profile`

`Access Profile != System Role`

`Eligibility != Access Grant`

`Privileged Eligibility != Privileged Account`

HR remains authoritative for employee, role, position and incumbency structures. Business domains remain authoritative for decisions about access to their sensitive business data. IT owns the technical access model and enforcement architecture.

It does **not** contain usernames, active user accounts, current employee permissions, MFA enrollments, sign-in history, access requests, permission changes, security alerts or security incidents.

Companion reference:

`hav_seafood_it_identity_access_security_framework_v1.md`

---

### `hav_seafood_it_infrastructure_endpoint_continuity_v1.xlsx`

Defines the authoritative **IT Infrastructure, Endpoints & Continuity Architecture**.

Contains:

- IT asset classes;
- **103 managed IT assets**;
- endpoint profiles;
- network zones;
- network components;
- asset-to-network relationships;
- infrastructure services;
- system-to-infrastructure dependencies;
- Production-to-IT bridges;
- backup profiles and applicability;
- recovery and continuity tiers;
- continuity requirements for all 13 enterprise systems;
- infrastructure continuity requirements;
- patching and lifecycle profiles;
- monitoring requirements;
- source precedence, architecture notes and data dictionary.

The core infrastructure model is:

`Enterprise Location -> Network / Infrastructure -> IT Asset / Endpoint -> System Dependency`

and:

`System / Infrastructure -> Backup Requirement -> Recovery Tier -> Continuity Requirement`

A critical boundary is:

`Production Equipment != IT Asset`

Production machinery, equipment, work centers and factory areas remain Production-owned. IT models connected terminals, endpoints, network components and technical dependencies around those structures without recreating Production master data.

The workbook does **not** contain asset-repair history, patch executions, network traffic, firewall logs, backup jobs, failed backups, monitoring alerts, outages, recovery events or device-loss history.

Companion reference:

`hav_seafood_it_infrastructure_endpoint_continuity_v1.md`

---

### `hav_seafood_it_service_change_control_framework_v1.xlsx`

Defines the authoritative **IT Service, Change & Control Framework**.

Contains:

- 18 internal IT services;
- 22 standard request types;
- 14 incident categories;
- four incident priorities;
- incident lifecycle architecture;
- problem-management structures;
- nine change types across standard, normal and emergency change classes;
- change-risk and lifecycle structures;
- change approval rules;
- 32 IT controls;
- 10 IT-specific segregation-of-duties rules;
- 13 exception/escalation types;
- 14 service-level / metric definitions;
- 24 IT processes;
- 120 static process steps;
- position-based authority;
- system/process mappings;
- cross-domain interfaces;
- source precedence, architecture notes and data dictionary.

The principal operating model is:

`IT Service -> Request / Incident / Problem / Change -> Process -> Authority -> Control / Escalation`

The architecture deliberately uses a lightweight governance model appropriate to HAV Seafood's size rather than inventing a large formal IT bureaucracy.

Important distinctions include:

`IT Service != System`

`Service Request Type != Service Request`

`Incident Category != Incident`

`Incident != Problem`

`Change Type != Change`

`Control != Control Execution`

`Exception Type != Exception Case`

`Service Metric Definition != Metric Result`

It does **not** contain actual tickets, incidents, problems, changes, deployments, approvals, outages, vendor cases, security investigations, control executions or service-performance results.

Companion reference:

`hav_seafood_it_service_change_control_framework_v1.md`

---

### `hav_seafood_it_systems_reference_tables_v1.xlsx`

Provides the **derived, AI-friendly navigation and joining layer** across the complete IT & Systems architecture.

Contains **29 derived reference sheets** covering areas including:

- system reference;
- application components and environments;
- integrations and integration data scope;
- system dependencies;
- access profiles;
- role-to-access defaults;
- profile-to-system-role mappings;
- system and data security;
- IT assets;
- locations and network relationships;
- system infrastructure dependencies;
- backup and recovery;
- IT services;
- request and incident structures;
- change structures;
- processes and controls;
- IT segregation of duties;
- exception/escalation structures;
- service metrics;
- cross-domain bridges;
- entity ownership/source precedence;
- relationship catalog;
- architecture-source catalog;
- architecture notes and data dictionary.

This workbook is **derived and non-authoritative**.

It introduces no new systems, integrations, access profiles, IT assets, controls, ownership decisions or other architecture.

If it conflicts with an authoritative IT, Shared Enterprise, HR, Production, Finance or other domain source, the authoritative source wins.

This workbook should normally be the **first Excel workbook inspected when fast AI context or cross-IT navigation is needed**.

Companion reference:

`hav_seafood_it_systems_reference_tables_v1.md`

---

## How the IT & Systems architecture fits together

At a high level:

`Shared Enterprise Systems + Data Ownership`

`-> IT Technical System Profiles`

`-> Applications / Environments / Integrations`

`-> Identity / Access / Security`

`-> Infrastructure / Endpoints / Network`

`-> Backup / Recovery / Continuity`

`-> IT Services / Requests / Incidents / Changes`

`-> IT Processes / Authority / Controls`

`-> IT & Systems Reference Tables`

A user/access-centric view is:

`HR Job Role / Position`

`-> Access Profile`

`-> System Access Role`

`-> Future User Account / Access Grant`

A system-centric view is:

`Enterprise System`

`-> Technical Profile`

`-> Integration / Data Object`

`-> Access / Security Requirements`

`-> Infrastructure Dependency`

`-> Backup / Recovery Tier`

`-> IT Service / Support Process`

A technology-service view is:

`IT Service`

`-> System / Infrastructure`

`-> Request / Incident / Problem / Change Framework`

`-> Process / Authority`

`-> Control / Escalation / Metric Definition`

---

## Relationship with Shared Enterprise Architecture

Shared Enterprise remains the common enterprise backbone around IT.

IT reuses Shared Enterprise structures including:

- company identity;
- enterprise systems and `ESYS-*` identifiers;
- existing `SINT-*` integration identifiers where already established;
- departments and organizational units;
- enterprise locations;
- external organizations;
- system/data ownership;
- identifier conventions;
- shared classifications;
- enterprise data-object ownership.

The Shared Enterprise Systems Landscape remains authoritative for **which enterprise systems exist and their enterprise business role**.

The Shared Enterprise System/Data Ownership Model remains authoritative for **where business data is mastered, maintained, consumed and reported**.

IT extends these structures technically but does not replace them.

A central rule is:

`Technical System Ownership != Business Data Ownership`

An application supported by IT may contain Finance, HR, Sales, Procurement, Production or other business data without IT becoming authoritative for that data.

---

## Relationship with HR & Organization Architecture

HR remains authoritative for:

- employees;
- enterprise job roles;
- positions;
- position seats;
- incumbency;
- employment lifecycle;
- workforce authority structures.

IT uses those structures for:

- access eligibility;
- access-profile defaults;
- technical ownership assignments;
- IT process responsibility;
- joiner/mover/leaver triggers;
- approval routing.

The principal identity relationship is:

`HR Employee / Position -> IT Digital Identity / Access Eligibility`

The IT architecture deliberately avoids making current employee access part of static Phase 1 architecture. Actual accounts and access grants belong to Phase 3.

---

## Relationship with Production Architecture

Production remains authoritative for:

- factory areas;
- work centers;
- production lines;
- production machinery and equipment;
- production storage locations;
- technical production process structures;
- production operational staffing and qualifications.

IT owns the technology structures around those Production entities, such as:

- shared production terminals;
- production-network zones;
- connected IT devices;
- infrastructure services;
- technical system dependencies;
- IT support processes.

Important bridges include:

`Production Work Center -> IT Terminal / Device`

`Production Area -> IT Network Zone`

`Production System -> IT Infrastructure Dependency`

`Production Technology Issue -> IT + Production Handoff`

IT must not recreate Production equipment as IT assets merely because equipment is connected to a network or system.

---

## Relationship with Finance & Administration

Finance remains authoritative for:

- financial data;
- financial approval authority;
- monetary thresholds;
- Finance segregation-of-duties meaning;
- accounting and settlement decisions.

IT may technically enforce or support Finance access restrictions, but does not redefine their business meaning.

For example:

`Supplier bank-detail maintenance vs payment authorization`

may be technically enforced through IT access design, while the underlying control remains Finance-owned.

IT service and change processes also reference Finance where system changes, outages or access decisions affect Finance-owned systems or data.

---

## Relationship with Sales, Procurement, Logistics, Marketing and Quality

These domains remain authoritative for their business processes and data.

IT provides the technology layer supporting them.

Examples include:

- Sales CRM technology supporting Sales-owned customer/commercial activity;
- Core ERP supporting Sales, Procurement, Finance, inventory and other business processes;
- QMS supporting Quality-owned technical quality records;
- Microsoft 365 supporting shared office, Marketing and Administration work;
- warehouse/ERP technology supporting Logistics execution;
- integrations carrying data between domain systems.

A technical failure may be owned by IT while the business consequence and business workaround remain owned by the affected domain.

For example:

`MES unavailable -> IT restores service`

but:

`Can Production continue safely without MES? -> Production / Quality decision`

---

## Authoritative versus derived files

The following IT workbooks are authoritative for their IT subject areas:

- `hav_seafood_it_systems_applications_integration_architecture_v1.xlsx`
- `hav_seafood_it_identity_access_security_framework_v1.xlsx`
- `hav_seafood_it_infrastructure_endpoint_continuity_v1.xlsx`
- `hav_seafood_it_service_change_control_framework_v1.xlsx`

The following workbook is deliberately **derived**:

- `hav_seafood_it_systems_reference_tables_v1.xlsx`

The derived workbook exists to simplify navigation, joining, AI context and later dataset generation. It should be refreshed whenever authoritative IT architecture materially changes and must never overrule an authoritative source.

Where an underlying entity originates outside IT, the upstream authoritative domain remains authoritative.

---

## Companion Markdown files

Each IT workbook has a matching `.md` file containing a compact description of:

- purpose;
- principal entities and relationships;
- important architecture counts;
- ownership boundaries;
- source precedence;
- cross-domain relationships;
- important assumptions;
- explicit Phase 1 exclusions;
- recommended AI use.

These files are intended to provide fast semantic context without requiring every workbook to be opened first.

---

## Important conceptual boundaries

The architecture deliberately keeps the following concepts separate:

`Enterprise System != Application Component`

`System != Environment`

`System != Business Data Owner`

`Integration != Integration Execution`

`Integration != System Dependency`

`Employee != Digital Identity`

`Digital Identity != Account`

`Account != Access Profile`

`Access Profile != System Role`

`Access Eligibility != Access Grant`

`Privileged Eligibility != Privileged Account`

`Production Equipment != IT Asset`

`IT Asset != IT Asset Class`

`Endpoint Profile != Endpoint`

`Network Zone != Physical Location`

`Backup Requirement != Backup Execution`

`Recovery Target != Recovery Event`

`Monitoring Requirement != Alert`

`IT Service != System`

`Service Request Type != Service Request`

`Incident Category != Incident`

`Incident != Problem`

`Problem != Root Cause`

`Change Type != Change`

`Approval Rule != Approval Event`

`Control != Control Execution`

`Exception Type != Exception Case`

`Service Metric Definition != Metric Result`

These distinctions should be preserved when Phase 3 operational data is generated.

---

## Architecture boundaries — operational data intentionally excluded

This folder does **not** contain historical or transactional IT records such as:

- actual user accounts;
- usernames;
- current employee permission assignments;
- access requests;
- access approvals;
- access provisioning events;
- account disablement events;
- password changes/resets;
- MFA enrollment events;
- login/sign-in events;
- failed logins;
- privileged sessions;
- access-review results;
- permission-change history;
- integration executions;
- interface failures;
- scheduled-job history;
- application logs;
- system uptime/downtime history;
- software deployment history;
- application version history;
- device-assignment history;
- device repair/replacement records;
- endpoint telemetry;
- patch installations;
- patch-compliance results;
- software inventory history;
- network traffic;
- firewall logs;
- VPN sessions;
- Wi-Fi connection logs;
- security alerts;
- malware detections;
- phishing reports;
- vulnerability findings;
- security incidents;
- forensic/investigation records;
- backup executions;
- failed backup jobs;
- restore executions;
- recovery-test results;
- outage events;
- monitoring alerts;
- IT service requests;
- help-desk tickets;
- IT incidents;
- problem cases;
- root-cause analyses;
- known-error records;
- change requests;
- change approvals;
- implementations;
- rollbacks;
- emergency-change events;
- vendor support cases;
- control executions;
- control failures;
- audit findings;
- exception cases;
- SLA/KPI results;
- IT operational emails or communications.

Those belong to Phase 3 after the Phase 2 business stories and patterns have been deliberately designed.

---

## Story neutrality

The IT & Systems Architecture is intentionally designed to support future business stories without choosing them yet.

It does not deliberately seed outcomes such as:

- repeated system outages;
- unstable integrations;
- data synchronization failures;
- inappropriate access;
- excessive privileges;
- failed offboarding;
- unauthorized administrator activity;
- phishing compromise;
- malware incidents;
- weak MFA adoption;
- security-control failures;
- unsupported endpoints;
- overdue patching;
- device failures;
- network instability;
- failed backups;
- failed recovery tests;
- lost devices;
- failed changes;
- excessive emergency changes;
- recurring incidents;
- weak IT support performance;
- vendor service failures;
- control bypasses;
- segregation-of-duties failures.

Those patterns should be selected in **Phase 2 — Stories** and introduced deliberately when operational IT data is generated.

Some structural characteristics—such as fragmented interfaces, manual transfers, shared production terminals or dependencies on a small IT team—exist because they are realistic architecture choices. They should not automatically be interpreted as Phase 2 problems.

---

## Recommended use of the folder

For fast context, inspect files in this order:

1. `README_it_systems_architecture.md` — overall IT architecture, ownership boundaries and file map.
2. `hav_seafood_it_systems_reference_tables_v1.xlsx` — compact cross-IT navigation and joining layer.
3. The matching authoritative IT workbook for the subject being analyzed.
4. The relevant Shared Enterprise, HR, Production, Finance or other domain source whenever the underlying entity or business decision is owned outside IT.

### AI navigation shortcuts

- What systems does HAV Seafood use? -> `System_Reference`.
- What technical structure sits under a system? -> `System_Component_Ref` / environment reference.
- How do systems exchange data? -> `Integration_Reference`.
- What data passes through an interface? -> `Integration_Data_Ref`.
- Where is a data object authoritative? -> `Integration_Data_Ref` + `Entity_Ownership_Source`.
- What should a job role normally access? -> `Role_Access_Reference`.
- What can an access profile do in a system? -> `Profile_System_Access_Ref`.
- What security requirements apply to a system? -> `Security_Reference`.
- What security classification applies to a data object? -> `Data_Security_Reference`.
- Which IT assets exist? -> `IT_Asset_Reference`.
- What IT infrastructure exists at a location? -> `Location_IT_Reference`.
- What does a system depend on? -> `System_Dependency_Ref` / `System_Infrastructure_Ref`.
- What happens structurally if a system becomes unavailable? -> `Backup_Recovery_Reference`.
- Which IT service supports an area/system? -> `IT_Service_Reference`.
- How are requests/incidents classified? -> `Request_Incident_Reference`.
- What rules apply to a change? -> `Change_Reference`.
- Which process/control applies? -> `Process_Control_Reference`.
- Which IT controls exist? -> `Control_Reference`.
- Which segregation rules apply? -> `SoD_Reference`.
- How should an exception escalate? -> `Exception_Escalation_Ref`.
- Which IT metrics are defined? -> `Service_Metric_Reference`.
- How does IT connect to another business domain? -> `Cross_Domain_Bridges`.
- Which source should be trusted? -> `Entity_Ownership_Source`.
- How do entity keys relate? -> `Relationship_Catalog`.

---

## Use in later phases

### Phase 2 — Stories

This architecture provides the stable structures needed to design cross-functional stories involving areas such as:

- system outages;
- integration failures;
- inconsistent data between systems;
- access-control problems;
- delayed onboarding/offboarding;
- excessive or conflicting permissions;
- privileged access;
- phishing and security incidents;
- endpoint failures;
- unsupported technology;
- patching problems;
- network disruption;
- backup and restore issues;
- continuity and recovery;
- recurring incidents;
- failed or risky changes;
- emergency changes;
- vendor dependency;
- IT service performance;
- Production technology dependencies;
- IT/Finance access controls;
- HR-to-IT lifecycle handoffs;
- technical failures affecting Sales, Logistics, Quality, Procurement or Marketing.

Stories should reference the existing systems, roles, profiles, assets, dependencies, services, processes, controls and ownership structures rather than changing architecture merely to make a pattern possible.

### Phase 3 — Operational dataset generation

Operational IT datasets should:

1. reuse all established system, integration, access-profile, role, asset, network, infrastructure-service, service, process, control and exception identifiers;
2. preserve Shared Enterprise, HR, Production and other domain identifiers;
3. generate operational records according to the static rules in the authoritative IT workbooks;
4. preserve business-domain ownership of underlying business data and decisions;
5. preserve the distinction between eligibility/rule definitions and actual access or operational events;
6. generate realistic ordinary activity and noise around deliberately selected Phase 2 stories;
7. avoid redefining master data inside operational datasets;
8. create records that join consistently across IT, HR, Production, Finance, Sales, Procurement, Logistics, Marketing, Quality and Management.

The eventual operational IT dataset can include realistic combinations of service-desk exports, user-account lists, access reviews, authentication logs, integration logs, endpoint inventories, monitoring exports, backup reports, change records, security alerts, vendor-support correspondence, incident reports, emails, spreadsheets and other realistic technology artifacts while remaining anchored to this architecture.

---

## Overall role of this architecture

Together, these files form the **static technology, identity, access, security, infrastructure, continuity, service and governance layer** for HAV Seafood.

They connect the Shared Enterprise systems backbone to applications, integrations, enterprise data objects, HR roles and positions, user-access design, IT assets, Production technology dependencies, network and infrastructure services, security requirements, recovery expectations, IT services, processes, changes, controls and cross-domain support relationships.

The architecture is deliberately proportionate to a 92-person manufacturing company. It is detailed enough to support rich operational data and cross-functional business stories while avoiding an unrealistically large IT organization or technology estate.

Its main purpose is to ensure that later synthetic IT activity behaves like part of the same company, uses consistent systems, people, assets, locations and ownership rules, and can participate in cross-functional business stories without creating competing master data.
