When my daughter was young and first learning to play chess, she would sit across the board from me to work through her available moves. Like all beginning chess players, there was a certain simplicity to her approach. She understood the rules, knew how each piece moved and had a small catalog of basic strategies. But at her young age and inexperience, she had yet to learn the richer, multi-level planning and strategy that makes chess so simple and elegant yet so complex and wonderful.
Chess and computer programming have a lot of similarities. Everything is interconnected. Every choice is impacted by decisions you’ve previously made, and every move you make affects your options in the future. When I designed Tritium®, this was the challenge I wanted to solve. Why?
Because this same challenge plagues many in the technology space, particularly in payments technology. They have teams of developers who know how to write code and make their platform perform the required tasks, but three key challenges limit them:
1. Their flexibility is limited by the choices already made – Imagine you walk up to two people playing chess in the park. One of the players asks you to take over for them. As you sit down at the board, your options are immediately limited by the previous player’s choices. All you can do is find the best path forward from the partially completed strategy and pieces you have available. This situation is playing out in paytech companies across the world. Years and years of legacy payments technology and technical debt limit developers’ ability, restrained to a fraction of their potential by decisions made before they ever write a single line of code.
2. They can’t see the whole board – In many large paytech companies, business strategy and development sit in two siloed parts of the organization. As a result, frontline developers do not understand where their platform came from and where it’s going.
Business decisions in some remote corner of the organization drive technology updates which are translated into tickets for the development team. Returning to the chess analogy, they’re asked to move a piece forward on the board, but all they are only able to see a fraction of the board. They have no idea what moves have already been made, where the other pieces are, and where they’re trying to go beyond the next space. With limited information available, their solution to a business challenge is a hard-coded solution. The piece moves, but was it a good move? There’s no way to tell, and once you’ve moved there’s no going back.
3. They can only play with the pieces on the board – Building on our chess in the park analogy, developers at legacy paytech companies are left with whatever pieces remain on the board. And there are specific rules governing every piece on the board. A knight is a knight. A rook is a rook. A pawn is a pawn, unless you reach the last rank of the board. Then, you can promote it (change it into a queen, rook, bishop, or knight). Once again, these restrictions combine to limit the available options now and in the future.
Now, imagine a different scenario.
First, imagine a scenario where the technical debt and hard-coded solutions of previous generations of developers don’t inhibit you. Every integration starts fresh from the same foundational base code. Almost anything is possible. It’s like starting with a reset chessboard every time.
Second, because the technology team is part of the strategy and planning process, they understand the broader project. Instead of looking at a single square of the chess board and coding for a single move, the developers see a comprehensive view of the board. They understand the opportunities, threats, and end goals and can plan accordingly.
The result is a simple and elegant solution that provides our development team (and our customers) the maximum flexibility to design an ideal payments technology solution. This means you’re never forced into a Kobayashi Maru scenario. There’s always a way to build a winning paytech product.