Modernisation proposal for review; durations are indicative.
Proposed Agent and Human Team for CardDemo Modernisation
In this document
This is an unapproved planning proposal. It defines possible roles for the delivery slices, not deployed agents, committed staffing, approval authority, or permission to execute changes. Role assignment, capacity, access, segregation of duties, and accountable owners remain to be confirmed.
Agents may accelerate evidence collection, comparison, test generation, implementation support, and repeatable analysis. They must not determine business authority, approve semantic differences, handle unrestricted sensitive data, authorize releases, or make production changes. Human owners retain all decisions concerning scope, business meaning, security, financial outcomes, data authority, operational acceptance, cutover, recovery, and retirement.
Operating model
Each task should use a small delivery group and an independent reviewer who did not produce the result under review. One person may hold more than one proposed role only after segregation-of-duties and capacity review. Scarce specialists should be engaged at defined decision points rather than assumed continuously available.
Agent work must be bounded by an approved task statement, named evidence set, permitted environment, allowed tools, data-handling rules, expected outputs, and stop conditions. Agent outputs are proposals or review material until accepted by an accountable human. Confidence labels must distinguish observation, inference, contradiction, missing evidence, and unresolved decision.
No agent should receive production write access by default. Access to credentials, passwords, card-security values, customer information, financial records, MQ messages, logs, dumps, or extracts requires human-approved minimization and masking. Agents must not copy legacy passwords, expose sensitive payloads in telemetry, resolve contradictory records by majority vote, or infer that inventory coverage proves semantic completeness.
Core coordination roles
Human modernisation lead
The proposed modernisation lead maintains slice boundaries, dependencies, decision points, and re-estimation. This role coordinates but does not replace business, security, data, operational, or release authority. It records when work is blocked by missing evidence and prevents unresolved assumptions from silently becoming architecture decisions.
An independent programme assurance reviewer checks that the plan remains incremental, reversible, evidence-backed, and free of unsupported claims about benefits, production suitability, staffing, cost, or completion.
Human business-behaviour owner
The proposed business-behaviour owner approves which observed outcomes are material within each selected scope. Responsibilities include messages, validation, routing, paging, sorting, state transitions, rejection distinctions, and customer continuity. Different domains may require different owners; a single enterprise-wide owner must not be presumed.
A business-rule review agent may assemble candidate rules and contradictions from approved material. It must not select a preferred rule or declare undocumented behaviour obsolete.
Human evidence and configuration custodian
The proposed custodian controls access to source, deployed artifacts, catalogs, scheduler definitions, logs, configurations, and test results. This role distinguishes deployed, optional, generated, historical, and obsolete material with input from accountable owners.
An inventory-analysis agent may correlate names and dependencies, identify gaps, and draft test candidates. It must preserve conflicting names and representations rather than normalizing them.
Human data authority and migration lead
The proposed data lead coordinates decisions about authoritative, derived, replicated, synchronized, independently maintained, historical, and obsolete representations. Data stewards and domain owners retain authority for meanings, keys, correction rules, retention, and acceptable differences.
A data-reconciliation agent may compare layouts, encodings, keys, counts, distributions, sequences, balances, and referential relationships. Matching counts or successful processing must never be reported as semantic equivalence.
Human security and privacy authority
The proposed security authority decides identity, authorization, least privilege, sensitive-data handling, audit, encryption, secrets, privileged access, and segregation of duties. It also determines whether representative data and telemetry are suitably protected.
A security-test agent may check approved policies, authorization matrices, masking, audit events, and deployment configuration. It must not determine acceptable risk or approve credential migration.
Human operations and recovery owner
The proposed operations owner defines supportability, monitoring, alert handling, restart, rerun, backup, restore, rollback, and forward-recovery expectations. Availability, performance, retention, recovery time, and recovery point objectives remain decisions until owners supply them.
An operations-analysis agent may model dependencies, generate failure scenarios, correlate events, and compare recovery results. It must not initiate destructive maintenance, production failover, queue replay, restoration, or cutover.
Human release and change authority
The proposed release authority evaluates evidence for deployment, coexistence, traffic progression, rollback, and retirement. It remains independent of implementation and is not created merely by assigning this role in the plan.
A release-verification agent may assess approved checklists and evidence for missing tests, unexplained differences, or rollback gaps. It cannot authorize promotion or retirement.
Team for “Establish the Deployed and Measurable Baseline”
A baseline analyst agent should collect approved artifact inventories, compare representations, retain contradictions, draft dependency views, and propose characterization tests. A measurement-design agent should draft candidate indicators with possible sources, sampling periods, exclusions, and review cadence. Neither agent may decide production relevance, ownership, targets, or whether a result is acceptable.
The human task group should include the evidence custodian, relevant business-rule owners, mainframe specialists, data stewards, security representatives, operations staff, and interface owners. Their bounded responsibility is to identify active environments and releases, classify artifacts, grant controlled access, approve expected observations, and assign proposed ownership.
An independent characterization reviewer should repeat selected observations and verify that outcomes are classified as passed, failed, blocked by missing evidence, not executable, or not applicable. A separate measurement reviewer should reject indicators lacking an owner, source, method, sampling period, exclusions, or review cadence. Baselines and targets must not be invented.
This slice has no prerequisite, but access, representative data, shared environments, supplier responses, and governance reviews may cause waiting. Its stated low, central, and high elapsed scenarios are 20, 45, and 90 working days; these are not agent runtimes or staffing commitments.
Team for “Resolve Data Authority and Rehearse Migration”
A layout-comparison agent should identify discrepancies in record lengths, framing, keys, encoding, dates, signs, precision, status values, indexes, and access paths. A migration-rehearsal agent may prepare repeatable non-production extraction, transfer, transformation, loading, rejection, restart, cleanup, rerun, and reconciliation tasks within an approved sandbox.
Human data and application owners must decide authority and meaning. Security, privacy, records, and operational reviewers must approve handling, retention, correction, recovery, and migration acceptance. The unexplained IMS child-layout and unload-allocation discrepancy must remain blocked for affected records until evidence resolves it.
An independent migration verifier should reproduce controlled counts and applicable referential, uniqueness, sequence, status-distribution, balance, and financial checks. It should specifically challenge any conclusion based only on matching counts or tool completion.
This work depends on “Establish the Deployed and Measurable Baseline.” Its elapsed scenarios are 20, 50, and 110 working days, with possible indefinite waiting for inaccessible representations or unresolved framing.
Team for “Deliver the Read-Only Servicing Path”
A servicing-path agent may help implement and test bounded account or card inquiry adapters, presentation paths, field comparisons, protected telemetry, and reversible routing. A contract-test agent should exercise confirmed lookup, identity and role routing, not-found distinctions, filtering, sorting, paging, masking, formatting, messages, and unavailable-option behaviour.
Human business and data owners must select the inquiry scope and approve keys, meanings, comparison rules, and presentation behaviour. Security, accessibility, platform, operations, and release reviewers must decide applicable controls and support procedures. Azure service selection should follow confirmed runtime, contract, scale, residency, identity, recovery, and support requirements rather than legacy product names.
An independent servicing reviewer should focus on conflicting card keys, omitted account-key components, page sizes, attention-key meanings, map and transfer differences, snapshots, and presentation-to-storage mappings. A separate rollback witness should observe routing back to the legacy path without relying solely on the implementation team’s report.
This slice depends on the baseline and data-authority slices. Its elapsed scenarios are 25, 55, and 105 working days. Hybrid connectivity, identity, firewall, representative-data, integration-environment, accessibility, and release-governance waiting must be tracked separately from agent runtime and human effort.
Team for “Modernize Workforce Identity and User Administration”
An identity-correlation agent may propose account matches and unresolved identities. An authorization-test agent may execute an approved role matrix, routing checks, policy tests, audit validation, and identity-provider failure simulations. These agents must not decide identity authority, segregation of duties, lockout, session standards, deletion policy, or credential handling.
Human business and security authorities must decide the identity population, legacy-record authority, user-type meaning, role model, privileged and break-glass access, federation or reset approach, and audit obligations. Operations must accept failure and recovery procedures. Legacy passwords must not be copied unless safe, supported handling is demonstrated and explicitly accepted.
An independent access-control reviewer should test least privilege and separation between Azure platform roles and application business authorization. A rollback reviewer should verify that fallback cannot lock authorized users out of both paths.
This slice depends on the baseline and read-only servicing path. Its elapsed scenarios are 20, 45, and 90 working days, with identity governance, tenant integration, network access, matching, and security review treated as waiting dependencies.
Team for “Establish Reference Data and Servicing Updates”
A reference-distribution agent may implement approved versioning, propagation, lag detection, and reconciliation. A concurrency-test agent may exercise unchanged values, stale reads, simultaneous updates, deadlocks, retries, uniqueness, compound keys, expiry and status validation, dependent deletion, and propagation failure.
Human domain owners must decide transaction-type and category authority, synchronization direction, card identity, compound keys, update scope, lock and retry policy, and acceptable compensation. Security reviewers decide handling of CVV-like and personal data. No agent may presume that a possible card-security overwrite is a confirmed defect.
An independent transaction reviewer should verify exact agreed state transitions and the intended account-and-customer rollback. A data-control reviewer should ensure that coexistence has one declared authority and no ungoverned dual writes.
This slice depends on data authority, read-only servicing, and workforce identity. Its elapsed scenarios are 30, 65, and 130 working days. Unknown consumers or unresolved authority are stop conditions, not implementation details.
Team for “Cut Over Payments and Transaction Outcomes”
A financial-characterization agent may execute approved boundary, duplicate, concurrency, restart, rerun, and failure-injection cases. A reconciliation agent may compare transaction creation, rejected outcomes, balance adjustments, states, acknowledgements, and external effects. Agents must never approve financial calculations, tolerances, corrective entries, or replay safety.
Human business and finance-rule owners must approve balances, calculations, identifiers, states, rejection reasons, reversals, refunds, fees, interest, limits, and reconciliation criteria. Data, security, risk, and operations reviewers must accept atomicity, idempotency, recovery, and cutover controls.
An independent financial-effects reviewer should verify that rejected work is not counted as successful, duplicate tests create no duplicate real effect, and no external effect is unaccounted for. A recovery witness should independently observe the rehearsed stop, rollback, or forward-recovery procedure. Automatic rollback must not be approved where an unaccounted target effect may exist.
This slice depends on data authority and servicing updates. Its elapsed scenarios are 35, 80, and 170 working days. Unexplained authoritative financial differences block progression.
Team for “Migrate Authorization, Fraud, Batch, Reporting, and Recovery”
A messaging-analysis agent may trace approved correlation identifiers, ordering, responses, persistence, retries, expiry, and acknowledgement paths. A fraud-analysis agent should remain separately scoped and must not merge fraud and authorization lifecycles without evidence. A batch-dependency agent may reconstruct workflows from observed dependencies rather than job names. Report and recovery agents may compare outputs, inject approved failures, and test restoration in controlled environments.
Human messaging, fraud, business, data, records, security, operations, recovery, reporting, and external-interface owners must decide schemas, response timing, lifecycle rules, batch outcomes, report meanings, retention, and recovery obligations. Each cutover and any retirement require separate human authorization.
Independent reviewers should separately assess messaging, fraud, batch restartability, report and statement reconciliation, restoration, and external effects. Testing should cover failure before and after receipt, evaluation, persistence, publication, acknowledgement, timeout, retry, expiry, destructive file operations, posting, and index rebuilding. A retirement reviewer must confirm that unknown consumers, discrepancies, recovery gaps, retention duties, and fallback dependence have been resolved before any retirement proposal advances.
This slice depends on the baseline, data authority, and payment outcomes. Its elapsed scenarios are 45, 110, and 240 working days. Queue access, scheduler evidence, suppliers, batch windows, report cycles, restore environments, business calendars, and change freezes may dominate waiting time.
Review, capacity, and re-estimation controls
Agent runtime should be measured separately from human analysis, review effort, waiting time, and elapsed working days. Parallel agent execution does not remove serial human decisions, scarce specialist reviews, shared-environment contention, extract windows, or release governance. No number of agent tasks implies a staffing level.
The likely critical path runs through the deployed baseline, data authority, servicing updates, payment outcomes, and the final authorization, fraud, batch, reporting, and recovery slice. The read-only path and workforce identity add prerequisites for servicing updates. Actual sequencing must be revised when evidence exposes tighter coupling or blocked authority decisions.
After the first accepted end-to-end slice, the modernisation lead should compare observed agent runtime, human review demand, waiting causes, defect discovery, reruns, and environment contention with the low, central, and high scenarios. Estimates and role capacity should then be revised. Re-estimation is also required after material contradictions, failed rehearsals, new consumers, unsafe replay, unresolved sensitive-data handling, or recovery defects are found.
No benefit should be claimed until an accepted measurement has a baseline, proposed target, accountable owner, source, method, sampling period, exclusions, and review cadence. Targets, service levels, staffing, cost, outage allowance, production suitability, cutover approval, and retirement authority remain undecided.
Harten analysis of AWS Samples CardDemo, a public demonstration application. The retained source content matches AWS revision 59cc6c2fd7ebd7ef7925cad552a01a4b8b6e4d5e. The documents describe source analysis and a proposed modernisation plan, not an implemented migration. No AWS endorsement is implied.
Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. Apache 2.0 source licence · Amazon notice. Read the case study and source measurement.