The lifespan problem
Public sector platforms have an awkward characteristic. They are expected to last a decade or more, but they are built on technologies and integrations that change much faster. The certification authority introduces a new digital signature standard. The mobile network operator changes its API contract. The donor introduces a new reporting format. The cloud provider deprecates a managed service. Each change, in a tightly coupled system, becomes a partial rewrite.
The result is the familiar trajectory of public sector software. Year one, the platform is celebrated. Year three, integrations break and patches accumulate. Year five, the institution is paying more to maintain the platform than it would cost to rebuild it. The platform is technically alive and institutionally dead.
The discipline behind hexagonal architecture
Hexagonal architecture, also called ports and adapters, treats this lifespan problem as the central design constraint. The core idea is a strict boundary between two layers. The domain layer holds the business rules, the data model, and the policies that the institution genuinely owns. Lot identifiers, certification workflows, role permissions, audit obligations. The infrastructure layer holds everything that depends on a specific technology choice. The database driver, the messaging gateway, the certificate signing library, the file storage client.
The boundary is enforced by ports, which are interfaces the domain defines, and adapters, which are implementations the infrastructure provides. The domain never imports infrastructure code. When a technology changes, the team writes a new adapter and plugs it in. The domain is untouched.
Why this matters for institutional clients
The institutional benefit is concrete. The platform survives technology changes. When a regulator introduces a new digital certificate standard, it is one adapter. When the cloud provider deprecates a managed service, it is one adapter. When a partner system changes its API, it is one adapter. The business rules, the data history, the audit logs, and the user workflows are all preserved.
The discipline also makes testing far cheaper. Domain logic can be tested in isolation, without spinning up a database or a messaging gateway. Adapters are tested against the third party contract. Defects are caught earlier, debugging is faster, and the institution can extend the platform without fearing the kind of regression that brings everything down.
What we deployed for FAO Burundi
The Imbuto platform delivered to FAO Burundi by PANEOTECH and ASER Technologies, with co financing from the African Development Bank and government leadership from the Ministry of Environment, Agriculture and Livestock, is built on a hexagonal Node.js and TypeScript backend with a MongoDB document store and a React Progressive Web App frontend. The seed sector business rules, the lot traceability logic, the role permissions, and the audit obligations live in the domain layer. The certification gateway integration, the storage client, the cloud provider, and the CDN all live behind explicit ports.
The Ministry now owns a platform that can absorb future regulatory changes, partner integrations, and operator changes without architectural disruption. The investment compounds rather than depreciates.
The architectural lesson
For platforms with a ten year horizon, the boundary between domain and infrastructure is not an academic concern. It is the difference between a system the institution still owns in year five, and a system it needs to rebuild. Hexagonal architecture is the discipline that earns the longevity.
