Essential systems nobody could describe
The logistics application landscape at Royal Flora Holland is a complex set of applications and data stores spread across AWS and several on-premise environments. Together they support business processes that are essential to the company's daily operations.
Royal Flora Holland is modernising its business IT landscape, and logistics was a natural part of that effort. The aim is to move to new landing zones on AWS and to limit the set of building blocks and approaches, so that teams benefit from standardised technology.
The landscape had grown organically over a long period. Documentation of how individual applications actually worked was often outdated or missing altogether. The challenge went beyond technology: the business processes these applications implemented also had to be reviewed and, where needed, modernised or phased out.
Map first, then migrate, one application at a time
A landscape you cannot describe is a landscape you cannot move. The work started with a technology map of what was actually running, and only then became an iterative programme of updating architectures and migrating them. Brighting's part was consultancy and architecture: we mapped the estate, designed the target architectures and owned the queue. The engineering was done by Royal Flora Holland's own teams.
Map the landscape
Every application and data store in logistics, described from a technology point of view. Where documentation was outdated or absent, we established how things actually worked.
Review the processes behind it
The business processes these applications implemented were reviewed alongside the technology, and where needed modernised or phased out. Not everything on the map was worth migrating.
Fix the set of building blocks
AWS CDK for infrastructure, uniform application packaging, and a preference for languages and data stores where sufficient experience already exists. A limited set, so teams benefit from standardised technology.
Design the target, own the queue
An iterative cycle: rework an application's architecture, decide what moves next, and hand it to the delivery teams. Event-driven integration between applications replaces the older couplings.
Bring AI into the development process
AI was introduced into the way the teams work, to speed up delivery and to build the set of automated tests that supports rapid development. More emphasis on automated testing was part of the plan from the start.
A map, a standard, and a migration in motion
A technology map of the landscape
Applications, data stores and the environments they sit in, described where documentation had gone stale or never existed.
Target architectures per application
Designed against the standardised building blocks, with product ownership and solution architecture held in one pair of hands.
A migration path and its priorities
Sequenced iteratively for the delivery teams, so the estate kept running while it changed underneath.
An AI-assisted way of working
AI brought into the development process, and the automated test set that lets the teams keep moving at that pace.
Architecture and ownership in the same person
Someone has to decide what gets migrated next, and someone has to design it. Over more than a year, that was one role rather than a committee, which is why the queue kept moving.
Cloud Native Engineering
Landing zones, infrastructure as code and event-driven integration are the patterns we design with on AWS every day. We are an AWS partner, which is what lets us advise on this stack with conviction.
AI in the development lifecycle
Our AI-DLC practice puts AI inside the way a team works, not beside it. Here that shaped the development process and the automated test set behind it.
More of our work
All cases →
Could your team describe your own landscape?
We map what is actually running, agree a limited set of building blocks with your architects, and design the migration path application by application, so your teams can deliver it while the business keeps operating.