Contact

Architecture through implementation.

Technical advisory and engineering across the delivery lifecycle.

Solution architecture, engineering, modernization and adoption support for defined technical requirements or larger delivery programs.

Discuss your projectSee the worked example
A sculptural ceramic and titanium bridge connects two solid foundations.
Illustrative study

Requirements and approach

Who it serves · The problem · What this does

Who it serves

Executives, technology leaders, program managers and delivery partners who need technical judgment and implementation support.

The problem

Unresolved architecture, disconnected platforms and unclear ownership can delay a program even when its objectives are well defined.

What this does

8Pact provides technical advisory, solution architecture, software and systems engineering, integration and modernization. Engagements can address a specific decision or span design through implementation.

Worked example on synthetic records

Professional Services

Illustrative workflow · Fictional records · Not client work

A date conflict stopped task T-2231 instead of passing silently into the work queue.

Three fictional systems each hold part of one inspection task. Start at the working screen, then trace how the record was mapped, checked, held at an exception for its owner, and delivered. All names, systems and records are fictional.

The path runs from the three systems, through the foundation, up to the operator screen. The exception shows the decision taken, and the connection carries a failure route.
Work queue · InspectionsSync 06:30 · 3 sources OK

Queue · 4 tasks

  • T-2228Fire door survey · ST-02Ready
  • T-2229Roof access check · ST-04Ready
  • T-2231Quarterly site inspection · ST-04Held
  • T-2234Lift certificate review · ST-07Ready

T-2231

Quarterly site inspection

Held · decision pending

EX-0192

Scheduled after the contract due date. Held for the Scheduling system owner. This task is not shown as Ready.

Select a field to trace it through the model, from its source to this screen.

Operating handoff

When a connection fails, these people respond

  1. 01DetectThe connection itselfA failed or late run marks the affected records “Source late”. Old values are never shown as current.
  2. 02First responseIntegration support, named in the handoffChecks the run, reruns it or escalates, and records what happened.
  3. 03Source fixOwner of the failing systemContracts manager, Scheduling system owner or Resource coordinator.
  4. 04FallbackOperations leadDecides when affected tasks move to the documented manual step, and when they come back.

The operator works T-2231 from one screen that shows where each value came from. A named team responds when a connection fails.

Read this workflow as text

  1. 01 · Systems of record

    Three systems each hold part of task T-2231. Every system has a named owner and decides only the facts it is authoritative for.

    • SYS-A Contracts register (register database). Owner: Contracts manager. Authority: Contract, deliverable, site and due date. Access: Read-only, approved by the owner. T-2231 lives at: Contract C-0418, deliverable line D-07.
    • SYS-B Scheduling system (scheduling application, read through its api). Owner: Scheduling system owner. Authority: Task ID, booked start and task status. Access: Read-only API key, approved by the owner. T-2231 lives at: Job 2231.
    • SYS-C Staff roster (sheet) (shared spreadsheet, imported on a schedule). Owner: Resource coordinator. Authority: Who is accountable for a task. Access: Read-only import of two columns, approved by the owner. T-2231 lives at: Row 48, matched on staff number 117.

  2. 02 · Required fields

    The task needs eight fields. Each one has a meaning, a freshness and a rule for which system wins a conflict. Everything else stays out.

    • task_id (Task ID): The unit of work the operator completes. From SYS-B job_id. Freshness: every 15 min. Conflicts: SYS-B. Traced value: 2231.
    • contract (Contract): The agreement this task delivers against. From SYS-A contract_no, joined to sys-b contract_ref c0418. Freshness: daily. Conflicts: SYS-A. Traced value: C-0418.
    • deliverable (Deliverable): What the contract requires on this line. From SYS-A deliv_ref. Freshness: daily. Conflicts: SYS-A. Traced value: D-07.
    • site (Site): Where the work happens. From SYS-A site_code. Freshness: daily. Conflicts: SYS-A. Traced value: st04.
    • due_date (Due date): The latest date the contract allows. From SYS-A deliv_due. Freshness: daily. Conflicts: SYS-A. The contract is the authority. Traced value: 30/11/2026.
    • scheduled_start (Scheduled start): When the work is booked to begin. From SYS-B start_dt. Freshness: every 15 min. Conflicts: SYS-B. Must fall on or before the due date. Traced value: 02-DEC-26 0800.
    • owner (Owner): The person accountable for doing the task. From SYS-C name, matched on staff number from sys-b crew_ref 117. Freshness: hourly. Conflicts: SYS-C. Never guessed if empty. Traced value: Okafor, J..
    • status (Status): Where the task stands for the operator. From SYS-B status_cd. Freshness: every 15 min. Conflicts: SYS-B, unless an exception holds the record. Traced value: SCH.
    • Left out on purpose: SYS-A contract_value, SYS-B notes_free, SYS-C phone, SYS-C pay_band.

  3. 03 · Transformation

    Raw values are normalized so they can be compared: IDs, dates, codes and names end up in one shape.

    • task_id: “2231” becomes “T-2231” (R1 · prefix and pad the job number).
    • contract: “C-0418” becomes “C-0418” (R2 · upper-case and hyphenate the join key).
    • deliverable: “D-07” becomes “D-07 · Quarterly site inspection” (R5 · look up the deliverable catalog).
    • site: “st04” becomes “ST-04” (R6 · standard site code).
    • due_date: “30/11/2026” becomes “2026-11-30” (R3 · day/month/year to ISO date).
    • scheduled_start: “02-DEC-26 0800” becomes “2026-12-02 08:00” (R3 · legacy date-time to ISO, site time).
    • owner: “Okafor, J.” becomes “J. Okafor · S-117” (R4 · display order, keep staff number as key).
    • status: “SCH” becomes “Scheduled” (R5 · status code lookup).
    • Check C1, contract c-0418 exists in sys-a and matches sys-b: pass.
    • Check C2, staff number 117 is present and active in sys-c: pass.
    • Check C3, scheduled start is on or before the due date: fail.

  4. 04 · Exception

    EX-0192: Scheduled start is after the contract due date. SYS-B books T-2231 to start on 2 Dec 2026 at 08:00. SYS-A says deliverable D-07 is due by 30 Nov 2026. Each system wins its own field, so neither can overwrite the other. Check C3 fails and the record is held instead of shown as ready. Owner: Scheduling system owner. Consulted: Contracts manager, if the due date itself should move.

    • 06:00: Sync run reads SYS-A, SYS-B and SYS-C.
    • 06:02: Check C3 fails on T-2231.
    • 06:02: EX-0192 raised; T-2231 held from Ready.
    • 06:03: Notice to the Scheduling system owner and the operator queue.
    • Option, fix at source: The Scheduling system owner rebooks job 2231 for 27 Nov in SYS-B. The next sync reads the new date, C3 passes and EX-0192 closes with the change recorded.
    • Option, override with note: Keep 2 Dec. The owner records why, after checking with the Contracts manager. The record is released with the override and its note visible. SYS-A is not changed.
    • Option, hold the manual step: Leave T-2231 on the current manual process until the date is settled. The record stays out of the Ready queue and is marked Held. Nothing is dropped quietly.

  5. 05 · Usable interface

    The operator works T-2231 from one screen that shows where each value came from. A named team responds when a connection fails.

    The operator view lists T-2231 in the inspection work queue with its contract, deliverable, site, due date, scheduled start and owner. Each value shows its source system, and any open exception is shown on the task. The system owner view shows connection health, field lineage and the exception log.

    • Detect: The connection itself. A failed or late run marks the affected records “Source late”. Old values are never shown as current.
    • First response: Integration support, named in the handoff. Checks the run, reruns it or escalates, and records what happened.
    • Source fix: Owner of the failing system. Contracts manager, Scheduling system owner or Resource coordinator.
    • Fallback: Operations lead. Decides when affected tasks move to the documented manual step, and when they come back.

Delivery process

Steps · review points · the decision

  1. Understand

    Align on the program, users and constraints.

  2. Design

    Compare options and document the architecture.

  3. Implement

    Build and integrate the agreed capabilities.

  4. Enable

    Prepare users and operating teams for the change.

  5. Transition

    Document decisions, responsibilities and the next release.

Where a person decides

Review points on the line above

Review gateProfessional Services

Where
At the review points agreed for the engagement.
Who
The designated client and delivery owners.
Decision
Approve, request changes or resolve dependencies under the engagement terms.

Scope and deliverables

Potential scope · Deliverables · Your input

Potential scope

  1. Solution architecture and technical advisory
  2. Application and systems engineering
  3. Cloud, platform and data modernization
  4. Integration and implementation support
  5. Technology selection, adoption and knowledge transfer

What you receive

  1. Architecture and implementation documentation
  2. Documented decisions and delivery dependencies
  3. Software, integrations or other agreed technical deliverables
  4. A transition and adoption plan

What we need from you

  1. A delivery sponsor and relevant system owners
  2. Access to the architecture and program context
  3. Agreed responsibilities, milestones and acceptance criteria

Acceptance criteria

04 checks · how each is judged

CheckHow it is judged
FitDoes the design address the stated requirements?
IntegrationDo systems exchange the intended data correctly?
ReadinessCan users complete the work and operators support it?
HandoffAre decisions, dependencies and ownership documented?

Deliverables, acceptance criteria, schedule and support are defined in the engagement agreement.

Discuss your requirements

Discuss your architecture, engineering or program delivery requirements.

Discuss your project See how we work