Walter Okumu Oriaro
I build the layer between systems that were never meant to talk to each other.
Integration architect and engineering leader. Fourteen years in software; the last four spent almost entirely on making payment rails, CRMs, ERPs, analytics platforms and legacy registries work together across seven countries, in low-bandwidth markets, on infrastructure we run ourselves.
Head of Product Development, Yellow Pages Group
I lead a newly created department reporting to the CEO and COO, with technical ownership of the group’s product platform across Kenya, Cape Verde, Mozambique, São Tomé, Angola, Tanzania and East Timor. I set the architecture and the quality bar, manage a small engineering team, and still write and review the code.
Before that I led the 15-person Customer Success and Web Development function for nearly three years, and built the API infrastructure and CI/CD systems the whole group now runs on. Everything below came out of those two roles.
systems
Four systems, and what each one had to solve
These run in production. The repositories are private, so what follows is the design reasoning rather than the code — which is the part worth reading anyway.
Multi-system integration hub
A spec-first hub fronting more than twelve external systems: a website platform, a listings-distribution platform, three Google data APIs, transactional email, object storage, a CRM, an ERP carrying HR and billing, a reporting service and a legacy Oracle registry. One OpenAPI document is the contract and the shared types are generated from it, so the front end cannot drift from the back end quietly. Governance is part of the product, not an afterthought: scoped API keys, rotation with an overlap window, country-level feature flags, integration health monitoring and encrypted columns.
Payment gateway abstraction
Every provider is an adapter behind one interface — capability negotiation, checkout construction, callback handling, refunds. Adding a market is one new file and one line in the registry. It runs across two countries and three gateways, including a direct M-Pesa Daraja integration with source-IP verification, and card acquiring with EMV 3-D Secure 2.2.0. The interesting problems were not the connectors: idempotent callbacks, MSISDN normalisation, per-response CSP nonces for provider-rendered pages, and log redaction that is a property of the logger rather than a convention.
Governed read access for AI tooling
A read-only platform gateway exposing four datastores to AI agents and internal services. The read-only guarantee is enforced at the SQL-parse layer rather than by convention or by trusting a database role, and the whole thing is designed to run VPC-internal with no outbound egress — the same constraint a sovereign or air-gapped deployment imposes. Architecture and security model are complete; implementation is in progress, deliberately staged so nothing can serve data before the guarantee is verifiable.
Lead intake middleware for a European client
A consulting engagement delivered with a written client decision record, an explicit scope boundary, thirteen architecture decision records and an operational runbook for the one failure mode that matters. Store first, respond, then notify and deliver — the visitor’s response never waits on a third party, so every delivery failure is a retry against durable state instead of lost data. The downstream CRM push shipped built and configuration-gated off, because the client’s CRM was mid go-live; enabling it is a config change and a restart, not a rebuild.
What a hub for twelve systems looks like
One hub, not a mesh. Every external system is reached through the connector layer and nothing else in the estate calls them directly, so there is exactly one place where “what does a customer look like” is answered, and one place to change when a vendor moves their API.
Numbers I can stand behind
How I work
- Specification before implementation. A contract first, types generated from it, CI failing when the spec does not validate. It is the highest-return convention I know and it costs nothing at the start.
- Decisions written down and dated — including the ones that turned out wrong. A stale architecture document is worse than none, because everybody trusts it right up until the first time it lies.
- Documentation ships in the same pull request as the change, never as a follow-up.
- Conventional Commits enforced in CI, protected branches, automated versioning, tag-triggered deploys. Process a three-person team can actually sustain.
- Config-gated delivery. Build the integration, test it, ship it, leave it off behind configuration until the receiving system is ready. Deferring the switch costs nothing; deferring the work means rebuilding context later.
- Mobile-first and WCAG 2.1 AA on anything with an interface, because the markets I build for are phone-first and bandwidth-constrained.
- An ISO 9001 habit for process, ISO 31000 for risk, ISO 27001 for security hygiene — applied at the scale a small team can hold, not as paperwork.
I would rather write down what a design does not yet handle than present it as finished. Most of what I have learned about integration came from the second and third provider, not the first.
Fourteen years
BSc Computer Science & Software Engineering, Catholic University of Eastern Africa. Full-stack programme at Microverse, where I have mentored developers since 2022 — weekly code review on architecture decisions and real engineering standards; three mentees have gone on to their first developer roles. Currently working toward AWS Solutions Architect – Associate.
Notes on integration architecture
The systems are private, so I write about the design reasoning instead — the constraints that produced a decision, and what I would change now. Currently: why an adapter registry beat a switch statement for multi-market payment routing, and the four governance concerns that turned out to matter more than the connectors.
Get in touch
I am open to senior engineering leadership roles — remote, Africa or Europe time zones — and to fractional technical advisory work where the problem is integration, platform architecture, or getting a small team to ship reliably.