What growth by business line does to an architecture
The group ran several used-vehicle businesses — retail, enterprise, auctions, procurement, inspection, financing — each of which had grown its own systems. Individually every choice had been reasonable. Collectively they produced an enterprise where the same customer existed several times over, the same vehicle was described differently in each system, and money moved through processes that were largely offline.
The commercial cost was not abstract. Leads raised in one business were invisible to another, so conversions were lost or happened later and at a lower price. Product data spread across business lines meant the same delay. An enterprise customer with several relationships had several logins, several contracts and no hierarchy, so credentials were shared. Reporting was embedded inside each product, which meant the group could describe each business but not itself.
This is the point at which the problem stops being a systems problem and becomes an architecture problem. No individual replacement fixes it, because the fragmentation is in the seams rather than in any one system.
The same customer existed several times over, and the group could describe each business but not itself.
Running the engagement as TOGAF ADM, not as a design exercise
The engagement ran the Architecture Development Method properly, starting where it is most often skipped: the preliminary phase, establishing what architecture capability the organisation actually had and wanted. That produced an organisational model for enterprise architecture, a tailored architecture framework with an explicit principles catalogue, an initial architecture repository and a governance framework.
Only then came the architecture vision — the capabilities and business value the target architecture would deliver — signed off before any target design work began. Business goals and scenarios were captured as a traceable artefact, so every later architectural decision could be traced back to a business objective rather than a preference.
Business goals were not assembled from stakeholder interviews alone. Customer feedback was collected through SurveyAnalytica, our own research platform, and used to establish the problem statements the architecture had to answer — so the traceability runs from evidence, through business objective, to architectural decision, rather than starting at somebody's opinion of what was wrong.
That sequencing matters more than it sounds. An architecture produced without an agreed capability model and principles is a document; one produced with them is something the organisation can govern and extend after the consultant leaves.
The target platform
The target is a service-oriented marketplace platform supporting multiple channels and several distinct kinds of user — retail consumers, enterprises, banks, dealers, inspection partners — on one set of shared services.
Identity, product information, pricing, inventory, orders, cart, quotation, auctioning, vendor management and onboarding, inspection, and background verification each became a service in their own right, rather than a feature inside whichever business line needed it first. A platform enhancement layer sits between those services and the channels, so neither side depends on the other's internals.
Content is headless: one CMS defines templates, pages and components that power the websites, the native apps, campaign emails and print collateral alike, instead of each channel maintaining its own.
Underneath, a data pipeline is the backbone for all movement across the landscape — streaming, pub/sub, REST and file-based entry points, with ETL and privacy profiling applied in transit — feeding a data lake that gives a composite view across services, billing, tickets, invoices and events. Reporting stops being something each product does privately.
The decisions that carried the most weight
- One identity, with hierarchy. An enterprise is not a user. Modelling companies, banks and dealers with their own structures, approval workflows and sub-users is what stops credential sharing and makes contracts assignable.
- Central procurement and inventory. Each channel had been procuring separately; a single procurement path with one inventory service is what allows stock to be sold through any channel.
- The data pipeline as backbone rather than as an integration project. Point-to-point connections between a dozen services would have recreated the original problem in newer technology.
- Headless content, so a new channel is a consumer of existing components rather than a new content estate.
- Product data mastered once. The same vehicle described consistently across retail, enterprise and auction is the precondition for everything else.
What I would tell someone facing this
- Do the preliminary phase. Skipping to target design produces a document nobody can govern — the principles and org model are what let the client carry it forward.
- Trace every architectural decision to a business objective in writing. It is the only defence against the decision being reopened every quarter on preference.
- Decide explicitly what becomes a shared service and what stays with the business line. Centralising everything makes each release an enterprise release; centralising nothing is what got you here.
- Model the enterprise customer before the consumer. Consumer identity is the easy case; hierarchies, approvals and shared contracts are where the design actually strains.
- An integration backbone is architecture, not plumbing. If it is treated as a project deliverable it will be de-scoped, and the fragmentation returns.
In their words
Cosmoneural was very quick to grasp our business and product requirements — the as-is and the magnitude of change involved. Strong fundamentals meant they simplified the problems and delivered a good, scalable solution on exactly the right technology. Hands-on throughout, and always with the big picture in mind. We look forward to working with them again.
Ananthanarayanan S, Head — Product Management, Mahindra First Choice Wheels · 2021
Technology
- SurveyAnalytica (own research platform)
- TOGAF ADM
- Microservices
- Headless CMS (AEM)
- Apache SOLR
- Data lake & data pipeline
- AWS
- CIAM / single sign-on
- Event streaming and pub/sub