Integrated Tech Stack
Module 4 is the data infrastructure layer of the operating system. It ensures that every system in the company talks to every other system through a governed integration hub, creating the single source of truth that Modules 3, 5, 6, 7, and 11 depend on.
Module 4 receives two upstream signals from Module 1. The AI Readiness Index score on tool stack compatibility directly determines the architecture pattern. Data hygiene decides whether centralization comes first. A red score on data hygiene forces Module 4 to prioritize data centralization before any other integration work begins. A red score on tool stack compatibility makes Hub-and-Spoke architecture non-negotiable and allocates a dedicated Integration Steward at 10% FTE. These are the defaults the diagnostic sets, and leadership confirms them at the quarterly review.
Module 1 also routes a signal from the Leadership DNA Radar. Red on cross-functional collaboration means Module 4 must prioritize system integration over individual tool optimization, because the humans are not bridging the departmental gaps. The technology must bridge them instead.
This is the difference between a tech stack strategy and a system requirement. Standalone integration projects ask "what should we connect?" Module 4 already knows, because Module 1's heat-map told it what is broken and which architecture pattern fixes it.
Why Integration Projects Fail
The average mid-market company runs 12 to 25 SaaS tools. Employees lose 12 or more hours per month navigating between fragmented systems. The data exists in multiple places, and no two versions agree.
Pattern 1: Point-to-point spaghetti. The first integrations happen organically. CRM connects to email. Email connects to project manager. Project manager connects to invoicing. Each connection is built independently. By 10 tools, 45 connections exist and nobody can map data flows. A change in one system breaks three others.
Pattern 2: Integration without governance. A company implements an integration hub but does not assign an owner or establish change-control. Teams build automations independently. Shadow integrations appear. Within six months, 80 workflows exist and nobody tracks which are critical.
Pattern 3: Data quality treated as a downstream problem. The company connects its systems but does not clean the data flowing between them. Duplicate records proliferate. Stale data persists. The BI dashboards that Module 3 depends on show numbers that nobody trusts. The integration created speed without accuracy.
Module 4 addresses all three patterns through a structured architecture selection process (not spaghetti), a change-control SOP with a named Integration Steward (not anarchy), and a Data Quality Monitor that catches problems before they reach downstream modules (not hope).
System Inventory and Blueprinting
What it does
Before connecting anything, Module 4 requires a complete inventory of every system in the company. The System Inventory Sheet captures five data points per tool: owner, API access availability, data objects captured, refresh cadence, and monthly cost.
The blueprint test
A useful diagnostic: "Can you explain to a new hire how data moves from a sale to an invoice to a dashboard in under 60 seconds?" If the answer is no, the data flow is not documented. Module 4 fixes this by producing a blueprint diagram that shows every system, every connection, and every data flow in a single visual.
Connection to Module 9
The System Inventory Sheet is a direct input to Module 9 (Exit and Acquisition Layer). In any M&A transaction, the acquiring company's technical team will ask for a complete systems map with integration points identified. Companies that have this ready demonstrate operational maturity. Companies that do not reveal integration risk that depresses the valuation.
Integration Hub Patterns
Three options
Module 4 evaluates three architecture patterns and recommends one based on company size and complexity.
Point-to-Point. Direct connections between individual systems. Easiest to set up initially. Becomes unmanageable beyond five systems. Not recommended for the VWCG OS target market, which typically runs 12 or more tools.
Hub-and-Spoke. All systems connect to a central integration hub. The hub routes data between systems according to defined rules. Examples include Zapier, Make, Workato, and Tray.io. Recommended for companies with 25 to 200 FTE. Manages complexity as the system count grows. Module 4's default recommendation for most implementations.
Data Lake or Warehouse. A centralized repository for raw data, designed for complex analytics. Examples include Snowflake and BigQuery. Best suited for analytics-heavy organizations or companies preparing for Module 7's AI deployment pipeline, which requires large datasets for model training.
How Module 1 determines the pattern
For companies that score green or amber on tool stack compatibility, Module 4 uses a decision matrix based on volume, latency needs, IT resources, and budget. A red on data hygiene puts data centralization first.
For companies that score red on tool stack compatibility, the default is Hub-and-Spoke, confirmed by leadership at the quarterly review. A red on data hygiene alone sets data centralization first, not the pattern. Hub-and-Spoke is non-negotiable. The red score indicates that the current tool stack cannot be integrated safely without a governed hub. Point-to-Point would compound the problem. Data Lake would add complexity before the foundation is ready. Hub-and-Spoke provides centralized governance with manageable implementation effort.
Module 1's diagnostic turns the architecture choice into a default that leadership confirms, rather than an open debate.
The Data Quality Monitor
What it does
The Data Quality Monitor tracks three critical metrics: integration uptime, data latency, and duplicate record count.
Three automated checks
Row-count parity. A daily check compares CRM record counts to the data warehouse. Divergence above 1% flags sync failures before they affect Module 3's KPI dashboards.
Duplicate detection bot. A nightly job fuzzy-matches records on email and company name, reporting to the Integration Steward. Duplicates corrupt client health, pipeline metrics, and people analytics. Catching them prevents cascading errors.
Latency alert. If task completion sync exceeds 15 minutes, the system alerts the Integration Steward. Module 3's weekly cadence requires data under 24 hours old. Excess latency means the Monday huddle works with stale numbers.
Downstream dependencies
The Data Quality Monitor exists because five downstream modules consume data from the integrated tech stack:
- Module 3 (KPI Precision Grid): Every dashboard metric passes through the integration hub. Bad data at the hub means bad data on the dashboard.
- Module 5 (Client Success Loop): Health scores aggregate data from CRM, support tickets, and usage analytics. Duplicate records or sync failures produce misleading health scores.
- Module 6 (Sales Velocity Engine): Pipeline hygiene scores depend on accurate CRM data. Stale opportunity records inflate pipeline value and destroy forecast accuracy.
- Module 7 (AI Deployment Canvas): Machine learning models trained on dirty data produce unreliable predictions. The Data Quality Monitor is a prerequisite for any AI deployment.
- Module 11 (People and Culture Analytics): Engagement pulse data, turnover risk inputs, and DEI metrics all flow through the integrated stack. Inaccurate data produces interventions aimed at the wrong teams.
Change Control and Shadow IT
The change-control SOP
Every modification to the integrated tech stack follows a documented procedure. A new field in the CRM triggers a schema change ticket. The Integration Steward reviews the downstream impact (which integrations does this field feed?), tests the change in a staging environment, and deploys only after confirming that no downstream module is affected.
This connects directly to Module 2 (SOP Codex). The change-control SOP is itself a documented procedure in the SOP Codex, with a taxonomy code, a named owner, and a 90-day review cycle. When Module 2's Review Engine flags the change-control SOP for re-validation, the Integration Steward confirms it still matches current practice.
Shadow IT scanning
Quarterly use of SaaS discovery tools (Torii, Blissfully, or equivalent) identifies unauthorized software. Shadow IT is the enemy of integration because it creates data flows outside the governed hub. If a team adopts a tool without the Integration Steward's knowledge, that tool's data does not appear on Module 3's dashboards, does not feed Module 7's AI models, and does not factor into Module 9's systems map.
The approval process requires CFO and CISO signatures for any net-new platform. This connects to Module 8 (Agile Capital Allocation), where new technology spend must fit within a funding tier, and to Module 12 (Cyber/Data Privacy and Security), where new tools trigger a Privacy Impact Assessment.
What makes this different from standard integration advice
Standard integration advice focuses on connecting tools. The deliverable is a working integration.
Module 4 focuses on governed integration where architecture is determined by diagnostic scores, data quality protects downstream modules, changes follow documented SOPs, new tools require capital and security approval, and systems maps are always audit-ready.
The integration is not the deliverable. The governed data flow across 13 modules is the deliverable.
Who This Module Is For
Module 4 was designed for mid-market companies that have already accumulated a tech stack but have not integrated it around a single source of truth.
These companies have tools. Often too many tools. Each department selected the tools that best serve its needs, which means the sales team's data lives in one system, operations data lives in another, and finance runs its own dashboards from a third source. The numbers never quite match. Leadership meetings spend 15 minutes reconciling data before any decision can be made.
Standard integration consulting solves this problem for a fee and delivers a connected tech stack. Module 4 solves it as part of a 13-module system where the architecture is not a recommendation but a parameter set by diagnostic scores, the data quality is not a project but a continuous monitor, and every downstream module is waiting for the clean data to arrive.
The Working Specification
The instrument scores five dimensions: Architecture Pattern Fit, System Inventory Completeness, Data Quality Monitor Performance, Change Control Governance, and Shadow IT Containment. Weights are version 1.0 calibration defaults from 2026-08-20, tuned to each client during calibration.
The Instrument
The Integrated Tech Stack Diagnostic scores 5 dimensions on a 0 to 5 scale against written anchors. The composite score is a weighted sum with equal weights of 0.20 per dimension. Three standing page metrics carry the published thresholds. Row-Count Parity runs a daily CRM vs warehouse check, and divergence above 1% flags a sync failure. Data Latency Minutes pings the Integration Steward when sync exceeds 15 minutes, and the M03 weekly review needs data no older than 24 hours. Duplicate Record Count comes from a nightly fuzzy-match bot on email and company name.
| Dimension | Weight | What it measures | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|---|
| Architecture Pattern Fit | 0.20 | Current pattern identified (point-to-point, hub-and-spoke, warehouse). Pattern matches the M01-required configuration when AERI tool stack compatibility is red. Blueprint diagram exists and passes the 60-second new-hire test | Point-to-point spaghetti at 10 or more tools. No blueprint. A change in one system breaks three others | Hub exists but workflow sprawl unmanaged (the 80-workflow pattern). Blueprint partial | Pattern matches M01 diagnostic constraint. Single blueprint shows every system, connection, and data flow. 60-second test passes |
| System Inventory Completeness | 0.20 | System Inventory Sheet covers every tool with all five fields: owner, API access availability, data objects captured, refresh cadence, monthly cost. Sheet current within the quarter | No inventory. Tool count unknown within a range. Owners unnamed | Inventory exists for major tools. Fields incomplete. Refresh ad hoc | Every tool inventoried with all five fields. Sheet current and diligence-ready for M09 |
| Data Quality Monitor Performance | 0.20 | All three checks live: row-count parity (1% threshold), nightly duplicate bot, 15-minute latency alert. Alert acknowledgement by Integration Steward tracked | No checks. Dashboards show numbers nobody trusts | Some checks live. Thresholds or ownership unclear. Duplicates found manually | All three checks automated with page thresholds. Steward acknowledges alerts. Downstream modules (M03, M05, M06, M07, M11) consume trusted data |
| Change Control Governance | 0.20 | Change-control SOP exists as a coded M02 entry with 90-day review. Schema change tickets used. Changes tested in staging before deploy. Integration Steward reviews downstream impact | Changes made live with no review. Broken integrations discovered by downstream modules | SOP documented but bypassed under time pressure. Staging inconsistent | Every change ticketed, impact-reviewed, staging-tested. SOP current in the M02 codex. Zero unreviewed production changes in the quarter |
| Shadow IT Containment | 0.20 | Quarterly SaaS discovery scan run. Unauthorized tools found per scan trending. CFO and CISO signoff enforced for net-new platforms | No scans. Teams adopt tools freely. Unknown data flows outside the hub | Scans happen but findings lack remediation. Signoff policy partial | Quarterly scans with remediation log. Net-new platforms blocked without CFO plus CISO signoff. All adopted tools enter the governed hub |
Scoring and Bands
| Band | Range | What it routes to |
|---|---|---|
| Red | 0.0 up to but not including 2.0 | Proposes the owning remediation playbook. Safety routes act on the first reading (Routing table below) |
| Amber | 2.0 to 3.5 inclusive | PB-M04-04 monitoring with 30-day pulse checks |
| Green | above 3.5 up to and including 5.0 | Hold and monitor quarterly through M13 (event-driven for the new-integration signal) |
Routing
Red bands fire the routes below. Every amber dimension routes to PB-M04-04. Every green dimension holds and is monitored quarterly through M13. Conditions read the module 0 to 5 bands unless a row names another scale. A color changes only when a score clears the band edge by a margin, or holds for two consecutive scorings. The margin is 0.25 points on 0 to 5 scales and 5 points on the AERI 0 to 100 scale. Safety routes are the routes that set AI mode in any module, the Privacy Impact Assessment rule, or Module 12 classification and response windows. They tighten on the first reading and loosen only after an independent re-score clears the edge. When two routes set the same parameter differently, the most restrictive value wins for safety routes, and the owning module's value wins for every other parameter. A route that fires from a scored dimension is a proposal until leadership confirms it in the M13 Phase 3 review. Routes that fire from measured values and events (PV2, KPI variance, revenue concentration, dates, and logged events) act on the reading. Scorer agreement has not yet passed the reliability test. A proposal is confirmed at the next monthly governance review or the M13 Phase 3 review, whichever comes first, and a playbook's stated duration starts at confirmation. Routes that restore the M13 cadence itself act on the reading. A route that carries evidence feeds the next scoring of the receiving dimension and never sets a score directly. Module instruments are scored quarterly in weeks 11 to 12 of the M13 cycle, Module 1 in Phase 1, and measured signals at their own review cadence. An RT code names the destination action, so several source rows can share one.
Outbound routes
| Signal | Condition | Destination | What fires |
|---|---|---|---|
| Architecture Pattern Fit | red | M04 PB-M04-01 | Hub-and-Spoke Consolidation Sprint (RT-M04-ARCHITECTURE-RED) |
| Architecture Pattern Fit | red | M01 PB-M01-08 | Confirm the M01 Tool Stack Compatibility red that forces Hub-and-Spoke |
| System Inventory Completeness | red | M04 PB-M04-01 | Hub-and-Spoke Consolidation Sprint |
| System Inventory Completeness | red | M09 PB-M09-03 | M09 marks systems-map evidence stale in the diligence assembly until M04 inventory is amber |
| Data Quality Monitor Performance | red | M04 PB-M04-02 | Data Quality Monitor Standup (RT-M04-DATA-QUALITY-RED) |
| Data Quality Monitor Performance | red | M03 PB-M03-01 | M03 restricts the baseline to metrics whose source passed the M04 parity check |
| Data Quality Monitor Performance | red | M07 PB-M07-02 | M07 blocks new deployments that read from sources failing the Data Quality Monitor |
| Change Control Governance | red | M04 PB-M04-03 | Change Control and Steward Activation (RT-M04-CHANGE-CONTROL-RED) |
| Change Control Governance | red | M02 PB-M02-01 | Change-control SOP must be a coded M02 codex entry with 90-day review |
| Shadow IT Containment | red | M04 PB-M04-03 | Change Control and Steward Activation |
| Shadow IT Containment | red | M08 PB-M08-01 | Net-new platform spend must fit an M08 funding tier |
| Shadow IT Containment | red | M12 PB-M12-02 | M12 runs a discovery scan for tools in use without a completed PIA |
| New-integration signal | on event | M12 PB-M12-02 | PIA before connect, CFO plus CISO signoff evidence (RT-M04-NEW-INTEGRATION-M12) |
| Integration go-live | on event | M10 PB-M10-01 | M10 runs a calibrated adoption sprint, subject to the M10 materiality threshold |
Inbound routes
| Signal | Condition | Source module | What fires in M04 |
|---|---|---|---|
| Cross-Functional Collaboration | red in M01 | M01 | Prioritize system integration over tool optimization (PB-M04-01) |
| Data Hygiene | red in M01 | M01 | Data centralization before any AI project (PB-M04-02) |
| Tool Stack Compatibility | red in M01 | M01 | Hub-and-Spoke architecture non-negotiable, Integration Steward at 10% FTE (PB-M04-01) |
| Baseline Snapshot Integrity | red in M03 | M03 | If distrust traces to integration data quality, escalate to M04 Data Quality Monitor findings (PB-M04-02) |
| Health Score Integrity | red in M05 | M05 | M04 runs a parity and duplicate check on the CRM, support and usage sources feeding health scores (PB-M04-02) |
| Pipeline Hygiene Enforcement | red in M06 | M06 | M04 runs a parity and duplicate check on CRM opportunity data (PB-M04-02) |
| Readiness Gate Discipline | red in M07 | M07 | Foundation work: data integration (PB-M04-01) |
| Systems and Operations Assembly Currency | red in M09 | M09 | M04 refreshes the system inventory and blueprint within the next monthly cycle (PB-M04-04) |
| PIA status signal | on event in M12 | M12 | Block go-live until PIA completes (RT-M04-CHANGE-CONTROL-RED) (PB-M04-03) |
| Pre-Diagnostic Preparation | red in M13 | M13 | Data integrity check overdue (PB-M04-02) |
Playbooks
Every playbook follows one lifecycle: open, running, met or missed, escalated, closed. A trigger that arrives while a playbook is open is logged against the open run. An outcome met, with an independent re-score at amber or better, closes the run, and the owner's next queued red opens. An outcome missed at the end of its stated duration escalates to the owner's manager and the next M13 quarter planning agenda. Someone other than the owner re-scores the dimension. Each owner runs at most three red playbooks at once. Further reds queue, ranked by how many modules the red dimension routes into. Safety playbooks (PB-M07-02, PB-M12-02, PB-M12-03) never queue. A red route opens a red playbook. A route that changes a mode, a cadence, or a data feed runs under the module's standing playbook. When a red playbook's outcome is met, any standing duty it set up continues under the standing playbook, which does not count toward the cap. Escalation for a CEO-owned playbook goes to the board.
PB-M04-01: Hub-and-Spoke Consolidation Sprint (Architecture / Inventory)
Trigger: Architecture Pattern Fit or System Inventory Completeness red, or M01 AERI red on tool stack compatibility forcing Hub-and-Spoke. Also opened by routes from M01 Cross-Functional Collaboration, M01 Tool Stack Compatibility, M07 Readiness Gate Discipline. Builds the System Inventory Sheet for every tool, maps all point-to-point connections, and confirms the M01 diagnostic constraint before selecting the hub platform. Connections migrate into the hub in dependency order: M03 dashboard feeds first, then M05 health-score feeds, M06 CRM pipeline, M11 people data. The single blueprint must pass the 60-second new-hire test. Outcome: blueprint passes the 60-second test, every tool inventoried with five fields, critical flows through the governed hub, steward operating at allocated FTE. Owner: Integration Steward (10% FTE minimum on red) with COO sponsor, 8 weeks.
PB-M04-02: Data Quality Monitor Standup (Data Quality)
Trigger: Data Quality Monitor Performance red, or a data-quality red routed in from M01, M03, M05, M06 or M13. Also opened by routes from M01 Data Hygiene, M03 Baseline Snapshot Integrity, M05 Health Score Integrity, M06 Pipeline Hygiene Enforcement, M13 Pre-Diagnostic Preparation. On M01 Data Hygiene red, it first centralizes customer and financial records into one governed source. It then instruments the three published checks: daily row-count parity above 1% flagged, nightly duplicate fuzzy match on email and company name, and 15-minute latency alert. First-week findings are triaged and fixed at the source system, and monitor output flows to M03 so dashboard trust is visible on the KPI grid. Outcome: all three checks live with page thresholds, findings triaged, signal flowing to M03, alert acknowledgement log started. Owner: Integration Steward, 3 weeks.
PB-M04-03: Change Control and Steward Activation (Governance / Shadow IT)
Trigger: Change Control Governance or Shadow IT Containment red, an unreviewed production change discovered, or a shadow tool found feeding business data. Also opened by routes from M12 PIA status signal. Drafts the change-control SOP (schema change ticket, downstream impact review, staging test, deploy confirmation) and registers it in the M02 codex. All stack modifications freeze onto the ticket path, the first quarterly shadow IT scan runs, and findings are adopted into the governed hub or retired under CFO plus CISO signoff. Outcome: SOP coded in M02 and in use, zero unreviewed production changes since activation, first scan complete with remediation log, signoff path demonstrated on a live request. Owner: Integration Steward with COO, CFO and CISO for net-new signoff, 4 weeks.
PB-M04-04: Stack Hygiene and Amber Monitoring (Amber Path)
Trigger: any M04 dimension amber, or green-state quarterly maintenance. Also opened by routes from M09 Systems and Operations Assembly Currency. Reviews monitor trends weekly and investigates any two-week negative drift. The quarterly cycle runs the shadow IT scan, refreshes the System Inventory Sheet, confirms the change-control SOP passed its 90-day review, and retires dead workflows. Outcome: quarterly cycle completed, scan logged, inventory refreshed, SOP current, M13 recalibration fed. Owner: Integration Steward, standing, with a 30-day pulse check for each amber dimension and green maintenance at the next M13 cycle.
Working templates ship with the module: the system inventory sheet, the change control ticket, and the data quality monitor config. Template artifacts and full playbook bodies are delivered during an engagement.