HLD

17 min readJul 15, 2026

# Summary

The final HLD positions **Delphi as the orchestration platform** for Tillman/EATON proactive and reactive troubleshooting. The solution introduces a new **EATON TMF-653 Java FT**, enhances the existing **Java Alarm Monitoring service** for TMF-656, modifies the **C++ DTE** to route Tillman PON commands, and introduces a new **EATON TMF-621 Java FT** for trouble-ticket integration over VMB/Kafka. Existing iView, CPEM, HNM, GWR, PCRF, iVAPP, K2View, NAR and prediction flows remain predominantly BAU.

## Your Role and Responsibility

As the **Delphi–Tillman Integration Architect**, you are responsible for:

* Finalizing HLD, ICD and LLD.
* Confirming impacted Delphi, CNS and K2View modules.
* Defining module-level impact and technology ownership.
* Coordinating Java, C++, RabbitMQ, VMB/Kafka, Apigee and database implementation.
* Validating proactive and reactive before/after flows.
* Tracking assumptions and unresolved items as explicit TBDs.
* Reviewing the design with Kishore before architecture approval.

— -

# High-Level Design

## Verizon Delphi — EATON/Tillman Integration

— -

# 1. Purpose

This HLD defines the target solution architecture for integrating Verizon Delphi with the EATON/Tillman PON ecosystem.

The design supports:

* Proactive troubleshooting.
* Reactive troubleshooting.
* Real-time PON service-test execution.
* PON alarm ingestion.
* Trouble-ticket and group-outage communication.
* Existing Delphi workflow reuse.
* Internal event distribution through VMB/Kafka.
* Secure external communication through Apigee.

— -

# 2. Business Objective

The project enables Verizon to troubleshoot customer services that traverse a Tillman-owned PON without giving Delphi direct dependency on Tillman EMS or device-specific implementation.

The design provides:

* Standard TM Forum interfaces.
* Centralized troubleshooting orchestration.
* Separation of Verizon and Tillman network ownership.
* Reuse of existing Verizon workflows.
* Faster reactive diagnosis.
* Proactive alarm-based prediction.
* Centralized ticket and outage exchange.

— -

# 3. Scope

## 3.1 In Scope

### TMF-653 Service Test Management

* Build a new **EATON TMF-653 FT** as a Java microservice.
* Support real-time commands against EATON OLT/ONT/PON.
* Support both proactive and reactive troubleshooting.
* Translate Delphi XML/RabbitMQ messages to TMF REST/JSON.
* Process synchronous acknowledgement and asynchronous test completion.
* Return normalized results to DTE.

### TMF-656 Service Problem Management

* Enhance the existing Java Alarm Monitoring service.
* Receive EATON PON alarms/service-problem events.
* Normalize AID, timestamp, timezone, category and severity.
* Write events to existing alarm logs.
* Send normalized alarms to K2View using existing BAU flows.
* Feed ticket-prediction and call-prediction inputs.

### TMF-621 Trouble Ticket Management

* Build a new **EATON TMF-621 FT** as a Java microservice.
* Support bidirectional ticket operations.
* Publish EATON-originated ticket and group-outage events to VMB/Kafka.
* Allow vRepair/UTP or approved internal applications to initiate EATON ticket operations.

### Delphi and DTE

* Enhance the C++ DTE.
* Add EATON command routing.
* Add proactive and reactive command mappings.
* Add RabbitMQ request/response queue routing.
* Add TMF-specific timeout and error mapping.
* Add ATest simulation coverage.

The final architecture explicitly identifies these as the principal new builds and major-impact components.

— -

## 3.2 BAU / Reused Components

The following remain BAU or require regression testing only:

* iView topology and iView FT.
* CPEM inventory.
* HNM home-network inventory and troubleshooting.
* GWR commands through GWRNG FT.
* PCRF subscriber-profile retrieval.
* iVAPP configuration commands.
* Router activation, including tech-install and self-install.
* Existing proactive prediction script.
* NAR customer-profile feed.
* K2View customer-profile and topology functions.
* CNS downstream notification and affected-customer processing.

— -

## 3.3 Out of Scope

* Development of EATON OSS platforms.
* Changes to EATON network elements.
* Replacement of existing Verizon home-network or GWR troubleshooting.
* Redesign of CNS, NSP or VZ Maps.
* Customer-facing UI redesign.
* Other TMF APIs outside TMF-653, 656 and 621.

— -

# 4. Key Architecture Principles

1. **Delphi remains the orchestration platform.**
2. **Tillman-specific PON access is isolated behind Java FTs.**
3. **DTE continues using RabbitMQ/XML internally.**
4. **External EATON communication uses REST/JSON TMF APIs.**
5. **Existing Verizon FTs remain unchanged for non-PON domains.**
6. **VMB/Kafka is used for internal event distribution, not as the external COS entry point.**
7. **K2View and prediction flows are reused.**
8. **CNS remains downstream and BAU.**
9. **New mappings must be configuration-driven.**
10. **Every asynchronous event must support correlation and idempotency.**

— -

# 5. Target High-Level Architecture

```text
VERIZON CHANNELS

IVRU | myvz.com | NSP | iVAPP | DTIX | Optix Repair | Omega
|
v
APIGEE / AMP
|
v
+ — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — +
| DELPHI |
| |
| Interface Handlers / FiOS Job Manager |
| | |
| v |
| DTE (C++) |
| | |
| RabbitMQ request/response queues |
| | |
| + — — — — — — — -+ — — — — — — — — — — — + — — — — — — — — — — — + |
| | | | |
| v v v |
| Existing FTs EATON TMF-653 FT EATON TMF-621 FT
| iView/CPEM/PCRF/HNM/ Java microservice Java microservice
| GWR/iVAPP/WSG | |
| | TMF-653 | TMF-621
| v v
| EATON Troubleshooting OSS EATON Ticket OSS
| |
| Enhanced Alarm Monitoring Java Service |
| ^ |
| | TMF-656 |
+ — — — — — — — — — -| — — — — — — — — — — — — — — — — — — — — — — — — +
|
v
EATON Alarm Monitoring OSS

Internal downstream:
Alarm Logs -> K2View -> Prediction Script -> Delphi
TMF-621 FT -> VMB/Kafka -> vRepair/UTP/approved consumers
```

The diagrams on pages 2 and 4 show the same logical split: existing FTs are retained, while EATON 653 FT, 621 FT, DTE and Alarm Monitoring receive the major changes.

— -

# 6. Component Architecture

## 6.1 EATON TMF-653 FT

### Technology

* Java microservice.
* REST/JSON external communication.
* RabbitMQ/XML internal communication.
* OAuth2 bearer-token authentication through Apigee.

### Responsibilities

* Consume DTE requests.
* Identify requested EATON command.
* Map the command to a TMF-653 service-test specification.
* Submit the service test.
* Store correlation data.
* Receive or retrieve asynchronous results.
* Convert results to Delphi XML.
* Publish the response to the corresponding RabbitMQ queue.
* Maintain audit, retry and timeout state.

— -

## 6.2 Enhanced Alarm Monitoring Service

### Technology

* Existing Java microservice.
* TMF-656 REST/JSON.
* Existing alarm-log and K2View interfaces.

### Responsibilities

* Receive ServiceProblem create/state-change events.
* Validate and deduplicate events.
* Parse EATON AID.
* Normalize source timestamps and timezone.
* Map EATON categories to Delphi alarm categories.
* Map EATON severity to Verizon severity.
* Generate raise/clear alarm lifecycle.
* Persist/write alarm logs.
* Forward normalized alarms to K2View.

— -

## 6.3 EATON TMF-621 FT

### Technology

* New Java microservice.
* REST/JSON external communication.
* VMB/Kafka internal distribution.
* OAuth2 through Apigee.

### Responsibilities

* Create EATON trouble tickets.
* Update ticket status and notes.
* Retrieve ticket status.
* Process EATON-originated tickets.
* Normalize group-outage events.
* Publish inbound events to VMB.
* Consume approved outbound requests.
* Maintain ticket correlation and lifecycle history.

— -

## 6.4 DTE

### Technology

* C++.
* RabbitMQ.
* XML.

### Responsibilities

* Identify EATON-owned PON topology.
* Route EATON commands to the TMF-653 FT.
* Continue routing non-EATON commands to existing FTs.
* Map workflow commands to FT request XML.
* Wait for FT response or asynchronous completion.
* Resume ticket-prediction, call-prediction or reactive workflows.
* Map TMF failures to Delphi error outcomes.

— -

## 6.5 Existing FTs

| FT | Technology | Target system | Change |
| — — — — | — — — — — | — — — — — — — — — — — — — — | — — — |
| iView FT | Java | iView | Reuse |
| CPEM FT | C++ | CPEM | BAU |
| HNMNG FT | C++ | HNM | BAU |
| GWRNG FT | C++ | Juniper/GWR | BAU |
| PCRF FT | C++ | PCRF | BAU |
| iVAPP FT | C++ | iVAPP | BAU |
| WSG FT | C++ | Existing alarm/customer data | BAU |

— -

# 7. Proactive Troubleshooting Architecture

## 7.1 Logical Flow

## 7.2 Supported Proactive Workflows

* Ticket Prediction.
* Call Prediction.
* Trouble Investigation.
* PON alarm correlation.
* Model-Q or equivalent eligibility flows.
* Existing customer-impact logic.

— -

# 8. Reactive Troubleshooting Architecture

## 8.1 Logical Flow

## 8.2 Ticket Escalation Flow

```text
Reactive troubleshooting identifies EATON issue
|
v
Internal application constructs ticket request
|
v
EATON TMF-621 FT
|
v
Apigee
|
v
EATON Ticket Management OSS
```

— -

# 9. TMF Interface Overview

— -

# 10. Internal Interface Design

## 10.1 DTE to TMF-653 FT

## 10.2 Alarm Monitor to K2View

Get social media media’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

## 10.3 TMF-621 FT to VMB

— -

# 11. Module Impact Analysis

— -

# 12. K2View Architecture Impact

## 12.1 Existing Flow

```text
iVAPP / NAR
|
v
Customer Profile & Topology
|
v
K2View Micro DB
```

## 12.2 EATON Extension

## 12.3 Expected K2View Changes

* Add/accept vendor code `EATON`.
* Store ServiceProblem ID.
* Store Product ID.
* Support EATON AID.
* Normalize timestamp.
* Map EATON alarm category.
* Validate Vision customer-ID association.
* Validate prediction-script compatibility.

Actual table and fabric names remain TBD until K2View schema/code review.

— -

# 13. CNS Architecture Impact

No direct TMF endpoint is planned inside CNS.

## Before

```text
vRepair group outage
|
v
Delphi/CNS
|
v
Affected customers
|
v
NSP / VZ Maps / customer notification
```

## After

```text
EATON TMF-621 group outage
|
v
EATON TMF-621 FT
|
v
VMB
|
v
vRepair
|
v
Existing Delphi/CNS flow
```

### Expected CNS impact

* Functional regression.
* Validate new outage source and identifiers.
* Validate Product/Vision ID mapping.
* Validate ETR and outage-status mapping.
* No confirmed new CNS service or database table.

— -

# 14. Data Architecture

## 14.1 Logical Data Objects

* TMF-653 transaction.
* Service-test acknowledgement.
* Service-test result.
* Service-test callback.
* TMF-656 event.
* Normalized alarm.
* TMF-621 ticket.
* Ticket status history.
* Integration audit.
* Retry and DLQ records.
* Outbox event.

## 14.2 Proposed Persistence

Actual production table names are **not confirmed** in the PDF and must be finalized during LLD/code analysis.

— -

# 15. Security Architecture

## Controls

* OAuth2 client-credentials flow.
* Dedicated service account per environment.
* Bearer-token caching and renewal.
* TLS 1.2 or higher.
* Certificate and truststore management.
* IP/proxy whitelisting.
* Secret masking.
* Payload threat protection.
* API quotas.
* Correlation-ID propagation.
* Role-based access for VMB and databases.

— -

# 16. Reliability Architecture

## 16.1 Idempotency

## 16.2 Retry

Retry:

* Timeouts.
* HTTP 429.
* HTTP 502/503/504.
* RabbitMQ temporary failure.
* VMB temporary failure.
* Token expiration after controlled refresh.

Do not retry:

* Invalid request.
* Unsupported command.
* Permanent authentication failure.
* Missing required identifier.
* Schema-validation failure.

## 16.3 Recovery

— -

# 17. Availability and Scalability

## Java Microservices

* Horizontally deployable.
* Stateless business processing where possible.
* Persistent correlation in DB.
* Multiple instances with consumer-group coordination.
* Health and readiness checks.
* Graceful shutdown.

## DTE

* Existing deployment model retained.
* Queue-based isolation from FT latency.
* Configurable command timeout.
* No long-running HTTP call inside DTE.

## VMB/RabbitMQ

* Durable queues/topics.
* Consumer-group design.
* Dead-letter support.
* Monitoring for queue depth and consumer lag.

— -

# 18. Logging and Observability

## Required Metrics

* TMF-653 requests and acknowledgements.
* Service-test completion time.
* Missing callbacks.
* TMF-656 event rate.
* AID parsing failures.
* Timezone conversion failures.
* K2View publish failures.
* TMF-621 ticket operations.
* RabbitMQ queue depth.
* VMB publish failure.
* Retry and DLQ counts.
* DTE timeout rate.
* OAuth token failures.

## Required Log Context

```text
correlationId
eventId
serviceTestId
serviceProblemId
ticketId
productId
visionCustomerId
commandId
workflowType
sourceSystem
HTTP status
processing status
duration
retry count
error code
```

— -

# 19. Deployment View

Separate environment configuration is required for:

* DEV.
* SIT.
* UAT.
* PROD.

Each environment requires distinct endpoints, credentials, certificates, queues, topics and database configuration.

— -

# 20. Testing Architecture

— -

# 21. Assumptions

1. iView provides EATON topology in the same format used for Verizon topology.
2. Existing iView FT can be reused.
3. CPEM and HNM continue to provide CPE inventory.
4. HNM continues home-network troubleshooting.
5. GWR commands continue through GWRNG FT.
6. K2View continues providing customer Vision ID, PON alarms and ML categories.
7. Existing proactive prediction scripts are reused.
8. iVAPP/NAR continues customer-profile/topology publication.
9. PCRF and iVAPP configuration flows remain BAU.
10. Router activation remains BAU.
11. CNS remains downstream of the vRepair group-outage flow.

These assumptions are listed explicitly in the proactive and reactive highlights.

— -

# 22. Risks and Mitigations

— -

# 23. Implementation Phases

## Phase 1 — Design and Access

* Finalize HLD, ICD and LLD.
* Freeze TMF contracts.
* Identify repositories and tables.
* Obtain Apigee access.
* Obtain credentials and certificates.
* Create RabbitMQ/VMB design.
* Confirm K2View mappings.

## Phase 2 — Shared Integration Framework

* OAuth client.
* REST client.
* Correlation.
* Validation.
* Audit.
* Retry.
* Outbox.
* Metrics.
* Error framework.

## Phase 3 — TMF-653 and DTE

* Build TMF-653 FT.
* Add DTE routes and commands.
* Add callback/result handling.
* Add ATest simulations.

## Phase 4 — TMF-656

* Enhance Alarm Monitoring.
* Add mappings.
* Integrate alarm logs.
* Validate K2View and prediction.

## Phase 5 — TMF-621

* Build ticket FT.
* Add inbound/outbound operations.
* Add VMB publishing.
* Validate vRepair/UTP integration.

## Phase 6 — Hardening

* Security.
* Performance.
* Failover.
* Monitoring.
* Runbook.
* SIT/UAT.

— -

# 24. Open Architecture Decisions

* Final TMF-653 command catalog.
* Exact callback route.
* Final TMF-656 category/severity mapping.
* EATON AID standard.
* Source timezone rules.
* Final TMF-621 ticket-type catalog.
* VMB topic names and retention.
* RabbitMQ queue names.
* Actual Delphi database tables.
* Actual CNS table/module impact.
* K2View schema and payload approval.
* Payload-size limits.
* Retry and SLA values.
* Environment availability.

— -

# 25. Architecture Acceptance Criteria

The HLD is ready for approval when:

* New and impacted modules are confirmed against code repositories.
* Technology and impact levels are accepted.
* Proactive and reactive flows are approved.
* K2View and CNS impacts are validated.
* TMF contracts and command/event catalogs are frozen.
* Apigee, RabbitMQ and VMB designs are agreed.
* Database strategy is finalized.
* Error, retry and observability models are approved.
* Development estimates are aligned.
* Kishore completes review.
* Venkat C approves the architecture baseline.

HLD

Get social media media’s stories in your inbox

Written by social media media

No responses yet

More from social media media

ddd

media

medis InterfaceRequired operationsRecommended Apigee proxiesTMF-653POST /serviceTest, GET /serviceTest/{id}, inbound callback POST2…

🔷 Summary (Your Role & Responsibility)

You are implementing a production-grade FT Adapter (Nokia AMS) with:

ActiveMQ

🔷 Summary (Your Role & Responsibility)

Recommended from Medium

How to simplify systems thinking for solving complex problems

And demonstrating a simple systems thinking process for solving the ecological crises as a whole

Willing to help, afraid to act | Pawse UX case study

How I designed Pawse, an app that helps people get help for injured street animals in India

From 2 AM Alarm to Sub-2 Finish: My VDHM 2026 Story

Race Day — 18th Oct 2026 — VDHM Delhi

Never Beg Someone to Stay, Let Them Walk

One person’s effort cannot replace the other person’s willingness

System Design Interview Series:23/30 [Case Study: Designing a Notification System]

A notification looks like the simplest thing a product does: something happens, someone is told. At scale it is a pipeline that must never…

Business Is War

I’m on my third startup. Along the way I’ve picked up a philosophy for how to approach business, and maybe life.

No responses yet

More from social media media

ddd

media

medis InterfaceRequired operationsRecommended Apigee proxiesTMF-653POST /serviceTest, GET /serviceTest/{id}, inbound callback POST2…

🔷 Summary (Your Role & Responsibility)

You are implementing a production-grade FT Adapter (Nokia AMS) with:

ActiveMQ

🔷 Summary (Your Role & Responsibility)

Recommended from Medium

How to simplify systems thinking for solving complex problems

And demonstrating a simple systems thinking process for solving the ecological crises as a whole

Willing to help, afraid to act | Pawse UX case study

How I designed Pawse, an app that helps people get help for injured street animals in India

From 2 AM Alarm to Sub-2 Finish: My VDHM 2026 Story

Race Day — 18th Oct 2026 — VDHM Delhi

Never Beg Someone to Stay, Let Them Walk

One person’s effort cannot replace the other person’s willingness

System Design Interview Series:23/30 [Case Study: Designing a Notification System]

A notification looks like the simplest thing a product does: something happens, someone is told. At scale it is a pipeline that must never…

Business Is War

I’m on my third startup. Along the way I’ve picked up a philosophy for how to approach business, and maybe life.