Rebuilding a Two-Decade-Old Telecom Workflow for 2026

The Original System Solved a Hard Problem

The platform coordinated work between analysts and managers from intake through completion. It retrieved supporting documents, moved work items through a business-process model, and exchanged transactions with a mainframe. Its presentation layer used server-rendered Java pages and an MVC framework; its middle tier used enterprise Java components on an application server; messaging connected asynchronous work; and a relational database stored operational data. A digitally signed browser applet opened the mainframe interaction window.

For the early 2000s, that was serious enterprise architecture. It centralized transaction management, represented workflow explicitly, and used asynchronous messaging where remote work could not be treated as an immediate local call. Those instincts remain sound. What has changed is the quality of the boundaries we can put around them.

What I Would Keep

• Keep workflow as a first-class concept. Orders with analyst queues, manager approvals, external transactions, document checks, and exception paths are not simple CRUD screens.
• Keep asynchronous integration. Mainframe calls, document retrieval, notifications, and downstream updates should not be hidden behind synchronous assumptions.
• Keep relational truth for operational state. Workflow state, order state, assignments, decisions, and audit history need transactions and queryability.
• Keep document storage outside the core transaction model. Documents have different access, retention, indexing, and lifecycle requirements than order rows.
• Keep human accountability. Every manual decision, override, retry, and approval should be visible, attributable, and reconstructable.

What I Would Change First

The first thing I would remove is direct client coupling to the mainframe. A browser must never need a signed applet, terminal-adjacent component, or privileged bridge to complete a business transaction. The modern replacement is not simply a prettier front end; it is a server-side trust boundary that owns identity, authorization, idempotency, retry, compensation, and evidence.

The second thing I would change is the meaning of workflow state. It should not be smeared across web sessions, EJB calls, queues, database flags, and human memory. The workflow engine should know what step is waiting, why it is waiting, what external effects were requested, which callbacks or timers are outstanding, and what can be retried safely.

A Pragmatic Reference Architecture

The target architecture starts with a browser-native analyst and manager experience, protected by identity and API policy. Behind it is a modular work-management platform that owns orders, assignments, decisions, documents, and exception handling. Durable workflow orchestration coordinates long-running human and system activity. Enterprise adapters isolate legacy systems and external platforms. Events, audit, telemetry, and policy evidence become part of the workflow contract rather than afterthoughts.

Core Modernization Moves

1. A secure, browser-native work experience

I would build the user experience as a React and TypeScript workbench or equivalent modern front end backed by a server-side BFF. The browser authenticates through OpenID Connect and never receives mainframe credentials. Authorization is enforced on the server, and every high-risk action is tied to the authenticated user, role, assignment, and current workflow state.

2. A modular core before a microservice fleet

I would start with a modular Java service boundary using Java 25, Spring Boot 4, and explicit domain modules. Order intake, assignment, document metadata, workflow callbacks, mainframe command preparation, and audit can be separate modules before they become separate deployables. That avoids turning an old distributed system into a new distributed system without first clarifying the domain.

3. Durable BPMN orchestration for people and systems

A BPMN engine such as Camunda, or a durable workflow engine such as Temporal where code-defined workflows fit better, should own the long-running process. It should coordinate analyst tasks, manager approvals, timers, escalation, external calls, retries, and compensating actions. Business rules belong in domain services; the process engine should make state and progress visible.

4. An anti-corruption layer around the mainframe

Mainframe interaction should move behind a versioned adapter layer. That layer translates domain commands into legacy transactions, enforces idempotency keys, validates response mapping, and returns stable domain outcomes. Whether the implementation uses z/OS Connect, MQ, a transaction gateway, or a custom adapter is secondary to the boundary: the domain model must not inherit terminal-era coupling.

5. Data, documents, events, and audit each have a job

Workflow and order state belong in a transactional operational store. Documents belong in object storage or a document platform with metadata in the domain database. Cross-system notifications should flow through a broker using an outbox pattern so committed state and emitted events cannot diverge. Audit history should be append-oriented, queryable, and tied to trace and correlation identifiers.

6. Observability becomes part of the workflow contract

A modern implementation should expose workflow age, queue depth, stuck tasks, retry counts, external-system latency, failed commands, manual overrides, and SLA risk. OpenTelemetry traces and structured logs should connect the user action, workflow instance, order identifier, adapter call, event publication, and document lookup. Operators should see why a workflow is waiting, not just that it is waiting.

7. Cloud-native without making Kubernetes the objective

Container orchestration is useful when the operating model justifies it. I would run stateless services, workers, adapters, and gateways on Kubernetes or OpenShift where platform maturity exists, but I would keep the design portable. The business objective is reliable workflow modernization, not a topology diagram full of services.

The 2003-to-2026 Translation

What I Would Not Do

• I would not start by decomposing everything into microservices. A modular monolith or small set of services is often the better first move.
• I would not replace the database simply because it is old. Data migration risk needs a business reason.
• I would not put workflow state only in Kafka. Events distribute facts; they are not a substitute for explicit process state.
• I would not hide mainframe complexity behind a thin REST facade and call the result modern.
• I would not use AI to approve, override, or invent business outcomes without policy, evidence, and human accountability.

Where AI Belongs - And Where It Does Not

AI can help analysts summarize order history, draft exception explanations, find similar prior cases, classify document types, generate test scenarios, and explain why a workflow is blocked. It can also help engineers modernize the platform through code comprehension, regression-test generation, migration mapping, and operational runbook generation.

But AI should not become the authority of record. It should not fabricate transaction outcomes, bypass approvals, or decide entitlements without deterministic policy and human review. In this architecture, AI is a governed assistant sitting beside workflow, audit, and policy, not a replacement for them.

A Migration Path That Protects the Business

1. Document the current workflow states, actors, decisions, external effects, reports, and exception paths.
2. Put an adapter boundary in front of the mainframe and measure all current transaction patterns.
3. Move document access behind a metadata service while preserving existing document identifiers.
4. Rebuild one workflow slice end to end with dual-run reporting and explicit reconciliation.
5. Introduce orchestration for new work while old work drains or is migrated in controlled batches.
6. Extract services only when operational evidence shows independent scaling, deployment, or ownership value.

The migration should produce evidence at every stage: matching outcomes, bounded latency, clear retry behavior, audit completeness, operator readiness, and rollback plans. A modernization that cannot prove equivalence before it expands is asking the business to take faith as a dependency.

How I Would Test It

The test strategy must cover more than API happy paths. It should include workflow replay, failed adapter calls, duplicate callbacks, manager rejection, analyst reassignment, document-not-found conditions, timer escalation, queue backlogs, partial outage recovery, entitlement changes, and cross-system reconciliation.

I would also test migration behavior directly: old and new workflows running in parallel, historical order import, adapter contract compatibility, reporting parity, security policy enforcement, and operator runbooks. For this kind of platform, the architecture is only as credible as its failure testing.

The Enduring Idea

The old system matters because it solved a hard coordination problem with the tools available at the time. A modern rebuild should respect that problem. The answer is not React instead of JSP, Spring Boot instead of EJB, Kafka instead of JMS, or Kubernetes instead of an application server. Those may be useful choices, but they are not the architecture.