The Numbers
The Customer
A financial technology services company specializing in cash-in-transit and physical currency management. Their platform handles the operational core of the business: route management, vault reconciliation, cash counts, and compliance reporting — all built on a foundation of legacy code that has been running for years.
Like many companies in this space, the software works. But it is increasingly difficult to understand, document, and extend. The original developers are gone. The business logic is buried in code that no one can fully read. And every new feature request requires reverse-engineering what the system already does.
They knew modernization was necessary. What they didn't know was how to start.
The Moment That Closed the Deal
Frank Welder, IBM Domain Architect at Arrow ECS, ran the proof-of-concept. The goal was to show IBM Bob's capabilities against a legacy modernization scenario — but Frank didn't use generic sample code. He used his deep knowledge of the cash-in-transit industry to have Bob generate code and business logic that closely mirrored the kinds of systems this customer would actually run.
"When Bill saw their data objects and entities in the POC — you had just set the hook."
— Michael Pompey, IBM AI Evangelist, Arrow ElectronicsBob generated a plain-English function inventory on the spot: a human-readable description of what each module does, written in language a business stakeholder — not just a developer — could understand. The output was so accurate to the customer's real-world domain that the customer initially believed Frank had obtained unauthorized access to their actual codebase.
He had not. Bob had reconstructed the shape of their system from domain knowledge and the patterns inherent in cash-logistics software. That moment — the recognition that IBM Bob understands their world without needing to be handed their code — is what drove the decision to sign.
The Business Problem
The customer's legacy platform is built on code that is difficult to read and harder to maintain. Key challenges included:
- No function inventory. No one could answer "what does this module actually do?" without reading thousands of lines of source code.
- No documentation. Business logic, edge cases, and operational rules existed only in the code — not in any document a business stakeholder could read.
- Developer onboarding was painful. New engineers required months to become productive because there was no structured way to understand the system.
- Modernization had no starting point. Without knowing what the system did, there was no safe way to plan a migration or phased modernization roadmap.
The goal of the engagement was not to rewrite everything. It was to make the existing system legible — and then chart a realistic path forward.
The Engagement
Arrow Services delivered a Direct-to-L4 Engineering engagement — a named IBM L4 resource working directly with the customer's team, starting with one week on-site to kick off the project and transitioning to remote delivery for the duration.
| Engagement Type | IBM BOB Direct-to-L4 Engineering |
| Model | Time and materials, best-effort · 100 hours fixed fee |
| Duration | August 17 – September 11, 2026 |
| On-site | Week 1 on location + final 8 hours for findings close-out |
| Response SLA | 1 business day acknowledgement and scheduling |
| Engagement value | $25,000 |
What Gets Delivered
How the Deal Came Together
IBM Bob POC Demonstration
Frank Welder ran a live demonstration using IBM Bob against a cash-logistics domain scenario. Bob generated code, business logic, and a plain-English function inventory that so closely matched the customer's actual systems they questioned whether their codebase had been accessed.
SOW Scoped and Sent
Arrow's Services Business Development team worked with the customer to scope a time-and-materials Direct-to-L4 work order. Multiple revisions over a week to align on CTM-specific requirements, then sent for execution.
SOW Executed — PO Issued
Customer returned a fully executed copy of the SOW with a purchase order. Arrow Services confirmed start date and delivery team. Onboarding began without a formal kickoff call — per the engagement model, Arrow confirmed contacts and logistics by email.
Arrow's First IBM Bob Services Win
The Arrow field team celebrated the close. Gerry Modzelewski, Field Sales Manager, called it Arrow's first of what he believes will be many IBM Bob services contracts — driven entirely by the technical credibility Bob established in the demonstration.
Arrow's first IBM Bob services contract. This engagement is more than one deal — it's the proof point that IBM Bob can anchor Arrow Services engagements. From a standing demo, through a live POC, to a signed $25,000 work order in days. The path to repeating this is clear.
Outcomes
Why This Matters for Arrow
IBM Bob is not just a tool for Arrow engineers. It is a sales asset. When a customer sees Bob reason about their domain — without being handed their source code — the conversation changes. It stops being a demo and becomes a business discussion.
This engagement is the first proof that Arrow can take IBM Bob from a capability demonstration to a billable services contract. The pattern is repeatable: identify a customer with legacy modernization debt, run a domain-accurate POC with Bob, and let the output speak for itself.
The customer signed not because Arrow gave a good presentation. They signed because Bob showed them something they had never seen before: their own system, made legible.