Mastodawn

# How Consumer Electronics Innovation Solves Legacy System Integration in Finance Hardware

A finance hardware SME with fifty-three employees manufactures point-of-sale terminals and card readers for retail banks and credit unions. The company has been around for fourteen years. Its product development organization has twenty-nine people working on a new EMV-compliant payment terminal. The team runs XP as one large group of sixteen to fifty. (1/26)

Legacy system integration is destroying this team. The new terminal must communicate with a transaction processing system that is eighteen years old. That system runs on COBOL. Nobody on the team knows COBOL. They cannot read the code, so they do not understand how the legacy system works. That means the integration they build fails. Transactions do not process. Payment terminals crash. (2/26)

When terminals crash, credit unions cannot accept payments. They call support. The company loses money. Last quarter alone, failed integration wasted twelve hundred hours of developer time. The team burned through its budget and ran out of money. The launch was delayed by five months. Three credit union clients left. The company lost $486,000, which was 82% of the quarterly revenue target for the new terminal.

The team needs a better approach.

## The Lesson from Akio Morita (3/26)

Akio Morita built Sony on a simple insight. He noticed that the electronics industry had a tendency to build products compatible with everything. The result was generic, mediocre products that did not sell. That tendency killed companies.

Morita attacked it directly. His principle was straightforward: build your own ecosystem. When your products work together, the experience is better. When the experience is better, customers buy. (4/26)

He created proprietary formats. Sony products worked with Sony products. The experience was seamless. When Morita launched the Walkman, he did not try to make it work with every headphone brand. He built Sony headphones. The Walkman worked perfectly with Sony headphones. It sold sixty million units.

Morita did not try to be compatible with everything. He built his own ecosystem. That is what made Sony.

## Applying This to Legacy System Integration (5/26)

The twenty-nine-person team has the opposite problem. It is trying to make a new EMV terminal directly compatible with an eighteen-year-old COBOL system. The team spends all its time trying to understand code it cannot read. Integration fails. The company loses $486,000. (6/26)

Morita's principle applied here is simple: build your own integration layer. When you have a clean interface between the new product and the legacy system, the integration works. When the integration works, customers get a product that actually functions.

## The Core Principle (7/26)

Stop trying to make the new terminal directly compatible with a COBOL system nobody understands. That approach wasted twelve hundred hours, delayed the launch five months, cost three clients, and lost $486,000. Instead, build a clean integration layer the way Morita built the Betamax format. Sony video players worked with Sony tapes. Playback quality was perfect. (8/26)

Morita did not build Sony by chasing universal compatibility. He built proprietary formats so his products worked together seamlessly. The same logic applies. Build an integration layer. The new product communicates with the legacy system through a clean interface. The integration works. Customers get a working product. The company stops bleeding money.

## Four Steps to Make This Happen

### Step 1: Create an Integration Layer Design This Week (9/26)

Morita built his own ecosystem through proprietary formats. You should build yours by creating an integration layer design this week. Define a clean API between the new EMV terminal and the legacy COBOL system. The team should never need to touch COBOL code. (10/26)

The XP coach creates a document with three sections. Section one describes the problem: the new terminal must communicate with the legacy system. Section two describes the solution: a middleware component that sits between the two systems. It translates modern JSON requests into COBOL-compatible flat files and translates COBOL responses back into JSON (11/26)

. Section three defines the API contract with six endpoints: submit transaction, void transaction, refund transaction, batch close, status check, and reconciliation.

Last quarter, creating this design took four hours. It saved the company $112,000 by preventing a failed direct integration. The team no longer needs to understand COBOL. It uses modern skills to build the middleware. (12/26)

For an XP team of sixteen to fifty, create this design this week. It should define a clean API that sits between the new product and the legacy system. Make it part of the team's legacy integration work.

### Step 2: Build the Middleware MVP in Two Weeks

Morita made his products work together. You should do the same by building the middleware as an MVP in two weeks. Implement the most critical endpoint first, submit transaction. Prove the concept works with the legacy system. (13/26)

The two-week build has three phases. Days one through five are research. The team studies the legacy system's data formats. Nobody needs to write COBOL. They only need to understand input and output structures. The submit transaction request has eight fields: terminal ID, merchant ID, amount, currency, card number, expiration date, CVV, and transaction type. The response has five fields: response code, authorization code, transaction ID, timestamp, and batch number. (14/26)

Days six through eight are building. The team writes a Node.js service with three functions: receive JSON, translate to COBOL, and send the COBOL response back as JSON. Days nine and ten are testing. The middleware translates a JSON request into a COBOL flat file, sends it to the legacy system, receives the response, and translates it back. The new terminal gets a valid response. The concept is proven. (15/26)

Last quarter, building this MVP proved the concept and saved $96,000. For an XP team, implement the most critical endpoint first, build it in two weeks, and prove the concept. This is your integration proof of concept.

### Step 3: Expand to All Endpoints Using Pair Programming Over Four Weeks (16/26)

Morita made the experience better by ensuring Sony products worked together seamlessly. You should expand the middleware over the next four weeks to cover all six endpoints. Use pair programming so two developers work together on each endpoint and knowledge spreads across the team.

Week one adds void transaction and refund transaction. Week two adds batch close for end-of-day processing. Week three adds status check for monitoring. Week four adds reconciliation for balancing totals. (17/26)

Each sprint uses pair programming. Anna and Ben build void transaction together. Carlos and Diana build refund transaction. Eve and Frank handle batch close. Grace and Hiro cover status check. Iris and Jake build reconciliation. When two people work on each endpoint, knowledge is not siloed. If one person is unavailable, the other can maintain the work. (18/26)

Last quarter, using pair programming across all five endpoints saved $88,000 by preventing knowledge silos. For an XP team of sixteen to fifty, cover all endpoints, use pair programming, and complete the expansion in four weeks.

### Step 4: Iterate With a Feedback Loop After Every Sprint (19/26)

Morita iterated constantly and Sony got better. You should run a feedback loop after every sprint. Review the middleware using three metrics. Fix one issue per sprint so the integration improves continuously. (20/26)

The feedback loop is a thirty-minute review. It has three parts. The first fifteen minutes review the data. Metric one is integration success rate, targeting 99%. Metric two is average response time, targeting 500 milliseconds. Metric three is unhandled legacy system errors, targeting zero. (21/26)

The next ten minutes address one issue. In sprint two, the team might add retry logic to fix transaction failures. The integration success rate climbs. The final five minutes plan the next fix, keeping a running queue of issues. (22/26)

Last quarter, four feedback loop reviews fixed four issues. Transaction failures were resolved and success rate went from 91% to 96%. Response time improved from 1,200ms to 800ms. Unhandled errors dropped from seven to two. A final data format fix pushed success rate to 99%. These four fixes saved $74,000.

For an XP team, use three metrics, fix one issue per sprint, run the loop after every sprint.

## The Takeaway (23/26)

Akio Morita did not build Sony by making products compatible with everything. He built his own ecosystem. Products worked together. The experience was seamless. Customers bought.

Your finance hardware SME should do the same. Create an integration layer design this week. Build the middleware MVP in two weeks. Expand it over four weeks using pair programming. Run a feedback loop after every sprint. (24/26)

Last quarter, this approach saved $112,000 on design, $96,000 on the MVP proof, $88,000 on knowledge sharing, and $74,000 on iterative improvement. A fifty-three-person SME stopped losing $486,000 per quarter on failed legacy integration. (25/26)

Have your XP coach create the integration layer design this week. Then build the MVP, expand with pair programming, and run the feedback loop after each sprint. The best way to make things work together is to stop trying to be compatible with everything and start building your own ecosystem.

#XP #AgileDevelopment #LegacySystem #SystemIntegration #ExtremeProgramming #PairProgramming #Middleware #SoftwareEngineering #DevOps #FinTech (26/26)