Addressing Platform Challenges Without Writing Code.

By 'without writing code', I do not refer to a no code dev platform. Instead, one of our biggest pain points was addressed without writing a single line of code.

Tell me more?

The organisation that I am working with currently provides data to numerous third-party point-of-sale systems, ('vendors' as we call them). Imagine a bustling marketplace where individuals (collectively - us) are selling various products. Each seller has information about their products, such as prices, descriptions, and availability.

Now, think of the vendors as knowledgeable mediators in this marketplace. Instead of every seller talking directly to each buyer (end users), the vendors act as an intermediary. Sellers provide their product information to the vendors, which then organizes and processes this data.

At any given time, a buyer can only interact with just one vendor (to optimise for cost, since they charge a small fee on every request 💰).

Such a tri party setup simplifies the process by collecting, organizing, and relaying information, making it more efficient for buyers to find what they need and for sellers to manage their transactions. This way, the vendors act as a bridge, improving the overall experience for both sellers and buyers.

Okay, what's the threat?

Like any other system, this setup had its downsides. The major ones being -

1. Integration and scale challenges - a lot of moving parts in a machine will always undergo wear and tear. But even configurational changes at one end (vendor/seller) would cause sudden spikes and slopes on the other.
2. Very low feature parity - some vendors would offer the complete feature set we supported, while one was still at an MVP level (yet catering to 10% of order volume - OV)

Every time the system architects and leads would design and build a robust system, with every solution we realized we were only differing the incidents by adding more compute, storage, new fallbacks, etc and never really solved the problem. This is when we had to zoom out and see what is at the core of the threat.

In most of our brain storming sessions, we would often refer to the vendor's system as "they wont support X", "they will not allow Y", "they might not be able to scale Z", and so on. This clearly indicated that we were still considering the vendor's system as a black box and did not care much about what the vendor uses to interface with the buyers. On discussions, the vendors acknowledged having the same mindset.

Yes, working with a black-box system is challenging. Working with a black box and expecting platform stability is hard!

Sure, what worked then?

We found that we did not need a high frequency engineering sync with the vendors as much as we needed a "platform sync". The platform sync would

1. Invite everyone from all our vendors whom we work with or is a decision maker in either product or engineering.
2. Unbox the "black box" that existed (ofcourse abstracting out the IP and confidential/internal details) for either side.
3. Discuss solutions that a vendor or we (the sellers) proposed and get general alignments from all our vendors.
4. Share threats to our systems and the solutions/plan to mitigate them.
5. Share our roadmap with vendors, and get their feedbacks

The outcome

The platform syncs have now enabled

1. Quicker TATs and better overall development.
2. Informed (lesser assumptions) design decisions for the system components that interface with 3rd parties.
3. Standardised platform that is backward compatible. This further has enabled the vendors to ship more polished solutions to the buyers.
4. Improved SLAs and incident recoveries.
5. Smoother feature development and roll outs.

As a key takeaway, one must ensure that Law of the Instrument should not come into play while solving problems. Zooming out to solve a problem helps when nothing works well.