Craig Pardey

ISO 20022 defines a catalog of messages to standardize data exchange in the finance industry, and it is gaining popularity in Payments.

Here in Canada, Interac updated their APIs to support ISO 20022 several years ago. FedWire in the US will be rolling out ISO 20022 support in summer 2025, and Zelle is following suit with its integration to The Clearing House’s Real-Time Payments network.

But it’s not a standard despite what the name implies.

I wrote about DRY configs many years ago but astonishingly my clients don’t seem to read my blog. I mean, who even has a blog these days anyway?

Externalized application configs have a way of multiplying like rabbits to the point where people become afraid to touch them at all, let alone apply the DRY principle to them. The proliferation of poorly-designed configuration files in Enterprise Java systems is appalling, and the situation is compounded when an external configuration system like Consul or Spring Cloud Config is added to the mix.

I recently had to return an item that I’d bought online. It’s free to return the item in-person to one of their retail locations, or $10 to ship it back. There was a store nearby so I elected to do an in-person return but the experience shows what can happen when software and processes are developed without involving the user.

The store clerk was friendly and helpful. He asked for my online order number, found it in the system, and told me that the money would be refunded to the original form of payment used for the purchase - in this case, PayPal. Everything is going smoothly to this point.

Only by increasing flow through the constraint can overall throughput be increased – Eliyahu M. Goldratt, The Goal, 1984

Turning this around we get the corollory that optimizations made to areas other than the constraint only serve to worsen the constraint.

Agile practices, and particularly Scrum and SAFe, have been widely adopted in large enterprises over the last decade or so, spawning entirely new departments dedicated to locking down the process. Agile Centers of Excellence (CoEs) produce materials explicitly describing every aspect of their company’s specific flavour of Agile, and have coaches dedicated to enforcing it across the teams.

Plans are worthless, but planning is everything – Dwight D. Eisenhower

The value of a process is primarily derived from the process itself, not the output.

Producing a slide deck or document on a topic requires hours of thought, multiple drafts and revisions, wordsmithing, and lots of research.

This iterative process helps to clarify your thinking around a topic. The hours spent thinking deeply about a problem and continuously refining your arguments is where the real value lies, not in the artifact that results from that process.

If your sign needs a sign explaining the sign then it’s a poorly-designed sign.

Let me present a few examples. I’ll start with the intersection at Bloor and Parkside in Toronto shown below.

There are four lights in this image: one for the through traffic, one for the cyclists, and two for the right-turn traffic. Both the bicycle signal and the right-turn signal have additional signs adjacent to them explaining what those lights are for. The placement of these explanatory signs is inconsistent: two are to the right of the signal, one is to its left.

Non-Functional Requirements (NFRs) are used extensively in enterprise software to define things like performance requirements and availability expectations but it’s important to be specific about what we’re asking for.

I spend a lot of time with my clients helping them understand why the details matter for NFRs so let’s walk through an example to demonstrate what I’m talking about.

Let’s assume we’re dealing with a system that is going to process 3-5 million transactions per day with peak volume during business hours at around 50 transactions per second. A sample NFR for such a system might be stated as:

I’m currently working with a large retail banking client to help them modernize their payments infrastructure. The word “modernize” is used in just about every client interaction. It appears in all the slide decks. It’s part of the business case justification.

But modernization is a relative term.

The big question is: What does the client mean by modernization?

The existing system is a vendor product running in an on-prem application server. It’s an opaque monolith that is challenging to operate, and to cap it off the vendor has announced that they’re ending support in a few years so my client needs to get off this platform in order to stay competitive in the payments space.

A moral hazard is when an..

…actor has an incentive to increase its exposure to risk because it does not bear the full costs of that risk.

It’s similar to perverse incentives.

A perverse incentive is an incentive that has an unintended and undesirable result that is contrary to the intentions of its designers.

I have spent the last 6 months working closely with a QA team inside a large financial instutition and have become increasingly skeptical of the value they provide - the development team don’t test as thoroughly as they should because they know that QA are playing backstop.

QA organisations have come a long way in the last decade or two. In the early 2000s, automated unit testing was just gaining popularity and QA was performed manually by armies of testers. The QA process was time-consuming and arduous, and the testing timelines were the first thing to be compressed when development took longer than planned (as it almost always did).

By the 2010s, many applications had moved to a web interface which allowed QA teams to automate some or all of the end-to-end testing using Selenium, or similar. This was a giant leap forward, especially for basic 3-tier apps with a web UI, a “services layer”, and a database. Everything was nicely contained in the one codebase, including the tests. Coupled with Cruise Control Hudson Jenkins, we had a reliable way to delivery quality software quickly.