Three Customers, One Entity
A retail group has absorbed two competitors and now runs three brands. Fourteen systems hold customer master data, and three different logical entities are all called 'Customer' - one inherited from each brand's legacy model. The architecture team wants a single canonical customer entity mandated across the group. A vendor publishes a retail industry reference model containing a customer data model and standard integration patterns. The group has just licensed an architecture repository tool. The team is unsure whether the canonical entity, the vendor model and the three legacy entities belong in the same place, at what level of the Architecture Landscape they should be modelled, and which of them counts as a standard rather than a reference. The Head of Architecture has two architects and one quarter to show progress.
1. Place the vendor reference model, the proposed canonical entity and the three brand-level customer models on the Enterprise Continuum, and say what each placement implies for reuse and for governance.
Read the worked answer
Vendor model → Architecture Continuum, Industry (with elements at Common Systems) level. It is a reference architecture: useful as a starting point, a checklist of what a retail customer model typically contains, and a source of integration patterns. It is not a standard, and adopting it wholesale is a decision the group has to justify against its own requirements.
Canonical customer entity → Organisation-Specific Architecture. It sits at the right-hand end of the continuum because it encodes the group's own decisions about identity, hierarchy and survivorship across three brands. Once mandated it should be entered in the Standards Information Base, and from then on deviations are exceptions requiring a dispensation, not local design choices.
Three brand-level customer models → Organisation-Specific Architecture, at segment or capability level. They describe real deployed systems and are transitional, not target. Their value is as baseline descriptions and as a gap analysis input; their danger is that they get treated as legitimate variants and the duplication persists.
The implication is directional: the continuum is meant to be traversed from industry reference toward organisation-specific, reusing rather than rebuilding. It does not mean mandating the vendor model uncritically. The judgement is where the group's genuine differentiation lies - if customer identity rules differ by brand for commercial reasons, that difference belongs in the organisation-specific architecture and should be stated explicitly rather than emerging by accident from three legacy models.
2. Which level of the Architecture Landscape should the team model to resolve the duplication, and why not simply go enterprise-wide strategic?
Read the worked answer
A strategic architecture describes the long-term, group-wide target at a level of abstraction suited to direction-setting. It would say that customer data should be managed once and shared. It would not tell you which of fourteen systems is the system of record, what the entity structure is, or which integration patterns to retire - and those are the decisions blocking progress.
A segment architecture for the customer domain across the three brands is the natural boundary: it has a clear business outcome, a defined scope and an owning sponsor. Within it, a capability architecture for customer data management gives the granularity actually needed - the entity catalog, an application/data matrix showing which of the fourteen systems creates, reads and updates each attribute, and a diagram of the target data flows.
The levels are not a mandatory sequence. Capability and segment architectures can be developed iteratively and reused as building blocks; what matters is that the level chosen matches the decision being made. With two architects and one quarter, attempting an enterprise-wide strategic model first would consume the whole quarter and still leave the fourteen systems untouched. The Content Metamodel then governs which entities and relationships must be captured, and the artefacts are simply catalogues, matrices and diagrams - the format question is less interesting than the scope question.
3. What should go into the repository, and what should deliberately stay out?
Read the worked answer
In:
- The Architecture Landscape, holding the strategic, segment and capability architectures at their respective levels of granularity.
- The Standards Information Base, holding the mandated canonical customer entity, the agreed integration patterns and any technology standards the group will enforce.
- The Reference Library, holding the vendor's industry model and any external guidance - clearly marked as reference, with a note on which parts were adopted and which rejected.
- The Governance Log, holding the decision to mandate the canonical entity, the dispensations given to brands that cannot migrate this year, and the owners and expiry dates of those dispensations.
- The Solutions Landscape, recording the actual products and instances - the MDM platform, the fourteen source systems - so the architecture can be traced to what is deployed.
Out, or at least curated hard: the vendor model in full, unedited. Loading an entire industry model into the repository creates an illusion of reuse while making search and governance worse; curate the parts actually referenced. Project plans and RAID logs stay out as well - the repository is not a programme management system.
The judgement is curation cost against reuse value. With two architects, a small well-governed repository that people trust beats a complete one that nobody maintains.