The post has been translated automatically. Original language: Russian
"req" and "DIGAL": why did we divide the platform into "engines" and "add-ons"
In recent weeks, we have been reassessing the architecture of our product, and we want to share the logic with the Astana Hub community.
Initially, req was a single product, a SaaS procurement platform. Now we have switched to a two-tier model: Core products — "engines" for companies that need dedicated deployment for their infrastructure.:
- trade.core — exchange core
- clear.core — clearing core
- procure.core — tender core
req remains an easy entry point, a SaaS solution for those who do not need or cannot deploy their own dedicated core.
Add-in modules work on top of both models: req.gate, req.AI, req.agg.
This separation allows you to close both large corporate clients with their own infrastructure, and small/medium-sized businesses that need an "out of the box" solution
req и DIGAL: зачем мы разделили платформу на "движки" и "надстройку"
Последние недели мы пересобирали архитектуру нашего продукта, и хотим поделиться логикой с сообществом Astana Hub.
Изначально req был одним продуктом — SaaS-платформой для закупок. Сейчас мы перешли на двухуровневую модель: Core-продукты — «движки» для компаний, которым нужно выделенное развертывание под свою инфраструктуру:
- trade.core — биржевое ядро
- clear.core — клиринговое ядро
- procure.core — тендерное ядро
req остается легкой точкой входа — SaaS-решением для тех, кому не нужно или невозможно разворачивать собственное выделенное ядро.
Поверх обеих моделей работают модули-надстройки: req.gate, req.AI, req.agg.
Такое разделение позволяет закрывать и крупных корпоративных клиентов с собственной инфраструктурой, и малый/средний бизнес, которому нужно решение "из коробки"
Share
