Architecture Commit Prep Pack
Purpose: prepare for the Architecture Commit role by reducing the meeting recordings into a decision-ready brief. This is the short version of architecture-commit-briefing.html.
Customer-facing solution POV: customer-solution-point-of-view.html.
1-Page Summary
The program is aligning on Lumen Vision / OneVision as the core workflow and orchestration surface for network implementation, planning, grooms, SiteTracker/Netbuild/Armor exits, and related field workflows. The architecture is not a simple tool replacement. It is a staged transformation across order management, service delivery, planning, inventory, procurement, field work, reporting, and AI-assisted workflow automation.
The most important architecture pattern is layered ownership:
- Authoritative systems remain distributed.
- Lumen Vision becomes the structured workflow/work surface.
- Kafka/CFKA provides event-based integration and traceability.
- Data Hub and reporting layers provide read-side visibility.
- AI/ADO can only be trusted after source-of-truth, lineage, rollback, replay, and auditability are solved.
The immediate architecture commit should focus on boundaries, canonical objects, integration contracts, and release sequencing. The diagrams repeatedly show that major dependencies include Lumen Vision, Flight Deck, Itential, BPI, Netbuild, FOA, ByFrost, Kafka 2.0, BlueSteel/SOM, Salesforce/NEO, SAP S/4HANA, GLM/3GIS, BluePlanet, WFM, SiteTracker, Armor, and analytics/reporting tools such as INID.
Recommended Architecture Commit Scope
Commit now:
- Target architecture principles and system boundaries.
- Release 1 workflow scope.
- Canonical object glossary.
- System-of-record/write-authority matrix.
- Integration pattern definitions.
- Kafka/CFKA traceability and event-contract expectations.
- SiteTracker/Project Helix migration boundaries.
- Data-cleansing gate model.
- Delivery-readiness requirements.
Do not overcommit yet:
- Full BluePlanet integration details.
- Fully agentic AI execution.
- Complete replacement of all tasking surfaces.
- Universal forecasting automation.
- Complete migration of all BAU/legacy workflows in one release.
Decision Matrix
| Area | Current Direction | Commit Decision Needed | Suggested Position |
|---|---|---|---|
| Lumen Vision role | Workflow/orchestration surface | Is it source of truth, orchestrator, work surface, or all three by object? | Define by object and workflow. Avoid blanket ownership. |
| Order initiation | Lumen Vision visible as decision point for RNI | Applies to MVP only or all workflows? | Commit for MVP scope, roadmap for others. |
| Task presentation | LV + Flight Deck shown | Who owns task state and completion? | Define task state ownership and sync contract. |
| Workflow entity | LV / Itential / FD unresolved | Which system owns executable workflow? | Use delegated workflow ownership by pattern. |
| Reporting | INID assumed for RNI reporting | Temporary or target reporting source? | Treat INID as assumption pending validation. |
| Data cleanse | Required prerequisite outside LV | How represented in LV? | External gate/milestone with auditable status. |
| Kafka/CFKA | Event backbone | Required headers, IDs, replay, DLQ model? | Make traceability headers a commit blocker. |
| SiteTracker exit | Project Helix path | Lift/shift versus transform boundary? | Hybrid: deadline-safe lift/shift plus planned transform. |
| BluePlanet | Future inventory target | In Release 1 or dependency only? | Dependency only until object/data exchange model is agreed. |
| SAP S/4HANA | Funding, procurement, materials | Which objects/fields integrate first? | Start with BOM/material/funding use cases. |
| WFM/Field | Field work migration to SFS/WFM | What must LV send/receive? | Define bidirectional task/status contract. |
| AI/ADO | Roadmap capability | Recommendation versus action boundary? | Human-approved actions until governance matures. |
| Date management | Cross-cutting issue | Who owns baseline/forecast/actual? | Define canonical date fields and ownership. |
Core Architecture Questions
Ask these first:
- What exactly must be approved at architecture commit: conceptual target, release scope, integration design, or delivery-ready design?
- Which workflows are in Release 1: RNI install/disconnect, grooms, waves, dark fiber, planning/network opportunity, SiteTracker exit, or SOM 2.0?
- For each core object, which system owns creation, update, and lifecycle state?
- What is the canonical object model for project, order, service order, network order, task, site, route, BOM, permit, and milestone?
- Which integrations are event-based, synchronous API, embedded UI, read-only view, or temporary manual/flat-file?
- What traceability header/correlation ID is mandatory across Salesforce, BlueSteel/SOM, Lumen Vision, BPI, Kafka, BluePlanet, and reporting?
- What is the cutover strategy for new, in-flight, and historical SiteTracker/Netbuild/Armor work?
- What data-cleansing status must be known before network work can proceed?
- Which AI/ADO capabilities depend on source-of-truth, lineage, rollback, replay, and auditability?
- What environments, UAT gates, rollback/replay controls, and observability are required before production cutover?
Suggested Talking Points
- “I think the commit should be object-boundary first, not tool-first. Lumen Vision can be the work surface without owning every object.”
- “The diagrams show LV + FD and LV / Itential / FD, so we should explicitly decide where workflow execution lives by workflow type.”
- “Kafka 2.0 headers and traceability look like shared enablers, not implementation details. I would treat them as architecture commitments.”
- “For SiteTracker exit, we should separate deadline-driven migration from future-state transformation so the roadmap does not collapse under scope.”
- “The AI roadmap depends on trusted operational data. I would not commit agentic execution until lineage, auditability, rollback, replay, and human approval boundaries are clear.”
- “Date ownership needs explicit architecture treatment. Baseline, forecast, projected, actual, and need-by dates cannot be casually synchronized.”
- “ByFrost appears as a single pane in the target sketch. We should clarify whether that means UI aggregation, task distribution, context packaging, or source-of-truth behavior.”
Main Risks
| Risk | Why It Matters | Mitigation |
|---|---|---|
| Tool-first architecture | Creates vague ownership and future conflict | Use object/system-of-record matrix |
| Hidden integration enablers | Kafka headers, CDC, replay, DLQ, and observability can block delivery | Track enablers as first-class backlog items |
| SiteTracker scope creep | Deadline-driven migration may become full redesign | Freeze migration boundary and backlog transformation separately |
| AI overcommitment | Bad data can scale into bad actions | Keep AI human-supervised until governance/data foundation is proven |
| Date inconsistency | Forecasting and milestone automation fail without ownership | Define canonical date model |
| Task ownership ambiguity | Users may still swivel-chair or duplicate updates | Define task lifecycle and write-back contract |
| Reporting mismatch | INID, dashboards, Data Hub, and LV may disagree | Define reporting source and reconciliation model |
| Environment weakness | Multi-system changes are hard to test safely | Commit integration/UAT/pre-prod model |
Suggested Architecture Artifact Set
Prepare or request these artifacts:
- Context diagram: systems and boundaries.
- Object ownership matrix: create/update/read/lifecycle owner. First draft: system-of-record-matrix.html.
- Integration inventory: source, target, pattern, object, frequency, owner, status. First draft: integration-inventory.html.
- Workflow scope map: Release 1, Release 2, deferred.
- Event contract outline: Kafka topic/header/correlation/replay/DLQ expectations.
- Migration/cutover plan: SiteTracker, Armor, Netbuild, Flight Deck, WFMT.
- Data governance model: lineage, audit, rollback, replay, cleansing gates.
- Delivery readiness checklist: environments, UAT, rollback, observability, support.
Meeting narrative draft: architecture-commit-slide-outline.html.
Meeting Q&A and architecture diagram: architecture-commit-qa-and-diagram.html.
Customer solution POV: customer-solution-point-of-view.html.
Your Stance
Recommended Architecture Commit stance:
Support Lumen Vision as the structured workflow and orchestration surface, but push for precise system boundaries. The commit should approve a staged architecture with clear ownership, integration contracts, and release sequencing. It should not imply that Lumen Vision instantly becomes the source of truth for all objects or that AI can execute autonomously before the data and governance foundation exists.