Choosing Architectural Perspectives

As a Data Architect, most of the disagreements you'll be asked to resolve won't be about technology at all. They'll be about meaning: two teams using the same word for different things, or arguing about structure when they haven't yet agreed what they're structuring. This course gives you the conceptual tools to spot those disagreements early and hold the line until they're settled.

In this lesson, you will learn to:

• Distinguish conceptual, logical, and physical views by the concern each one serves
• Decode how product, analytics, governance, platform, and domain stakeholders frame the same information need
• Select the perspective and evidence a conversation needs before proposing a solution

This first unit is about perspective: recognizing that a single architecture can be described in several valid ways, and that choosing the wrong one for the conversation in front of you wastes everyone's time.

The Conceptual-Logical-Physical layering comes from three-schema architecture, and its power comes from the order. The conceptual view answers what the business means and which entities it genuinely cares about: what is a customer, what is a subscription, what counts as a churn event. The logical view answers how those things are structured and related, and what rules hold between them, independent of technology. The physical view answers which realized technology choices implement that structure.

Each layer serves a different concern, and that is the point. A logical view cannot settle whether a lapsed payer is a churned customer, because that is a question of meaning, not structure. A conceptual view cannot tell a platform lead how much storage to provision. When a conversation stalls, it is often because someone is answering a conceptual question with physical evidence.

The layering also has a direction of dependency. If the conceptual view is unsettled, anything built on top of it is provisional. You can draw a logical structure for "customer" while three teams still disagree about what a customer is, and that disagreement will reappear later as a trust problem in a reported figure.

Watch how this plays out in a real exchange on a churn project. Nova, a product analyst, wants the logical structure; Dan, a platform engineer, wants the physical sizing; Natalie, the data architect facilitating the meeting, is listening for which layer the conversation actually needs first:

• Nova: Can you just show me a diagram of how the churn data will be connected?
• Dan: And I need the refresh cadence so I can size the environment.
• Natalie: Both fair, but hold on. Nova, when you say a customer has churned, does that include someone who's stopped paying but still has access?
• Nova: I'd say yes. Though billing would say no, they'd call that a lapsed payer.
• Natalie: Then we don't have a structure question yet, we have a meaning question. Dan, your sizing depends on how many rows that definition produces, so it moves with it.
• Dan: Fine. But I need a date when that's settled.

Notice what Natalie does: she doesn't refuse the structural or physical requests, she shows why they're downstream of an unresolved conceptual one.

The same information need arrives in five incompatible languages. Use the table to separate each speaker's surface request from the concern and architectural lens beneath it.

Your job is to separate the concern from the proposed solution. Stakeholders rarely state a concern directly; they state the thing they imagine would resolve it. "Give me the refresh cadence" is a solution shape. The concern underneath is capacity and operational feasibility. Naming the concern beneath the wording is the analysis; restating the wording is not.

Crucially, no single lens handles all five. Governance's consent question and platform's sizing question cannot be answered by the same view, and neither can be answered at all until the conceptual disagreement about what counts as a churned customer is settled.

This is where the Stakeholders → Concerns → Viewpoint → View pattern (from ISO/IEC/IEEE 42010) earns its keep. You name who is in the room and what each of them actually cares about, and only then do you select the viewpoint (the lens) and produce the view (what that lens shows). For a concrete pairing: the conceptual definition viewpoint is the lens, and the view it produces is the churn-definition model with its edge cases and domain exceptions. Choosing the lens first is the most common failure in early architecture practice, and it usually shows up as a meeting where everyone talks past each other with slides that answer nobody's question.

Facilitating well means saying out loud what perspective the session is operating at, and what evidence would count as an answer at that level. If the session is conceptual, the admissible evidence is definitions, examples, edge cases, and disagreements between domains. Data models, refresh schedules, and vendor comparisons are not evidence at that level, and allowing them in is how conceptual questions get quietly decided by whoever controls the tooling.

Equally important is naming the decisions nobody owns. If no one has been assigned authority to select a cross-quarter definition, that gap is itself an architectural finding. To name a candidate owner, look for three signals: who consumes the number for a decision, who has authority over the publishing artifact, and which domain bears the accountability when it is wrong. The person who satisfies all three is the defensible owner.

The single idea to carry forward: name the stakeholder and the concern before you pick the lens, and never let a conceptual disagreement be resolved by structural or technology evidence. Next you'll test that pattern in a couple of quick self-checks, then put it to work in a memo that decodes five conflicting stakeholder intake notes into the concerns and perspectives hiding underneath them.