BrokerLink does not expose raw application paths. Traffic lands through enterprise edge controls before route evaluation.
Architecture diagram library
Make the WHPS architecture impossible to hand-wave.
This is the front door for the WHPS diagram set: ServiceLink Portal, BrokerLink Portal, GroupLink Portal, Contact Center AI, ACA platform modernization, mainframe migration, EDE certification, AI SDLC controls, security, data movement, and service testing.
As-is legacy discovery
Current-state diagrams, interface inventory, system dependencies, batch/file flows, and operational constraints. These are evidence inputs, not the future-state story.
Inspect lane
Wipro Links / HPS current-state baseline
Evidence-backed view of the Wipro Links platform, HPS zone, PCI zone, ServiceLink, ExchangeLink, DataPower, MQFTE, PaySafe/Fiserv, and mainframe dependencies.
Review baseline
To-be WHPS Health Plan Platform
ServiceLink, BrokerLink, GroupLink, Contact Center AI, membership management, domain services, AI controls, data products, and zero-trust platform foundations.
Review target
Broker / Agent pathway architecture
MarketLink broker desktop, agency hierarchy, white-label consumer enrollment, CMS EDE services, security controls, and demo walkthrough.
Review pathway
BrokerLink security reference architecture
DNS, F5 VIP, reverse proxy, WAF, SSO/MFA, IAM/IDM, application security, protected data, EDE evidence, SecOps, and assurance controls.
Review posture
Transition and coexistence architecture
Strangler pattern, dependency removal, dual-run, file/batch parity, cutover controls, and decommission gates.
Inspect strategy
Diagram production roadmap
Legacy views still needed, to-be diagrams to build, and the evidence required before a diagram is marked presentation-ready.
Plan diagrams
Architecture lanes
Separate as-is legacy discovery, transition architecture, and to-be target architecture.
The legacy diagrams are valuable because they show dependencies, personas, integration patterns, data movement, and operating risk. The to-be environment is a separate design set that uses the legacy inventory as input and expresses the future state as cloud-native, AI-native, secure, observable, and evidence-governed.
| Lane | Purpose | Diagram examples | Decision it supports | Usage boundary |
|---|---|---|---|---|
| As-is legacy discovery | Capture what exists now: users, applications, interfaces, databases, files, jobs, vendor boundaries, and operational handoffs. | Current-state context map, application dependency map, interface catalog, batch/file flow, data-store map, security-zone map. | What must be protected, strangled, replaced, wrapped, retired, or investigated before migration. | Current-state and legacy discovery only; not the future-state architecture. |
| Transition and coexistence | Show how WHPS safely moves from legacy to target while business operations continue. | Facade/adapter view, dual-run flow, event replication, batch parity, cutover sequence, rollback path, decommission ledger. | How we reduce risk, prove parity, avoid outages, and retire dependencies in controlled waves. | Label with migration wave, source of record, rollback owner, and exit criteria. |
| To-be target architecture | Describe the cloud-native, AI-native platform we are building. | Target platform L1, membership domain architecture, API/event fabric, data platform, AI control plane, zero-trust security, operations/SRE view. | What the future operating model, product platform, technical control plane, and architecture standards are. | Use as executive, architecture, and delivery collateral once assumptions and open facts are clearly marked. |
| Control and evidence architecture | Connect policy, RACI, standards, release gates, audits, AI governance, and runbooks to both transition and target states. | Evidence control tower, release packet flow, EDE certification flow, AI SDLC control plane, incident/POA&M flow. | How WHPS proves architecture, security, delivery quality, regulatory readiness, and operational control. | Use when reviewers ask how the architecture is governed and proven. |
Legacy discovery still needed
Additional as-is diagrams complete the dependency translation into the to-be design.
The initial Word diagrams, the Wipro Links Platform Design and Architecture deck, and the AWS Mainframe Migration Assessment kickoff now give WHPS enough evidence to separate source facts from target implications. Each legacy diagram should produce a target-state implication, a migration risk, and a required evidence artifact.
| Legacy/current-state diagram needed | What it must capture | Why it matters for to-be | Target output it feeds |
|---|---|---|---|
| Application and capability inventory | All portals, service apps, batch platforms, reporting tools, payment/tokenization boundaries, document systems, fulfillment vendors, and operational consoles. | Prevents missing a business capability or hidden operational owner when defining target services. | Domain service catalog and product/platform ownership model. |
| Interface and protocol catalog | API, MQ/message, SFTP, EDI, database, scheduler, file, print, IVR, CRM, carrier, CMS/FFM, and vendor connections with direction, frequency, and owner. | Identifies what becomes API, event, file adapter, data product, or retired integration in the target. | API/event fabric, file adapter pattern, firewall and certificate matrix. |
| Data store and source-of-record map | Member, enrollment, policy, billing, payment, document, eligibility, commission, rating, reconciliation, reporting, and audit data sources. | Clarifies canonical ownership and lineage for membership management and analytics. | Canonical member model, data product catalog, lineage and retention architecture. |
| Batch, file, and reconciliation flow | Nightly, monthly, quarterly, end-of-month, renewal, audit-letter, print, GL, 834/820/999, mismatch, and control-total flows. | Protects the operational schedule while target events and workflows are introduced. | Dual-run plan, parity scorecard, scheduler modernization, decommission ledger. |
| Security, network, and certificate map | Zones, ingress/egress paths, WAF, SSO, MFA, service accounts, certificate trust chains, secrets, vendor access, and monitoring points. | Determines zero-trust boundaries and the target certificate, identity, and observability model. | To-be network/security control map and certificate rotation runbook. |
| Operations and incident flow | Support groups, alert routing, job failure handling, manual remediation, escalation paths, maintenance windows, audit response, and business fallback steps. | Ensures the target design includes runbooks, SLOs, on-call ownership, fail-closed behavior, and rollback paths. | Operations readiness architecture, SRE runbook matrix, incident response flow. |
Evidence-backed current state
Wipro Links and HPS are hybrid, integration-heavy, and payment/security-sensitive today.
The April 2026 Wipro Links architecture deck and April 10, 2026 AWS discovery kickoff confirm the current environment is not a single portal. It is a Wipro Links platform around HPS zones, portals, ESB messaging, DataPower APIs, MQ/MQFTE file exchange, PingFederate SSO, PaySafe/Fiserv tokenization, SQL stores, analytics, and a COBOL/JCL/DB2 ServiceLink core.
In-scope assessment
9.55M LOC
8.60M active LOC, 32,815 source members, about 10% obsolete.
Mainframe footprint
6,628 MIPS
15-20 apps, 10 z/OS DB environments, about 18 TB, 41K DB IOPS.
Runtime posture
168h OLTP
140h batch/week means batch, scheduler, and reconciliation are core risks.
Control zones
HPS + PCI
DataPower mTLS, SAML, PGP, RACF, PCI tokenization, and audit trails.
| Source-proven current fact | Target-state implication | Migration / evidence requirement |
|---|---|---|
| ExchangeLink uses ITX, HIPAA Pack, WAS, MQ, Broker/ACE, Java, COBOL, and DB2 for ESB-style asynchronous exchange and TA1/999 creation. | Target integration fabric must cover EDI validation, canonical transformation, async routing, replay, and carrier-specific business rules. | Interface catalog, EDI transaction samples, TA1/999 parity evidence, message replay tests, and carrier-rule owner signoff. |
| Wipro APIs use DataPower, MQ, ACE, Java, DB2, and Spring Boot with mTLS, header injection, protocol switching, and endpoint statistics. | API gateway and service mesh must replace current controls with equivalent or stronger identity, certificate, schema, and telemetry posture. | Endpoint inventory, client certificate matrix, schema registry, gateway logs, and traffic migration plan. |
| ServiceLink provides enrollment, premium billing, reconciliation, in-force administration, and customer service on COBOL/MF, JCL, DB2, Java, MQ, ACE, and Spring Boot. | ServiceLink modernization must be a domain migration across enrollment, billing, payments, reconciliation, service, and batch, not a front-end replacement. | Domain decomposition, source-of-record map, batch calendar, DB2 lineage, parity scorecard, and decommission ledger. |
| Portals use PHP/Zend/Apache/HTML/CSS/jQuery/React/PHP Slim with MySQL portal config/audit, MSSQL documents, and DB2 policy/financial data. | Future ServiceLink, BrokerLink, and GroupLink experiences should share a modern BFF, domain APIs, document service, audit model, and canonical member context. | Portal route inventory, session/role model, data contract map, document-store integration plan, and accessibility/security test evidence. |
| PaySafe is a PCI-DSS payment UI integrated to tokenization and Fiserv/Wells Fargo wallet services, with DataPower-secured submitPayment. | Target payment flow must be token-first and keep card/bank data out of product services, AI workflows, and general-purpose logs. | PCI boundary diagram, token vault contract, payment reconciliation report, log-redaction tests, and incident runbook. |
| Managed File Transfer uses MQFTE and PGP across FTP, SFTP, and WMQFTE, with transfer events consumed by EMC. | Target file platform needs auditable partner file exchange, encryption, transfer events, exception workflow, and retirement criteria for legacy file paths. | MFT inventory, PGP key register, partner SLA, file event telemetry, retry policy, and evidence of consumer-zero retirement. |
| AWS discovery quantifies 9.55M in-scope LOC, COBOL/JCL/COPYBOOK/DB2 artifacts, Control-M/IWS/RACF utilities, and 140 hours/week of batch uptime. | Modernization waves must include code, scheduler, security, database, control-card, stored-procedure, and operational readiness tracks. | Native source offload, scheduler config, SMF/runtime evidence, dependency graph, MRA findings, and weekly/steering decision logs. |
To-be architecture answer
Describe the future state as a cloud-native, AI-native health plan platform, not a portal rebuild.
The target architecture is the WHPS Health Plan Platform: ServiceLink Portal, BrokerLink Portal, GroupLink Portal, and Contact Center AI are experience products on a shared platform of identity, APIs, events, domain services, data products, AI controls, security controls, and migration facades.
| Architecture layer | Target-state description | Strategic answer | Evidence to maintain |
|---|---|---|---|
| Experience products | ServiceLink, BrokerLink, GroupLink, and Contact Center AI become independently releasable products on shared platform foundations. | We are not rebuilding four disconnected portals; we are building four product surfaces over common services. | Product roadmaps, workflow maps, release packets, UAT evidence. |
| Membership management | Membership becomes a governed domain platform for member profile, household, coverage, eligibility, policy enrollment, billing status, communication, and case history. | Membership is managed through governed domain APIs, events, controls, reconciliation, and system-of-record-aligned data. | Canonical member model, API contracts, event catalog, lineage and reconciliation reports. |
| Integration fabric | API gateway, BFF, service mesh, event backbone, workflow orchestration, file adapters, and coexistence facade replace point-to-point coupling. | All inbound, outbound, synchronous, asynchronous, and batch movement has an owned pattern and control boundary. | Endpoint catalog, event schema registry, firewall/certificate inventory, control totals. |
| AI-native control plane | Model gateway, retrieval, agent orchestration, guardrails, evals, prompt/tool registry, human approval, and evidence vault govern AI usage across delivery and operations. | AI is embedded as a governed operating layer, not a stand-alone chatbot or vendor-specific coding practice. | AI BOM, model selection record, retrieval source inventory, eval report, approval trace. |
| Data and evidence | Operational stores, lakehouse, lineage, reconciliation, retention, observability, SLOs, and audit evidence are designed into the platform. | Every critical transaction can be traced from user action to source, event, data product, release, and support evidence. | Data catalog, lineage map, SLO dashboards, audit samples, monthly evidence packets. |
| Migration bridge | Existing source systems are isolated behind facades, adapters, CDC, replay, dual-run, and decommission controls until the target domain is proven. | Legacy details are not the destination; they are controlled migration dependencies with retirement gates. | As-is dependency graph, parity scorecard, rollback proof, retired interface ledger. |
BrokerLink security architecture
BrokerLink security posture spans edge, identity, application, EDE, data, and SecOps assurance.
This is the executive one-page view for the broker platform security model. It shows the target control chain from DNS and F5 VIP through WAF, SSO/MFA, API controls, protected data, CMS EDE evidence, vulnerability management, pen testing, red teaming, and runtime monitoring.
Every broker, agent, agency admin, support user, and consumer action is bound to authenticated and auditable authority.
Application security evidence is generated before production movement and carried into release approval.
Runtime signals and independent validation feed remediation, POA&M, release gating, and control attestation.
| Security layer | BrokerLink control expectation | Technical implementation signals | Evidence for review |
|---|---|---|---|
| Perimeter and DNS | All public traffic passes through managed DNS, F5 VIP, reverse proxy, WAF, bot policy, TLS, HSTS, and CSP before application reachability. | DNS ownership, VIP configuration, reverse-proxy route policy, WAF rules, header policy, certificate chain, DDoS/CDN posture. | DNS record review, VIP export, WAF policy, TLS scan, certificate inventory, firewall change approval. |
| Identity and broker authority | SSO, IAM/IDM lifecycle, MFA, conditional access, RBAC/ABAC, NPN/AOR context, brokerId and agencyId scoping, support break-glass. | OIDC/SAML integration, group claim mapping, step-up MFA, session timeout, privileged access approval, no shared identities. | Access review, MFA report, IDM sample, broker role evidence, privileged session log, deprovision test. |
| Application and API security | Broker workspace, consumer portal, admin routes, CMS Hub calls, and evidence exports are separated by route, role, schema, and transaction boundary. | BFF, API gateway, CSRF, rate limits, input validation, mTLS, secrets manager/KMS, protected-data encryption, audit hash chain. | Threat model, API contract tests, SAST/DAST/SCA reports, secrets scan, dependency scan, release packet. |
| Operations assurance | Findings and runtime telemetry continuously feed remediation, POA&M, incident handling, and release decisions. | Cortex XDR/SIEM/SOAR telemetry, Tanium endpoint posture, Qualys vulnerability scans, pen test, red team, incident playbooks. | SIEM correlation, vulnerability report, endpoint posture, pen-test attestation, red-team findings, remediation closure. |
Membership management target
Membership management becomes the governed member operating layer.
The target architecture organizes billing, finance, broker, commissions, enrollment and policy maintenance, reconciliation, data warehouse, fulfillment, audit letters, and rating as cloud-native domain services and governed events.
| Membership capability | Target service / data product | Primary consumers | Key events and controls |
|---|---|---|---|
| Member identity and profile | Member Profile API, party/household model, identity-link table, consent and delegation store. | ServiceLink, Contact Center AI, CRM, secure inbox, reporting. | MemberProfileUpdated, consent audit, access review, duplicate-member exception queue. |
| Coverage, eligibility, and dependents | Coverage and Eligibility service with effective dates, plan selection, APTC/CSR, SEP/QLE, and dependent relationships. | ServiceLink, BrokerLink/EDE, GroupLink, contact center, notices, analytics. | CoverageChanged, EligibilityDetermined, retro-change review, CMS/EDE evidence trace. |
| Enrollment and policy maintenance | Enrollment Orchestration service for application intake, policy add/change/termination, quarterly windows, and downstream fulfillment. | BrokerLink, GroupLink, ServiceLink, CMS/FFM adapters, operations. | EnrollmentSubmitted, PolicyUpdated, TerminationRequested, idempotency key, workflow state audit. |
| Billing and premium ledger | Premium Billing service with invoice generation, adjustments, grace status, subsidies, recurring draft state, and account balance. | ServiceLink, finance, contact center, notices, reconciliation, financial reporting. | InvoiceGenerated, PaymentApplied, GraceStatusChanged, ledger control totals, finance reconciliation. |
| Payments and tokenization | Payment Orchestration service that stores only tokens/references and keeps PCI-sensitive processing outside the health-plan domain boundary. | ServiceLink, guest payments, billing, finance, customer service. | PaymentAuthorized, PaymentFailed, token lifecycle evidence, refund/return trace. |
| Broker, group, and commissions | Broker and Group Administration services for NPN/AOR, group census, renewals, commission eligibility, disbursement, and licensing evidence. | BrokerLink, GroupLink, finance, compliance, reporting. | AORChanged, GroupCensusUpdated, CommissionCalculated, license validation and exception tracking. |
| Documents, communications, and fulfillment | Notice and Document service with secure inbox, templates, citations, letter generation, outbound delivery, and print/vendor adapters. | All portals, contact center, compliance, fulfillment operations. | NoticeGenerated, DocumentDelivered, suppression rules, retention clock, proof of delivery. |
| Rating, renewal, audit, and reporting | Rating/Renewal service plus lakehouse data products for mismatch reports, audit letters, data quality, and operational analytics. | Product, actuarial/rating, operations, finance, audit, leadership dashboards. | RateApplied, RenewalPrepared, DataQualityException, lineage, report certification. |
Legacy context translation
Legacy diagrams are context inputs that must be translated into transition and to-be views.
The useful meeting takeaway from legacy diagrams is the capability map, dependency shape, operational timing, and risk surface. The to-be architecture replaces named legacy components and point-to-point paths with governed platform services, domain APIs, events, data products, and evidence controls.
| Legacy diagram signal | To-be architecture implication | Collateral created / updated | Do not carry forward |
|---|---|---|---|
| Multiple personas and portals: members, brokers, groups, customer service, carriers, CMS/FFM. | Position ServiceLink, BrokerLink, GroupLink, and Contact Center AI as product channels over shared identity, API, event, and domain services. | Target architecture answer, four-platform mega architecture, portal views. | Separate one-off portal stacks or duplicated portal-specific back ends. |
| Central authentication and authorization capability. | Adopt zero-trust access: SSO, MFA, consent/delegation, risk-based step-up, short-lived tokens, certificate-bound service identities. | Security/interconnect matrix and target architecture diagram. | Implicit network trust or user/password propagation as the architecture pattern. |
| API, service, and message mediation are central to the current ecosystem. | Create one integration fabric: API gateway, BFF, service mesh, event backbone, workflow orchestration, schema registry, DLQ, replay, and observability. | Target architecture, mega map, diagram catalog entries. | Unowned point-to-point connections, hidden transformations, and undocumented routing logic. |
| Payments and tokenization are separated from the health-plan zone. | Keep payment processing outside the PHI/domain boundary; store token references, audit events, and reconciliation results. | Membership target matrix and endpoint/security controls. | Cardholder data storage or payment logic embedded in member services. |
| Domains include billing, finance, broker, commissions, enrollment, reconciliation, data warehouse, fulfillment, audit letters, and rating. | Use these as the domain-service backlog and migration-wave taxonomy for the cloud-native platform. | Membership management target architecture and diagram answer library. | Technology-by-technology migration plans that ignore business capability ownership. |
| Reporting, reconciliation, documents, communications, file transfer, and batch are operationally critical. | Design data lineage, lakehouse products, document/notice services, file adapters, batch parity, and evidence packets into the target platform. | Data/evidence layer in target architecture and security/interconnect matrix. | End-of-project audit evidence collection or manual spreadsheet reconciliation as the control model. |
| ExchangeLink, EMC, MQ, Broker/ACE, HIPAA Pack, TA1/999, and carrier rules mediate enrollment and financial transactions. | Replace hidden integration logic with an explicit API/event/file pattern catalog, canonical schemas, retry semantics, exception ownership, and replay evidence. | Wipro Links current-state map, integration pattern catalog, migration wave intake, and interface dependency graph. | Undocumented ESB transformations, hard-coded carrier variations, or unobservable message handoffs. |
| DataPower, PingFederate SAML, MQFTE/PGP, RACF, Control-M/IWS, and PaySafe/Fiserv controls form the current security/compliance perimeter. | Target zero-trust architecture must map each control to equivalent or stronger cloud-native identity, certificate, file, scheduler, payment, audit, and incident controls. | Security-zone map, certificate register, PCI boundary diagram, scheduler modernization plan, and AI/contact center control packet. | Assuming cloud migration automatically preserves security posture, auditability, or PCI separation. |
| AWS discovery requires native source offload, scheduler configuration, JCL/control cards, DB2 DDL/stored procedures, BMS maps, runtime artifacts, and documentation. | Modernization waves start with evidence intake and dependency analysis before design; target diagrams must show which assumptions are source-proven versus proposed. | AWS discovery baseline, source artifact intake checklist, weekly status packet, steering decision log, and MRA gap register. | High-confidence target diagrams that are not traceable to source artifacts, runtime evidence, or business-owner validation. |
Diagram roadmap
The presentation library needs both more legacy discovery diagrams and a fuller to-be diagram set.
This is the working backlog for architecture collateral. A diagram is not complete until it has an owner, assumptions, source inputs, evidence links, and a clear label showing whether it is as-is, transition, to-be, or control/evidence.
| Diagram | Lane | Audience | Required inputs | Meeting answer |
|---|---|---|---|---|
| WHPS current-state ecosystem map | As-is legacy discovery | Architecture, operations, security | Wipro Links platform deck, AWS HPS discovery metrics, application inventory, zones, interfaces, source systems, vendors, support owners. | Here is what exists today and what the target must account for. |
| Wipro Links / HPS current-state platform map | As-is legacy discovery | Leadership, architecture, security, migration | ServiceLink, ExchangeLink, EMC, GetNext, DataLink, Communication Engine, DataPower, PingFederate, MQFTE/PGP, PaySafe/Fiserv, DB2/MSSQL/MySQL. | Here is the sourced current-state platform baseline we are modernizing away from. |
| Legacy interface dependency graph | As-is legacy discovery | Engineering, migration, QA | API/file/message/database connections, volumes, schedules, SLA, owners, error handling. | Here are the dependencies we must wrap, replace, retire, or validate. |
| AWS Transform discovery to WHPS wave factory | Transition and coexistence | Leadership, migration, architecture, finance | Source offload, code inventory, call graph, data graph, batch graph, MRA, candidate workload, wave scoring, parity gates. | Here is how discovery evidence becomes funded migration waves. |
| WHPS integration pattern catalog | Transition and to-be target | Engineering, security, operations, QA | API, event, MQ, file/SFTP, EDI, database, batch, print, payment, CRM, CMS/FFM, carrier dependencies. | Here is the approved pattern for every dependency type reviewers ask about. |
| To-be health plan platform L1 | To-be target architecture | Leadership, architecture, product | Product scope, domain service taxonomy, platform foundation decisions, AI control-plane assumptions. | Here is the future platform we are building. |
| To-be membership management domain | To-be target architecture | Product, data, engineering, operations | Canonical member model, source of record, coverage/billing/case/document requirements, privacy controls. | Here is how membership becomes an API, event, data, and evidence-backed domain. |
| To-be network, identity, certificate, and secrets map | To-be target architecture | Security, infrastructure, operations | DNS, environments, CIDRs, IdP, certificate authority, secrets/KMS model, ingress/egress policy. | Here is how the platform is protected and how trust is established. |
| Transition coexistence and strangler map | Transition and coexistence | Migration, operations, QA, business owners | Dependency graph, dual-run candidates, batch windows, rollback rules, cutover calendar. | Here is how we migrate without breaking the business. |
| To-be data, lineage, and reconciliation map | To-be target architecture | Data, compliance, analytics, finance | Source systems, target data products, lineage, retention, control totals, audit samples. | Here is how data remains traceable, reconcilable, and usable. |
| To-be AI-native operating control plane | Control and evidence architecture | Engineering, security, compliance, leadership | AI inventory, model/tool policies, retrieval sources, eval gates, release packet, monitoring requirements. | Here is how AI is governed across delivery and operations. |
| Presentation-ready diagram register | Control and evidence architecture | Leadership, consultants, architecture board | Owner, freshness date, evidence source, assumption status, approval state, target meeting use, and open validation gaps. | Here is which diagram is safe to use in which meeting and what still needs validation. |
Overall big diagram
One over-detailed target-state map with platform, AI factory, network, security, data, and migration layers.
This view intentionally carries more detail than a steering-slide diagram. It names the four primary platforms, the model-agnostic AI SDLC factory, security and certificate controls, integration protocols, evidence stores, and the coexistence path back into COBOL, CICS, DB2, VSAM, JCL, EDI, print, and GL.
Security and interconnect detail
Ports, protocols, certificate posture, and controls for the primary platform paths.
These are target architecture patterns for review and planning. Exact environment DNS, CIDRs, and firewall rules should be finalized during implementation, but this gives the diagram the technical density reviewers expect.
| Path | Target endpoint pattern | Protocol and port | Identity / certificate control | Security and evidence |
|---|---|---|---|---|
| ServiceLink Portal to edge | ServiceLink portal edge route | HTTPS 443, HTTP/2, TLS 1.3 | Public CA or enterprise CA, HSTS, OIDC session, MFA step-up for PHI/payment workflows | WAF, bot rules, CSP, consent log, secure inbox audit, payment tokenization evidence |
| BrokerLink Portal and CMS EDE | BrokerLink portal route, EDE adapter route | HTTPS 443, mTLS for partner adapters, SFTP 22 for controlled files | Broker SSO, NPN/RCL validation, delegated AOR access, client cert pinning for EDE adapters | RIDP/Experian trace, EDE transaction log, PIA, SSPP/MARS-E package, BRA/FFM parity evidence |
| GroupLink Portal to core services | GroupLink portal route, group administration API route | HTTPS 443, private service mesh mTLS 8443 | Group admin RBAC, delegated employer roles, short-lived service tokens | Access review, census change audit, billing inquiry trace, support runbook acceptance |
| Contact Center AI to CRM and retrieval | Contact Center AI route, retrieval service route | HTTPS 443, WebSocket 443 for transcript stream, private gRPC/mTLS 8443 | Agent desktop SSO, scoped tool identity, model gateway policy token, certificate rotation | Transcript, citations, tool-call log, agent approval, CRM disposition, QA score, knowledge backlog item |
| AI SDLC factory to engineering systems | AI SDLC factory route, evidence store route | HTTPS 443, SSH 22 where approved, OCI registry 443, webhook 443 | Scoped agent identity, time-bound credentials, signed artifacts, KMS/HSM-backed secrets | AI inventory, AI BOM, prompt/model/tool registry, SAST/DAST, eval report, approval record, rollback plan |
| Mainframe facade and data movement | Core facade route, mainframe adapter route | HTTPS/mTLS 8443, MQ 1414, JDBC/DB2 446, SFTP 22, scheduler callbacks 443 | Service account per adapter, cert-bound credentials, least-privilege DB2 packages | Copybook map, CICS trace, DB2 lineage, batch control totals, parity scorecard, decommission ledger |
Primary architecture map
Target-state platform architecture.
This is the architecture directory for the platform build. Use the canvas for the interactive system view and the workstream architecture packs for controls, requirements, interfaces, and operating context.
Target-state architecture board
ACA digital platform, modernization facade, business services, data products, and mainframe estate.
5 channel groups
11 service domains
COBOL / CICS / VSAM / DB2 / JCL
Diagram set
Use the right diagram for the conversation.
These are the diagrams that should be used in steering discussions, architecture reviews, engineering walkthroughs, and product planning sessions.
As-Is, Transition, and To-Be Architecture Lanes
Separates legacy discovery from coexistence planning and future-state architecture so meeting collateral is never ambiguous.
- Current-state diagrams are evidence and dependency discovery inputs
- Transition diagrams carry dual-run, rollback, and retirement gates
- To-be diagrams describe the platform WHPS is building
Current-State Diagram Backlog
Defines the additional legacy diagrams needed before every current dependency can be translated into the to-be environment.
- Application inventory, interface catalog, data-store map
- Batch/file/reconciliation flow, security-zone map, operations flow
- Each legacy diagram produces target implications and migration risks
To-Be Diagram Production Roadmap
Prioritizes the target-state diagrams needed for presentations, architecture review, security review, delivery planning, and operations.
- Health plan platform, membership domain, API/event fabric
- Network/security, data/lineage, AI control plane, SRE operations
- Each diagram needs owner, assumptions, inputs, and evidence links
Cloud-Native, AI-Native Health Plan Platform
Defines the meeting answer for the future state: four experience products, shared zero-trust access, domain services, events, AI controls, data evidence, and migration bridge.
- ServiceLink, BrokerLink, GroupLink, and Contact Center AI as product channels
- Membership, enrollment, billing, payments, documents, communications, and data services
- AI-native control plane and source-system coexistence bridge
Membership Management Target Architecture
Turns the legacy diagrams' domain signals into a target-state membership operating layer with APIs, events, lineage, and reconciliation.
- Member profile, household, coverage, eligibility, enrollment, billing, and cases
- Tokenized payments, broker/group links, documents, notices, and audit letters
- Domain events, data products, control totals, and exception queues
ACA Platform Modernization Architecture
Shows the target architecture across channels, integration, ACA services, data products, controls, and the mainframe estate.
- Enrollment and billing flows
- Communications engine placement
- COBOL, CICS, VSAM, DB2, JCL, EDI, print, and GL boundaries
Mainframe Migration and Strangler Architecture
Shows how dependencies are isolated, migrated by domain, validated through dual-run, and cut over safely.
- Core facade and adapter boundaries
- Batch, file, and transaction decomposition
- Cutover, rollback, and decommission controls
Agentic Delivery and AI SDLC Architecture
Shows how AI-assisted delivery is governed through scoped agents, policy checks, evaluations, CI, evidence, and release gates.
- Agent orchestration and permissions
- Human approval and security gates
- Evidence and telemetry feedback loops
Contact Center AI Operating Architecture
Shows caller context, CRM, retrieval, citations, guardrails, agent approval, QA scoring, and service improvement feedback.
- Human approval before customer-facing answers
- Policy and citation controls
- QA loop and knowledge backlog
Customer Call and Service Test Architecture
Shows how service tests validate caller identity, AI assist, CRM staging, QA capture, approval, and failure handling.
- Call path and agent assist boundary
- CRM writeback and test evidence
- Fail-closed controls and escalation
ServiceLink, BrokerLink, GroupLink, and EDE Platform Views
Shows portal-facing capabilities, API boundaries, identity, enrollment, documents, billing, and service flows.
- ServiceLink member service, BrokerLink enrollment, and GroupLink administration workflows
- CMS EDE / FFM integration
- ServiceLink billing, coverage, and communication views
RACI, Governance, and Artifact Response Views
Shows how the target governance bodies, RACI matrix, approved tools, standards, ADRs, EDE evidence, runbooks, and monthly packets connect.
- AI Governance Council, AI Review Board, architecture/security/QA/CAB forums
- Reviewer question-to-artifact routing
- Release evidence, risk register, POA&M, and value ledger trace
Where each diagram lives
Diagram index.
This table is the quick lookup when someone asks for a specific architecture view.
| Diagram | Use it for | Location |
|---|---|---|
| As-is, transition, and to-be architecture lanesHow to classify every architecture artifact | Explains which diagrams are legacy/current-state context, which support migration/coexistence, and which represent the future-state platform. | Review architecture lanes |
| Legacy discovery backlogCurrent-state diagrams still needed | Application inventory, interface/protocol catalog, data-store map, batch/file flow, security-zone map, and operations flow needed for accurate to-be design. | Inspect legacy discovery |
| To-be diagram production roadmapFuture-state collateral backlog | Target platform, membership domain, network/security, data lineage, AI control plane, SRE operations, EDE, and migration/coexistence views. | Review diagram roadmap |
| Cloud-native, AI-native to-be architecturePrimary future-state answer | Executive and architecture answer for ServiceLink, BrokerLink, GroupLink, Contact Center AI, membership management, domain services, AI controls, data, and migration bridge. | Review to-be architecture answer |
| BrokerLink security reference architectureEnterprise broker platform posture | DNS, F5 VIP, reverse proxy, WAF, IAM/IDM, SSO/MFA, route controls, protected data, EDE evidence, SAST/DAST, Qualys, Cortex, Tanium, pen tests, and red-team validation. | Review security posture |
| Membership management target architectureSource-backed member operating layer | Membership, coverage, eligibility, enrollment, billing, payments, documents, communications, broker/group relationships, cases, lineage, and reconciliation. | Inspect membership target |
| Legacy capability translationHow as-is diagrams inform transition and to-be views without preserving the old stack | Maps legacy diagram signals to target-state platform services, domain APIs, event contracts, AI controls, and evidence requirements. | Review legacy translation |
| ACA platform modernization architecturePrimary end-to-end target architecture | Overall ACA platform strategy, service decomposition, integration, data, controls, and mainframe dependencies. | Explore ACA canvas |
| Quote to enrollment flowEnrollment path from BrokerLink/ServiceLink to policy creation | BrokerLink portal, ServiceLink intake, eligibility/subsidy, enrollment orchestration, binder payment, and exchange files. | Trace enrollment flow |
| Premium billing flowInvoice, payment, subsidy, reconciliation, and GL | Billing, payment processing, remittance, delinquency, grace period, data quality, and financial reconciliation. | Trace billing flow |
| Nightly batch and reconciliationMainframe file and batch operating model | JCL, VSAM, DB2, EDI, print/mail, GL feeds, extracts, control totals, and batch evidence. | Trace batch flow |
| Mainframe migration strategyStrangler, dual-run, cutover, and decommission | Migration wave planning, dependency removal, service facade strategy, data extraction, rollback, and operational readiness. | Inspect migration strategy |
| AI SDLC workflowAgentic software delivery control architecture | Engineering governance, scoped agents, policy checks, tests, evaluations, evidence, and release controls. | Review AI SDLC diagrams |
| Contact Center AI architectureAgent assist and service operations | Retrieval, citations, guardrails, agent approval, CRM writeback, QA scoring, and knowledge feedback. | Inspect service architecture |
| Service test harnessOmnichannel service validation | Test scenarios, expected outcomes, AI assist boundary, CRM evidence, QA result, and release readiness. | View service-test evidence |
Reference standards
External anchors for the target architecture.
These sources are used as architecture guidance anchors, while the WHPS framework remains tool-agnostic and cloud-provider portable.