# HAV Seafood — IT Systems, Applications & Integration Architecture

## Purpose

This workbook defines the static **IT Systems, Applications & Integration Architecture** for **HAV Seafood**.

It belongs to **Phase 1 — Business Architecture** of the synthetic dataset project:

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

The architecture technically extends the existing Shared Enterprise systems landscape. It does **not** create a second enterprise-system master.

The existing **13 `ESYS-*` enterprise systems** remain authoritative in the Shared Enterprise Systems Landscape, while this workbook defines their technical profiles, structural application components, permitted environments, technical integration design, dependencies, support model and maintenance/change-window rules.

The existing **22 `SINT-*` high-level integrations** are also preserved and technically extended rather than replaced.

---

## Workbook

`hav_seafood_it_systems_applications_integration_architecture_v1.xlsx`

### Architecture scope at a glance

- **13** technical system profiles, one for each existing enterprise system;
- **26** structural application components;
- **21** permitted system/environment relationships;
- **22** technically extended `SINT-*` integration interfaces;
- **54** integration-to-governed-data-object relationships;
- **20** significant system dependencies;
- **10** reusable availability, support and interface-criticality classes;
- **26** internal/external system-support relationships;
- **13** static maintenance/change-window assignments;
- **96** imported system/department usage relationships from Shared Enterprise;
- explicit source precedence, architecture notes and a field-level data dictionary.

These are current-state structural definitions, not operational history.

---

## Core architecture principles

- Shared Enterprise remains authoritative for `System_ID`, system identity, enterprise purpose, high-level system usage and the existing `SINT-*` integration identities.
- The Shared Enterprise **System & Data Ownership Model** remains authoritative for business-domain ownership and system-of-record assignments.
- IT owns the technical extension: hosting posture, application components, environment design, technical interface mechanics, technical dependencies, support responsibilities and change-window architecture.
- IT operation of a system does **not** transfer ownership of the business data processed by that system.
- HR remains authoritative for positions and incumbency. IT technical ownership/support is therefore attached to HR-owned positions rather than named employees.
- Enterprise locations remain authoritative in Shared Enterprise; this workbook does not redefine locations.
- Formal user accounts, permissions and access profiles are deliberately deferred to the later Identity, Access & Information Security Framework.
- Detailed endpoint, network, server, sensor and backup-target architecture is deliberately deferred to the later Infrastructure, Endpoints & Continuity Architecture.
- Several file-based and manual interfaces are intentionally retained to reflect a realistic 92-person company rather than a perfectly integrated enterprise.
- No deliberate Phase 2 business-story anomalies are embedded here.

---

## Existing enterprise systems extended

The workbook technically extends the following existing systems without changing their `ESYS-*` identity:

1. `ESYS-001` — Core ERP
2. `ESYS-002` — Production Execution System
3. `ESYS-003` — Quality Management System
4. `ESYS-004` — Maintenance Management System
5. `ESYS-005` — People & Payroll
6. `ESYS-006` — Sales CRM
7. `ESYS-007` — Microsoft 365
8. `ESYS-008` — Microsoft Entra ID
9. `ESYS-009` — Power BI
10. `ESYS-010` — Label Design & Printing
11. `ESYS-011` — Temperature & Cold-Chain Monitoring
12. `ESYS-012` — Endpoint Security & Backup
13. `ESYS-013` — Online Banking Portal

---

## Sheets

### `System_Technical_Profile`

Authoritative IT technical extension for each existing enterprise system.

Contains:

- technical profile ID;
- linked Shared Enterprise system identity;
- application type;
- hosting model and responsibility;
- authentication posture;
- SSO/MFA applicability;
- external-network access class;
- availability and support classes;
- IT technical-owner and primary-support positions;
- vendor-support posture;
- lifecycle status and architecture notes.

Core relationship:

`Shared Enterprise System -> IT Technical Profile -> Technical Service Class -> IT Position Responsibility`

---

### `Application_Components`

Defines restrained structural components beneath the enterprise system level.

Examples include application services, integration services, factory/site connectors, collaboration services, identity services, local print services and monitoring gateway layers.

These are **not** software-installation or version records.

`System != Application Component`

---

### `Environment_Definitions`

Defines permitted Production and selected Test/Configuration environments.

Not every SaaS system receives a separate non-production environment. The model is intentionally proportionate to HAV Seafood's size.

The sheet distinguishes architecture from deployment history:

`Environment Definition != Deployment != Release`

No production-data-copy events or environment refresh histories are stored here.

---

### `Integration_Interfaces`

The primary technical-integration sheet.

It preserves all **22 existing `SINT-*` integration identifiers** and their Shared Enterprise source/target/purpose fields, then adds IT-owned technical design such as:

- transport method;
- trigger type;
- automation level;
- encryption and authentication requirement;
- interface criticality;
- failure impact;
- technical owner;
- monitoring requirement;
- reconciliation requirement.

Important principle:

`Integration Architecture != Integration Execution`

Actual runs, files, messages, errors, retries, timestamps and failures belong to Phase 3.

---

### `Integration_Data_Scope`

Links the technical integrations to governed enterprise `DOBJ-*` data objects from the existing System & Data Ownership Model.

This makes source-of-truth boundaries explicit for each important interface data subject.

Key relationship:

`SINT-* Integration -> DOBJ-* Data Object -> Business Owner Domain -> Authoritative System`

The personal/financial/commercial sensitivity indicators are informational technical-design flags only. The later Information Security architecture will own formal information classifications.

---

### `System_Dependencies`

Defines material technical/business dependencies that are not identical to integrations.

Examples include:

- authentication dependency on Entra ID;
- reporting dependency on operational source systems;
- label-printing dependency on MES variable production data;
- QMS dependency on cold-chain monitoring evidence.

`Integration != Dependency`

A system can depend on another service even where no separate business-data interface is created.

---

### `Technical_Service_Classes`

Defines reusable static classes for:

- availability expectations;
- support priority;
- integration/interface criticality.

The classes are intentionally simple and proportionate. They are architecture requirements, not measured SLA results.

---

### `System_Support_Model`

Defines two structural support layers per system:

- internal HAV Seafood L1/L2 support using HR-owned IT positions;
- external L3 application/platform/service-provider support.

Formal external supplier organization IDs are intentionally not invented here. If a provider needs to become a governed external party later, its identity should be created or reused through Shared Enterprise.

---

### `Maintenance_Change_Windows`

Defines static rules for when material technical changes should normally be performed and who must be involved when business operations may be affected.

It does **not** contain actual maintenance windows, change requests, approvals or deployments.

Particularly protected systems include MES, QMS, label printing, cold-chain monitoring, identity and HR/payroll.

---

### `Cross_Domain_System_Use`

Imported reference layer from the Shared Enterprise Systems Landscape showing which departments use which enterprise systems and for what scope.

It is included for technical context only and remains upstream-owned.

---

### `Source_Precedence`

Defines which architecture wins if the same concept appears in multiple places.

Important precedence rules include:

- system identity -> Shared Enterprise Systems Landscape;
- high-level `SINT-*` identity -> Shared Enterprise Systems Landscape;
- technical integration design -> this IT workbook;
- business data ownership/system of record -> Shared Enterprise System & Data Ownership Model;
- positions/incumbency -> HR;
- locations -> Shared Enterprise;
- detailed permissions -> future IT Identity & Access architecture;
- detailed infrastructure/endpoints -> future IT Infrastructure architecture;
- actual system activity/logs -> future Phase 3 operational data.

---

### `Architecture_Notes`

Records major scope decisions and boundaries.

---

### `Data_Dictionary`

Field-level definitions for all workbook sheets.

---

## Technical architecture model

At a high level:

`Shared Enterprise System`

`-> IT Technical Profile`

`-> Application Components`

`-> Permitted Environments`

`-> SINT-* Technical Integration`

`-> DOBJ-* Data Scope / Source of Truth`

`-> System Dependencies`

`-> Support / Service Classes`

`-> Maintenance & Change Rules`

A separate ownership view is:

`Business Domain -> Business Data Ownership`

while:

`IT -> Technical Platform / Integration / Support Ownership`

These must not be collapsed into one concept.

---

## Important conceptual boundaries

The architecture deliberately preserves these distinctions:

`System != Business Domain`

`System != Business Data Owner`

`System != Application Component`

`System != Environment`

`System != User Account`

`Integration != Integration Execution`

`Integration != System Dependency`

`Data Consumer != Authoritative System`

`Reporting Copy != Source of Truth`

`Technical Owner != Business Owner`

`Support Responsibility != Approval Authority`

`Environment Definition != Deployment History`

These boundaries should remain intact in later generated data.

---

## Relationship with Shared Enterprise Architecture

Shared Enterprise remains authoritative for:

- the 13 enterprise systems;
- enterprise departments;
- system/department usage;
- enterprise locations;
- high-level integration identities;
- enterprise data objects;
- business-domain ownership;
- authoritative-system / system-of-record assignments.

This workbook extends that backbone technically rather than replacing it.

---

## Relationship with HR

HR remains authoritative for the positions used in IT responsibility mappings.

The primary IT positions referenced here are:

- `POS-IT-MGR` — IT & Systems Manager;
- `POS-IT-SUPPORT` — IT Support Specialist;
- `POS-IT-SYS-DATA` — Business Systems & Data Coordinator.

Operational support events should resolve named employees from current position incumbency when Phase 3 data is generated.

---

## Relationship with other business domains

The architecture preserves specialist business ownership even where IT supports the application:

- Finance owns financial business content in ERP and banking processes;
- HR owns employment/payroll business content in People & Payroll;
- Sales owns commercial/customer relationship content in CRM;
- Production owns production execution/product technical structures represented in MES/ERP;
- Quality owns technical quality decisions and quality records represented in QMS;
- Maintenance owns maintenance work-management content in CMMS;
- Marketing owns brand/claims/content governance even where Microsoft 365 or Label Design & Printing is used;
- Logistics and Procurement own their operational/commercial structures even where ERP carries their transactions.

---

## Architecture boundaries — operational data intentionally excluded

This workbook contains no historical or transactional IT records such as:

- user accounts or account histories;
- actual permissions or group memberships;
- login/sign-in events;
- integration executions;
- interface files/messages;
- failed integrations;
- retries;
- interface runtimes;
- system uptime/downtime history;
- incident tickets;
- service requests;
- support cases;
- system alerts;
- security alerts;
- vulnerability findings;
- patch deployments;
- software-version history;
- release/deployment history;
- change requests;
- change approvals;
- backup jobs;
- restore attempts;
- device inventory;
- server/network inventory;
- endpoint health;
- capacity/utilization metrics;
- vendor support tickets;
- license consumption.

Those belong to later architecture workbooks or Phase 3 operational datasets.

---

## Story neutrality

The architecture does not deliberately seed outcomes such as:

- integration failures;
- outages;
- authentication problems;
- weak access controls;
- missed joiner/mover/leaver actions;
- stale reporting;
- unsupported applications;
- poor change control;
- backup failures;
- security incidents;
- vendor-service deterioration.

These patterns should be chosen deliberately in **Phase 2 — Stories**.

---

## Recommended AI use

For fast context:

1. read this Markdown file;
2. inspect `System_Technical_Profile` for a system-level question;
3. inspect `Integration_Interfaces` for system-to-system exchange;
4. inspect `Integration_Data_Scope` when source-of-truth/data ownership matters;
5. inspect `System_Dependencies` for outage/dependency analysis;
6. inspect `System_Support_Model` for technical responsibility;
7. inspect `Source_Precedence` whenever domain ownership is ambiguous.

Useful shortcuts:

- "How is system X technically hosted/authenticated?" -> `System_Technical_Profile`
- "What components make up system X?" -> `Application_Components`
- "Does system X have test?" -> `Environment_Definitions`
- "How do systems X and Y exchange data?" -> `Integration_Interfaces`
- "Who owns the data moved by an interface?" -> `Integration_Data_Scope`
- "What does system X depend on?" -> `System_Dependencies`
- "Who supports system X?" -> `System_Support_Model`
- "When may system X be changed?" -> `Maintenance_Change_Windows`
- "Which source wins?" -> `Source_Precedence`

---

## Overall role

Together, this workbook and Markdown file form the static **technical systems and integration layer** for HAV Seafood.

They connect the existing Shared Enterprise application landscape to technical hosting, application components, environments, integration mechanics, governed data scope, dependencies, technical support and change rules while preserving business ownership in the relevant enterprise domains.

This creates enough structure for later synthetic IT logs, integration histories, support records, change activity and cross-functional stories without introducing operational history during Phase 1.
