Back to Main Briefing

Architecture Commit Q&A And Diagram

Purpose: prepare for likely meeting questions and provide a simple architecture diagram with an explanation you can use in discussion.

Architecture Diagram

flowchart LR
    subgraph Channels["Channels / Order Entry"]
        SF["Salesforce / NEO\nProduct Order Source"]
        EXT["External / Partner / Portal / API"]
    end

    subgraph OrderLayer["Order Management"]
        SOM["SOM 2.0 / BlueSteel\nService Order Flow"]
        OM["Order Management\nWaves / Dark Fiber"]
    end

    subgraph Workflow["Workflow / Orchestration Surface"]
        LV["Lumen Vision / OneVision\nWorkflow, Planning, Task Visibility"]
        ADO["ADO / AI Agents\nRecommendations + Human-Supervised Actions"]
    end

    subgraph NetworkExec["Network Execution"]
        BPI["BPI\nNetwork Order / Design"]
        FD["Flight Deck / WFM / SFS\nField Task Execution"]
        BF["ByFrost\nSingle Pane / Context Package"]
        GCR["GCR / ServiceNow Future\nChange Notification"]
    end

    subgraph InventoryPlanning["Planning / Inventory / Build Inputs"]
        GLM["GLM / 3GIS\nSites, Routes, Survey"]
        BP["BluePlanet / VoltRon\nNetwork Inventory"]
        SAP["SAP S/4HANA\nMaterial Master, BOM, Procurement, Capital"]
        DC["Data Cleansing\nExternal Gate"]
    end

    subgraph Integration["Integration And Data"]
        KAFKA["Kafka / CFKA\nEvents, CDC, Headers, Replay, DLQ"]
        HUB["Data Hub\nStitched Read View"]
        RPT["INID / Reporting / Dashboards\nKPIs, Status, Analytics"]
    end

    SF --> SOM
    EXT --> SF
    SOM --> KAFKA
    KAFKA --> LV
    LV --> BPI
    BPI --> KAFKA
    KAFKA --> HUB
    HUB --> LV
    HUB --> RPT

    LV --> FD
    FD --> KAFKA
    LV --> BF
    BF --> FD
    LV --> GCR

    GLM --> KAFKA
    BP --> KAFKA
    SAP --> KAFKA
    LV --> SAP
    DC --> LV

    LV --> ADO
    KAFKA --> ADO
    ADO --> LV

Diagram Explanation

This diagram shows the recommended target pattern for the architecture commit.

The key idea is **layered ownership**. Lumen Vision / OneVision should be treated as the structured workflow and orchestration surface, but not automatically as the source of truth for every object. Salesforce / NEO remains the product order source, SOM 2.0 / BlueSteel handles service-order flow, SAP S/4HANA owns material/procurement/capital domains, GLM / 3GIS and BluePlanet own location/route/inventory domains, and field execution may still happen through Flight Deck, WFM, or Salesforce SFS depending on workflow.

Kafka / CFKA is the connective tissue for state changes, CDC, event replay, traceability headers, and error handling. Data Hub is a stitched read view for consumers and should not become a write path. Reporting tools such as INID and dashboards consume operational state but need clear reconciliation rules.

AI / Adaptive Decision Orchestration should sit on top of trusted workflow and event data. It can recommend next-best actions and support workflow changes, but the architecture should keep actions human-supervised until lineage, auditability, rollback, replay, and guardrails are proven.

Likely Questions And Suggested Answers

1. Are we saying Lumen Vision is the new source of truth?

**Short answer**

Not for every object. Lumen Vision is the workflow and orchestration surface for agreed scope. Source-of-truth ownership should be defined object by object.

**Better meeting answer**

“For some workflow objects, Lumen Vision may become authoritative. But product orders, material master, inventory, field dispatch, and service-order state already have authoritative systems. The architecture should define create/update/read/lifecycle ownership per object rather than making a blanket source-of-truth claim.”

2. Why not make everything flow through Lumen Vision?

Because some systems have legal, operational, or domain authority that should not be bypassed. Salesforce owns product order state, SAP owns material/procurement/capital domains, BluePlanet owns inventory direction, and field systems may own technician execution. Lumen Vision should orchestrate and present work without corrupting source-system ownership.

3. What exactly are we approving?

Approve the staged architecture:

  • Lumen Vision as workflow/orchestration surface for Release 1.
  • Distributed source-of-truth model by object.
  • Kafka/CFKA as shared event and traceability foundation.
  • Defined Release 1 integrations.
  • Data-cleanse gate.
  • Hybrid migration path for SiteTracker/Armor/Netbuild.
  • Human-supervised AI/ADO boundary.

Do not approve an undefined promise that every workflow, integration, and AI action is complete.

4. Why is Kafka 2.0 so important?

Kafka/CFKA is not just plumbing. It provides real-time state movement, replayability, idempotency, traceability, validation, and error handling. SOM 2.0 depends on Kafka 2.0 headers for traceability. Without the event/header standard, cross-system workflows will be hard to debug, reconcile, or automate safely.

5. Why defer full BluePlanet write integration?

The meetings show BluePlanet as the target inventory consolidation platform, but the object boundary is not yet clear enough. GLM/3GIS, BluePlanet, BPI, Lumen Vision, and planning workflows all touch site, route, design, and inventory concepts. The architecture should first define the information model and ownership split, then commit write integration.

6. What is the biggest risk?

The biggest risk is vague ownership. If Lumen Vision, Flight Deck, WFM, BPI, ByFrost, SAP, BluePlanet, and reporting systems all appear to own overlapping task/order/date/inventory state, teams will recreate swivel-chair work in a new form.

7. What should we say about AI?

AI should be positioned as roadmap capability sitting on top of trustworthy operational data. The source-of-truth slide explicitly says AI is only as reliable as the data layer below it. Agentic execution should remain human-supervised until governance, lineage, auditability, rollback, replay, and permissioning are proven.

8. What is ByFrost in the target architecture?

Based on the diagrams, ByFrost appears to be a single-pane/context layer for network/field execution. The open question is whether it is only a UI/context aggregator or whether it owns operational task/context state. That should be clarified before commit.

9. What is the practical Release 1 scope?

Recommended Release 1:

  • Salesforce/NEO/SOM order events into Lumen Vision.
  • Kafka 2.0 headers and traceability.
  • Lumen Vision to/from BPI for network order/design visibility.
  • Selected LV to/from Flight Deck or WFM task/status sync.
  • Data-cleanse gate in workflow.
  • Read-only Data Hub stitched view.
  • SiteTracker cutover/migration feed for net-new and selected active projects.

10. What should be explicitly deferred?

Defer or constrain:

  • Full BluePlanet write integration.
  • Universal grooms migration.
  • Fully automated forecasting.
  • Autonomous AI actions.
  • Broad partner live integrations before security/legal/data contracts.
  • Complete retirement of every tasking surface in one release.

Objection Handling

Objection: “This is too cautious.”

**Response**

“The caution is targeted. We can move quickly on Release 1 if we are precise about object ownership and integration contracts. The risk is not moving slowly; the risk is making a broad commitment that later collapses into conflicting system behavior.”

Objection: “Users do not care about source-of-truth matrices.”

**Response**

“Users care when dates disagree, tasks duplicate, dashboards conflict, and updates disappear. The matrix is how we prevent those user-facing failures.”

Objection: “We need no swivel chair now.”

**Response**

“Agreed as a target experience. The implementation can use different patterns: direct API action, event sync, embedded UI, or context package. We should decide which pattern applies by workflow instead of assuming one pattern fits every system.”

Objection: “AI can solve the workflow complexity.”

**Response**

“AI can help once the workflow state is trustworthy. If the underlying order, task, inventory, and date data is inconsistent, AI will scale inconsistency. The architecture should first make the data auditable and replayable.”

Objection: “Why keep legacy systems in the diagram?”

**Response**

“Because the migration path matters. SiteTracker, Armor, Netbuild, Flight Deck, and WFMT are not the target, but they are part of the cutover reality. Leaving them off the diagram hides migration risk.”

Questions To Ask In The Meeting

  1. For Release 1, which objects does Lumen Vision actually create or update?
  2. Which systems remain authoritative for order, task, inventory, BOM, site, route, and date fields?
  3. What is the minimum Kafka 2.0 header standard?
  4. Does ByFrost own state or only package/display context?
  5. Is INID the target reporting source or a temporary assumption?
  6. Which workflow execution engine owns which paths: Lumen Vision, Itential, Flight Deck, or BPI?
  7. What is the cutover rule for new, in-flight, historical, and duplicate SiteTracker/Netbuild/Armor records?
  8. Which integration failures block workflow progression versus create fallout tasks?
  9. What actions can AI recommend, and what actions can it execute after human approval?
  10. What environments exist for multi-system integration testing and rollback?

Recommended Closing Position

“I support committing to Lumen Vision as the structured workflow and orchestration surface for the agreed Release 1 scope. My recommendation is that approval should be conditional on clear object ownership, integration patterns, traceability headers, data-cleanse gates, migration boundaries, and human-supervised AI controls. That gives the team a real architecture to build against without pretending every downstream detail is already settled.”