CRM/KYC — API Product Delivery & Agile Stabilization

Problem & why it mattered

A complex CRM/KYC integration lacked a testable delivery path—progress was hard to prove and rework risk threatened fixed-price commitments.

Context

• The Mission: Integrate a Microsoft Dynamics-based CRM/KYC product (Vendor) with legacy back-office logic via secure APIs.
• The Platform Shift: One of the first projects to adopt a newly introduced “API Factory” architecture (WSO2) for production-grade exposure of legacy systems.

What was broken / risky

• Non-testable decomposition: Early planning fixated on field mapping instead of data normalization + contract-first schemas, making quality and end-to-end validation hard.
• Architectural uncertainty: The new API Factory stack had limited production history; teams had to translate dense COBOL/DB2 structures into stable JSON contracts. This is the same discipline AI teams need for RAG/ML: clean inputs, stable contracts, and observable failures.
• Stakeholder pressure: Without a demonstrable “working path,” confidence and decision speed degraded across a multi-party engagement.

Workflow (before → after)

Shifting from field-level slicing to layer-based, testable functional delivery.

Approach & Decisions

I reframed the roadmap into testable slices, translated regulatory needs into usable stories, and set a delivery model the team could execute consistently.

What I did (key moves)

• Regulatory → delivery translation: Converted KYC/regulatory requirements into actionable user stories with clear acceptance criteria and API contract expectations.
• Re-architected the roadmap: Pivoted from a surface-level journey plan to a technical implementation strategy that de-risked the stack before scaling scope.
• Decomposed stories by layer: Created a three-layer story structure (COBOL, Java, WSO2) for each feature to enable vertical-slice testing.
• Data contracts & guardrails: Defined schema rules, validation checks, and failure modes to keep JSON outputs stable across layers.
• Thin-slice validation (“Email Pilot”): Focused the squad on moving one simple field through the full stack to establish a repeatable “working path” blueprint.
• Stakeholder visibility model: Reported progress via functional milestones and integration readiness (not raw field completion), improving decision quality.

Decisions / trade-offs

• Validate foundation before breadth: Prioritized proving the end-to-end path early—even if it meant delaying broader feature work in the first sprints.
• Technical path before full journey: Sequenced work based on integration feasibility and database complexity to avoid late-stage surprises.
• Right-sized story granularity: Kept stories meaningful enough to demo, yet small enough to test at each layer and reduce rework.

Delivery under Constraints

Legacy backend rigidity, a newly adopted middleware platform, and cross-timezone coordination required a strong delivery operating model.

Constraints (top 3)

• Legacy tech debt: Dense COBOL/DB2 structures (“copybooks”) increased mapping and ETL risk when translating to JSON contracts.
• Multi-party delivery risk: A fixed-price engagement across multiple organizations left little room for slip, misalignment, or rework.
• Global coordination: Aligning teams across London (CRM Vendor team), Switzerland (Bank), and Singapore (Implementation) across time zones.

How I reduced risk

• Cadence & quality gates: Introduced clearer DoR/DoD, acceptance criteria, and contract checks so stories didn’t “bounce” between layers.
• Governance across layers: Defined ownership, escalation paths, and acceptance criteria for COBOL → Java → WSO2 handoffs.
• Predictable forecasting: Shifted estimation from raw field counts to layer complexity, improving planning accuracy and communication.
• Hands-on unblock & alignment: Bridged BA intent ↔ engineering feasibility ↔ partner expectations to resolve trade-offs once, not repeatedly.

Impact

Stabilized delivery for a high-risk CRM/KYC integration and validated a reusable production approach for the bank’s API Factory stack.

What improved

• Rework: Estimated 25–30% reduction in rework once stories were sliced by layer with clearer acceptance criteria and contract checks.
• Predictability: Improved sprint planning accuracy by tracking progress via functional milestones and integration readiness (instead of “% fields done”).
• Stakeholder confidence: Faster decisions and fewer escalations after the “working path” (thin-slice) blueprint made progress demonstrable.
• Platform validation: Established patterns for using the API Factory stack in production-grade integrations.
• Data quality guardrails: Fewer contract breaks and clearer failure visibility via contract checks and layer-based validation.
• Estimation basis: Fewer story reopens/carry-overs and fewer defect-driven rework cycles after the layer-based slicing model was adopted.
• Operating model: Established a repeatable pattern (thin-slice → layer-based slicing → contract checks) for future API Factory integrations.

Next improvements (post-launch roadmap)

• Developer Experience (DX): Automate Swagger-to-Confluence documentation to streamline partner onboarding and reduce manual drift.
• Parallel mocking: Build a mocking framework so external partners can develop and test UI logic without waiting for the COBOL layer.

Learnings

Roadmaps must respect the tech stack; a user journey built on an unproven foundation becomes delivery risk.

Operating lessons

• Deep-tech roadmaps can be technical: Sequencing by architecture readiness is often the fastest path to real progress and stakeholder confidence.
• Testability beats throughput optics: Field-level progress is misleading unless a working end-to-end path exists.
• Stability reduces rework: Clear story slicing + quality gates (DoR/DoD, contracts, acceptance criteria) are how agile execution scales in regulated environments.
• AI parallel: Good RAG/ML starts here—normalized data, stable contracts, and observable failures.