6 subsidiaries, 25 years of history, and an architecture function that can no longer keep up with the business
Before
with no architectural consistency amid growing decentralization
After
operating subsidiaries with IT systems to coordinate
operating subsidiaries with IT systems to coordinate
of history and accumulated complexity
architecture function repositioned and operational
After 25 years in business, a long-established digital retailer split its activity into several operating subsidiaries: supply chain, B2B marketplace, B2C platform, retail media, a technology subsidiary serving the business units, and cybersecurity. The ecosystem grew more complex as the business evolved, with a growing need for consistency in a decentralized context. The architecture function struggles to serve the business platforms effectively: its positioning, its practices and its ability to guide decisions are all being called into question.
SITUATION BEFORE
- Operational baseline
- An ecosystem decentralized into 6 operating subsidiaries with heterogeneous IT systems. An architecture function struggling to serve the business platforms. No consolidated view of the business functions and the technology solutions behind them.
- Teams affected
- The entire organization: 6 operating subsidiaries whose IT systems must stay consistent despite decentralization.
- Hidden costs
- Architecture decisions made in silos by each subsidiary, creating cross-cutting technical debt and redundancies. Delivery slowed down by the inability to settle cross-cutting technical choices quickly.
- Why it was not solved earlier.
- The complexity built up gradually, one subsidiary at a time. The architecture function had been designed for a centralized ecosystem and had never been repositioned for a decentralized, multi-business context.
THE STORY
OUR APPROACH
6 steps to get there
Build a shared language between business and tech
An essential first step: make sure business and tech speak the same language. On a selected business scope, Nobori Partners takes stock of the terms used by tech and by the business, analyzes where they overlap and where they diverge, then builds a shared vocabulary through discussions about the business itself: business processes, problems to solve, stakeholders involved. Without this foundation, every map and every architecture decision rests on misunderstandings.
Build the functional view of the business systems
Walkthrough interviews of the business tools, collection and analysis of existing functional documentation, then co-design workshops on the functional building blocks with the teams. The result: a formalized functional map of the identified business scope, along with the process to maintain it and evolve it over time.
Take ownership of business data
Interviews to gather information on business data, collection of existing documentation, identification of the data repositories and of how data propagates across the IT landscape. A formalized data map of the identified scope, with the process to keep it alive.
Correlate the functional view with technology solutions
Cross-analysis of functional and technology documentation, interviews on the technology tools in use and the projects underway. Study of the functional coverage of the technology solutions. Construction of a pragmatic application landscape map, close to reality on the ground, linking business functions and technology solutions.
Assessment and repositioning of the architecture function
Interviews on the current positioning of the architects, analysis of standard deliverables, understanding of the process for guiding business/product teams. Identification of pitfalls and formulation of recommendations. Then co-design of the target positioning of the architects and redefinition of their role in guiding teams, through co-design workshops.
Redesign the guidance process and deliverables
Co-design of the target process for guiding business/product teams, identification of the actions needed to put it in place, and a stress test on a pilot initiative. In parallel, identification of the key architecture deliverables for each stage of the process, building their content with the team, and validation on the same pilot initiative.
RESULTS
The measurable impact
A shared business/tech language built on a pilot scope. Functional and data maps formalized with the teams. A pragmatic application landscape map linking business functions and technology solutions. The architecture function repositioned, with a redefined process for guiding business/product teams, tested on a pilot initiative. Architecture deliverables structured and aligned with each stage of the process.
Is your architecture function struggling to keep up with the complexity of your ecosystem? Let's talk repositioning
Book a discovery callSIMILAR CASE STUDIES
data initiatives delivered
At the heart of Intermarché's Data Factory, Nobori Partners laid down the architecture and governance that took more than 15 initiatives (ML, BI and e-commerce streaming) from study to production.
Read the case studysaved on back-office processing
Blank, the Crédit Agricole group neobank for freelancers, was growing fast, but its operations teams were flying blind, held back by a DynamoDB architecture designed for scalability, not for analysis. In 4 months: a real-time pipeline, self-service dashboards, 1 FTE freed up.
Read the case study