“Which Customers Are Affected?” Is an Architecture Question

A company plans to retire an older authentication service. Before announcing the change, it wants a list of customers who still depend on it and an explanation of what each customer needs to do.

This is a fictional design exercise. It is also specific enough to expose the choices hidden inside a request to “build a knowledge layer”. We have an outcome to evaluate, relevant systems to examine and a reason to stop modeling when we know enough.

I would not begin by selecting a graph database. I would ask the team to walk through one customer they believe should be on the list and one they believe should not. The disagreement between those cases is likely to teach us more than an inventory of every enterprise data source.

The first decision is what “affected” means

A product might include an optional integration with the retiring service. One installation uses that integration; another does not. A third has already migrated, although its CRM record still carries the old product name.

If we model only Product and Customer, we cannot distinguish these cases properly. The installed configuration matters. So does the difference between a planned migration and a completed technical change.

The investigation needs to separate technical exposure from the response to that exposure. A required dependency identifies an installation that needs attention. It does not, on its own, establish a contractual notice obligation or the person to contact. Those are subsequent questions with different evidence.

That separation gives us a useful first deliverable: a reviewable set of exposed installations, connected to the relevant subscriptions, with unresolved cases retained. We can add contract interpretation once this narrower capability is working. Combining every stage into an affected_customer flag would conceal where a mistake came from.

Choose the concepts that distinguish the cases

For this first version, I would represent installations, configuration versions, technical components, subscriptions and organizations in their relevant roles. The installation uses a configuration; the configuration contains required dependencies; the subscription identifies the commercial arrangement for the installation.

A CRM account remains a separate object. It may represent the relationship with a corporate group, while the subscription names a particular company as contracting party. Matching their names does not make the two records equivalent.

The model need not contain a comprehensive theory of corporate ownership. It needs the relationships that support this investigation, with definitions precise enough that the team can classify an awkward example. If two people disagree about whether a test installation belongs on the customer list, we have found a scope decision that must be made before automating the answer.

This is where competency questions are useful. In ontology engineering, they describe questions the representation must support. Here they might ask which active installations have a required path to the retiring service, which subscriptions those installations belong to, and which identities remain unresolved.

The point is not to give every question an academic name. It is to make a model earn each distinction through something the application needs to answer.

Treat the mappings as part of the model

Suppose the deployment system records migration_status = COMPLETE. Before using that value to remove an installation from the list, I would inspect what the workflow actually means by complete. It may mean that the migration ticket is closed, not that traffic has stopped using the old endpoint.

A technically successful import can preserve the wrong interpretation perfectly. Renaming COMPLETE to migrated does not improve the evidence.

For this design, I would use configuration or deployment evidence to establish technical migration and retain the ticket state as a separate process fact. If the company cannot provide the necessary deployment evidence, that becomes an explicit limitation of the result. The architecture should not repair an unavailable observation by choosing a more convenient label.

Each relationship should preserve the source identifier behind it. When installation I-204 is connected to subscription S-17, the team should be able to inspect the mapping and distinguish an imported identifier from a manually reviewed match. Ambiguous candidates can be retained without merging them into one supposedly authoritative entity.

These mappings deserve tests alongside the queries. A change to a source status definition can otherwise alter the customer list without changing a single line of the agent's instructions.

Build the least expensive credible baseline

Now we can make a storage decision. If the required information already lives in a relational system and the relationships are modest, I would first test relational tables, views and recursive queries. PostgreSQL supports recursive common table expressions; following a dependency chain is not exclusively a graph-database capability.

A property graph is worth evaluating when varied relationship traversals dominate the workload and its model makes those queries easier to express and maintain. Nodes and relationships with properties, as in Neo4j's model, give us a direct representation of installations and dependency links.

RDF is worth evaluating when shared identifiers, published vocabularies and exchange with RDF-based systems are substantial requirements. RDF provides a standard triple-based data model, with SPARQL as a query language for that model. Those capabilities do not automatically supply the company's rules for technical exposure or prove that a source mapping is correct.

These are starting points for a comparison, not benchmark results. A representation does not supply the source authority or business meaning that the example depends on. I would test the same expected answers and changes against each viable design before choosing one.

Deploying all three merely to remain technology-neutral would add complexity without resolving the choice. My starting point is a baseline, a record of why the alternatives do not currently justify their cost, and the evidence that would reopen the decision. An existing enterprise platform may change the economics considerably; this fictional example is not enough to prescribe a vendor.

The same restraint applies to copying data. A materialized dependency view may be useful without moving contracts, billing transactions and operational writes into it. Every copy introduces an update obligation. Leaving data at its source avoids that copy but makes query availability and latency depend on the source.

Evaluate the decisions the architecture makes

Before scaling the import, I would assemble a small set of checked cases. It would include an indirect dependency, an unused optional integration, a genuinely completed migration and an unresolved customer identity. Each expected outcome would include the supporting reason.

The existing and proposed approaches can then be compared on those same cases. Perhaps structured retrieval with better identifiers already resolves the failures. Perhaps the difficult part is recursive dependency reasoning. Perhaps the real problem is that nobody records the installed configuration accurately enough. These findings lead to different investments.

The evaluation needs both missed exposures and unnecessary investigations. An architecture that returns every customer can avoid omissions by making the output useless. A system that drops unresolved identities may produce a reassuringly short list while hiding the work that remains.

That makes supported results, missed cases, false positives and unresolved cases separate measurements, alongside the time a reviewer spends checking them. Query speed matters, but a fast result that takes hours to verify has not completed the intended job.

An especially useful test is to change an input after the first run: withdraw a dependency, correct an identity mapping or make the deployment source unavailable. The revised result should reflect what changed and expose what is no longer known. That tests the architecture more seriously than another clean-data demonstration.

End the investigation with a decision

A good first assessment could conclude that the company needs a small dependency service backed by its existing database, explicit identity mappings and a better deployment feed. It could also conclude that a graph-oriented representation is justified, or that an existing platform already provides most of the necessary capability.

The deliverable should make that decision implementable: the agreed meaning of exposure, the source responsibilities, the minimal model, the alternatives rejected, the checked cases and the next bounded increment. There should also be a stopping condition if the required evidence cannot be obtained or the benefit does not justify the maintenance cost.

The business asked which customers are affected. Answering that question carefully has revealed the knowledge the application needs, the systems that can supply it and the uncertainty that remains. That is enough to start building something useful without committing to a program to model the entire company.

This is the kind of bounded decision a knowledge architecture assessment can investigate.

Sources and scope · 18 September 2026

• Noy and McGuinness, Ontology Development 101, on scope and competency questions.
• PostgreSQL documentation, WITH Queries, including recursive queries.
• Neo4j documentation, Graph database concepts.
• W3C, RDF 1.1 Concepts and Abstract Syntax. Cited for the established RDF data model, not as a claim about the latest standards revision.
• W3C, SPARQL 1.1 Query Language. Cited for established query capabilities, not latest-version status.
• The service-retirement scenario is a worked example, not a client case study. The comparison table lists starting points, not benchmark results.

New articles and talks.

Occasional emails when I publish an article or have a talk to share. No weekly schedule.

Email address

Subscribe

By subscribing, you agree to receive these emails from Markus Nissl Consulting. You can unsubscribe at any time. See the Privacy Policy for how your information is handled. Email delivery is provided by Brevo.