bluebay2014 - stock.adobe.com

Inside Grab’s platform strategy

Grab’s group CTO talks up the super app’s platform strategy, architecture and organisational structure behind its growth across diverse Southeast Asian markets

From a humble taxi-hailing service in Kuala Lumpur to Southeast Asia’s leading super app, Grab has become a regional household name that offers a diverse range of services spanning ride-hailing, food delivery, parcel delivery and financial services.

Today, the company boasts of the largest on-demand fleet in the region, with six million driver partners and six million merchants and kiosk partners. Last year, it handled 3.5 billion transactions, and by the second quarter of 2024, its number of monthly transacting users had reached an all-time high of 40.9 million.

But the company’s growth across the region wasn’t simply a matter of scaling up – it had to build a platform to navigate the unique challenges of the region: geographically diverse populations with varying cultures, regulatory environments and business landscapes in mostly emerging markets where affordability matters.

To address these hurdles, Grab adopted a platform-based architecture and organisational structure that consists of three layers, according to Grab’s group chief technology officer, Suthen Thomas Paradatheth.

Speaking at the Government Technology Agency’s Stack 2024 developer conference, he said the top layer comprises business verticals responsible for consumer-facing products such as ride-hailing and food delivery, each with its own business targets.

The product platforms layer sits in the middle, providing common services for all business verticals to foster reusability and prevent duplication. The technology infrastructure platform underpins the entire system, handling critical functions such as deployment, infrastructure management and compliance.

This structure, said Paradatheth, reflects Grab’s organisational design, adhering to the “reverse Conway manoeuvre” that aligns organisational structure with architectural goals, rather than the other way around in Conway’s Law, which posits that technical systems inadvertently reflect the organisational structures behind them.

Automated deployment

Grab has already reaped benefits from its platform approach. For one thing, the technology infrastructure platform has enabled it to shift from a manual, error-prone deployment process to automated deployment using a tool called Conveyor, which lets any Grab developer automatically deploy changes to production.

The tool deploys the changes to a canary environment, monitors the deployment and automatically rolls back changes if any issues are detected. This has enabled Grab to do around 17,000 deployments per month, or about 100 deployments per day.

The technology infrastructure platform team owns the entire development, deployment and operations processes, as well as application code, and machine learning and large language models. It also handles tasks such as patching operating systems, managing infrastructure and addressing security vulnerabilities.

This abstracts away the complexity of infrastructure management from development teams, allowing them to focus on building software features using an internal framework that allows them to spin up new microservices with instrumentation and testing in place.

At the product platform layer, a fulfilment team manages all the interactions between business verticals and driver partners, offering capabilities such as supply shaping, pricing, dispatch and fleet management.

Before the fulfilment team was formed, each business vertical had its own batching engine for clustering multiple jobs and orders together. The fulfilment team has consolidated these batching capabilities into a single system, eliminating duplication and improving efficiency.

With a more holistic view of a driver’s activities, the fulfilment team can now perform global optimisations across all business verticals, such as interleaving on-demand jobs such as transport rides and food deliveries within the driver’s schedule to optimise the use of their time. “All the verticals are competing for the driver’s time,” said Paradatheth. “If that competition isn’t managed well, you could end up with local optimisation that doesn’t maximise the earnings of the driver.”

Read more about IT in ASEAN

However, Grab’s platform journey wasn’t without obstacles – there was pushback from business verticals about the loss of control. “There were tears,” said Paradatheth, describing the initial resistance. “People were upset.”

Grab addressed these challenges through a combination of strategies: accepting a trade-off between agility and efficiency, and focusing on metrics and outcomes to demonstrate the impact of platforms. More importantly, it defined clear interaction modes to address dependencies between platform and vertical teams.

The first interaction mode involves vertical teams providing platform teams with budgets to hire resources and address the dependency. While seemingly generous, it can lead to inefficiencies and doesn’t promote collaboration.

The second mode involves code-sharing and collaboration where the dependent team makes minor modifications to the platform themselves, with the product platform team reviewing the changes. For more complex changes, a “high touch” model has both teams contributing engineers to a temporary team focused on building the required functionalities.

The most preferred way to address dependencies, said Paradatheth, is through what he dubbed X as a service, the “gold standard” where platforms expose application programming interfaces that vertical teams can consume.

This promotes low coupling and allows for independent development, such as a fulfilment service that exposes parameters, such as the number of seats and required service levels, rather than specific product types such as taxis.

In building platforms, Paradatheth noted the importance of defining platform boundaries, identifying situations where platforms offer significant advantages such as reducing toil and managing competition for resources, as well as addressing the human element. “Getting the boundaries right is crucial,” he said. “And recognising the socio-technical problems – the human dimension – is just as important as the technical aspects.”

Read more on IT architecture