Model Viewpoints
This page explains how the knowledge domain can support multiple viewpoints without fragmenting the underlying truth structure. It is not one single flat diagram. The drawio source contains multiple pages, and each of them matters in a different way:
- Page 1 — Classic: a more traditional viewpoint map showing architecture disciplines and perspective families distributed across the Social, Business, Service, Application, Data, Deployment, and Infrastructure domain stack
- Page 2 — Future: a more operational and productized view showing how catalogs, automation, provisioning, relationship management, and mission alignment become explicit projection surfaces over that same domain stack
So this page should be read in two passes:
- first as a classic architecture-and-perspective map
- then as a future operating/projection model
Intro
The viewpoints model matters because organisations are never understood from only one angle. Different people ask different questions. Different roles need different surfaces. Different frameworks emphasise different structures. Different decisions require different forms of interpretation.
That is why this page is useful. It explains how one shared semantic foundation can support multiple consumable views without forcing the organisation to maintain a different canonical model for each audience, framework, or task.
Page 1 — Classic
The first page is the more traditional viewpoint map. It should be read as a perspective structure layered across the main domain stack:
- Social
- Business
- Service
- Application
- Data
- Deployment
- Infrastructure
What Page 1 is trying to do
This page is not mainly about user-interface screens. It is about the kinds of architecture and conceptual perspectives people use to interpret different parts of the shared model.
Visible examples include:
- conceptual architecture
- logical architecture
- capability architecture
- process architecture
- functions architecture
- service architecture
- application architecture
- data architecture
- platform architecture
- physical architecture
- deployment architecture
- integration architecture
- analytics architecture
- content architecture
- UX architecture
- leader architecture
Why Page 1 matters
This page makes a strong architectural point:
the same underlying domain stack can support many different architecture-style readings.
That matters because organisations often drift into maintaining separate disconnected models for:
- business capability
- process
- service design
- application architecture
- data architecture
- physical/runtime architecture
- user experience
- analytics
Page 1 argues for a better pattern:
- keep the domain stack shared
- derive viewpoint families over it
- let each viewpoint emphasize what matters for its audience without becoming a separate truth system
The deeper reading of Page 1
The first page is best read as a discipline map of legitimate projections. It is not saying that each architecture label is a separate ontology. It is saying that the organisation needs multiple disciplined ways to interpret the same underlying reality.
So the stronger reading is:
- the ontology remains canonical underneath
- these architecture forms are derived readings of the stack
- each perspective highlights specific concerns and suppresses others
- semantic continuity has to be preserved across them
Page 2 — Future
The second page shifts from architecture labels toward more operational and productized viewpoint surfaces. It still sits over the same main domain stack, but the viewpoint forms become much more concrete.
What Page 2 is trying to do
This page appears to introduce more concrete projection and operating surfaces such as:
- component catalog
- experience catalog
- code generation
- automated deployment
- automated configuration
- automated provisioning
- relationship management
- mission alignment
That is a major shift in tone. The page is no longer just naming architecture disciplines. It is showing how viewpoints can become actionable products, catalogs, automations, and operating surfaces.
Why Page 2 matters
This page matters because it pushes the viewpoint idea into a future-facing operational direction. It suggests that viewpoints are not only for human interpretation. They can also become:
- catalogs
- guided model surfaces
- configuration and automation inputs
- generation surfaces
- alignment and management tools
That is a much stronger claim than “different people like different diagrams.” It says viewpoints can become a real operating architecture built on top of canonical semantics.
The deeper reading of Page 2
The second page suggests a model where the shared ontology can drive or support:
- reusable catalogs
- semi-structured experience layers
- automation pathways
- configuration surfaces
- mission/strategy alignment views
- relationship-management projections
So the stronger architectural reading is:
- viewpoints are not only passive representations
- they can be productive surfaces that feed execution, provisioning, generation, and coordination
- the canonical model needs enough semantic strength underneath to support that safely
Why the viewpoints model matters
The viewpoints model exists to make a shared knowledge foundation usable across many kinds of organisational work. A canonical ontology is valuable, but it is not enough on its own. People do not work by staring directly at one giant underlying model. They work through specific questions, role-specific concerns, framework lenses, decision contexts, and operating surfaces.
That is why viewpoints matter. They allow the organisation to preserve one underlying truth structure while still producing many different interpretive and operational experiences.
So the viewpoints model is best read as:
- a way to support multiple legitimate readings of the same underlying reality
- a way to let different roles consume the model without fragmenting it
- a way to derive framework views without making those frameworks canonical
- a way to connect shared meaning to tailored experiences, dashboards, canvases, catalogs, and decision surfaces
The high-level viewpoints idea
The basic architectural idea is simple:
- the ontology remains canonical
- viewpoints are derived or projected from that ontology
- different audiences need different structures of interpretation
- one shared model can support many lenses if the projection discipline is strong enough
That is what prevents the organisation from falling into the familiar trap of maintaining separate disconnected truths for architecture, governance, strategy, service design, customer understanding, delivery, and performance review.
How viewpoints should be understood
A viewpoint is not just a different opinion. It is a structured way of looking at the same underlying organisational reality.
That means a viewpoint usually does at least one of the following:
- emphasises a specific concern
- suppresses detail that is irrelevant for a given audience
- groups information differently to support a particular task
- translates shared semantics into a framework or work pattern people already know
- presents the same underlying domain through a more useful experience surface
- exposes the same domain as a catalog, automation surface, or guided operational product
So a viewpoint should not be treated as a rival model. It should be treated as a disciplined projection over the canonical model.
Viewpoints and collaboration
This page is the companion to Model Collaboration.
If collaboration explains how different roles contribute into the shared model, viewpoints explains how different users, teams, frameworks, and applications consume, navigate, and interpret that same model.
That is why these two pages belong together. A shared ontology-backed system does not succeed just because many people can contribute to it. It also has to produce role-appropriate experiences that make the shared model usable.
So the deeper pattern is:
- collaboration creates structured contribution into the canonical model
- viewpoints create structured consumption, interpretation, projection, and sometimes operational productization over the canonical model
That is how one underlying semantic foundation can support many organisational experiences without fragmenting truth.
The main kinds of variation viewpoints need to support
Different questions require different perspectives. Some views are more internal. Some are more external. Some are more about outcomes. Some are more about activity. Some are more about structure. Some are more about experience. Some are more about automation and operating surfaces.
A strong ontology-backed system should support these variations without requiring a new underlying model each time.
That means the viewpoints model needs to support differences such as:
- internal versus external focus
- strategic versus operational focus
- outcome-oriented versus activity-oriented interpretation
- design-time versus runtime understanding
- governance, service, architecture, product, or customer lenses
- expert versus simplified consumable views
- human-facing versus automation-facing projections
Review perspectives from the source material
The original material identifies a useful spread of tools and perspectives that can be used to review or interpret organisational information.
| Tool / Perspective | Internal | External | Outcome | Activity |
|---|---|---|---|---|
| Balanced scorecards | x | x | ||
| Value chain | x | x | ||
| Hoshin Kanri | x | x | ||
| Business Model Canvas | x | x | x | |
| Business Motivation Model | x | x | x | |
| Design thinking | x | x | ||
| Customer journey map | x | x | ||
| SWOT analysis | x | |||
| Storytelling and communication design | x | x | ||
| Brand and content design | x | x | ||
| Experience and interaction design | x | x | ||
| Business design and models | x | x | x | |
| Product and service design | x | x | x | |
| Process and operating model | x | x | ||
| Organisation and ways of working | x | x | x |
What this list really means
This list matters because it reinforces a key architectural point:
the same underlying organisational reality can be interpreted through many different frameworks and perspectives.
That fits directly with the broader position that:
- the ontology is canonical
- frameworks are views or translations
- different audiences need different surfaces
- the same underlying knowledge can support more than one interpretation layer
So the point is not that all of these tools are equally foundational. The point is that they expose different view logics over shared structure.
Why frameworks should remain viewpoints, not the canonical model
This page is one of the clearest examples of why frameworks should not become the underlying storage model.
A Business Model Canvas, a value chain, a balanced scorecard, a customer journey map, or a TOGAF-style architecture view may all be useful. But they should be understood as viewpoints over the organisation, not as the ontological foundation of the organisation itself.
That distinction matters because if the framework becomes canonical, the organisation becomes trapped inside the assumptions and blind spots of that framework. If the ontology remains canonical, the organisation can support multiple frameworks, change its preferred lenses over time, and still preserve semantic continuity.
How viewpoints relate to experiences, apps, and systems
A viewpoint is not only a conceptual interpretation. It often needs to appear through a concrete experience.
That means viewpoints may be realised through things like:
- dashboards
- canvases
- workspaces
- role-specific apps
- reporting surfaces
- review tools
- guided workflows
- framework-oriented views
- catalogs
- configuration surfaces
- generation surfaces
- automation-supporting products
This is important because people usually do not consume ontology directly. They consume experiences built on top of structured knowledge. So the viewpoints model is one of the key bridges between the canonical ontology and the actual systems people use.
Why this matters for agents
Agents should be able to work from the canonical ontology while still supporting multiple viewpoints such as:
- governance
- architecture
- service design
- business model analysis
- operational review
- customer experience analysis
- catalog generation
- configuration assistance
- deployment and provisioning support
That means the ontology needs enough structure to support translation into different lenses without losing semantic continuity. It also means agents need to know when they are operating on the canonical model versus when they are generating a viewpoint-specific interpretation, summary, projection, or automation surface.
What a strong viewpoints model needs to preserve
A strong viewpoints model should preserve at least six things:
1. semantic continuity
A viewpoint should remain traceable back to the underlying canonical model. It should not introduce silent meaning drift.
2. projection discipline
A viewpoint should make clear what it highlights, suppresses, groups, or translates. That way the reader can understand what kind of view they are looking at.
3. role relevance
A viewpoint should exist because it helps a real audience do real work. It should not be a decorative alternative rendering.
4. framework portability
The system should be able to support multiple framework-style views without turning any one framework into the permanent semantic container.
5. experience usability
A viewpoint should be consumable through experiences that make sense to the people or agents using it. That may mean reports, canvases, apps, dashboards, maps, or guided review surfaces.
6. operational productization
Some viewpoints should be able to become productive surfaces for things like catalogs, generation, provisioning, configuration, and alignment workflows.
The biggest risk this model helps avoid
Without viewpoint discipline, organisations tend to fragment their knowledge into separate framework silos. Architecture teams build one picture. Strategy teams build another. Operations teams build another. Customer teams build another. Data teams build another.
Each may be individually useful. But over time they drift, duplicate one another, contradict one another, and become difficult to reconcile.
The viewpoints model is one of the main ways to avoid that. It says:
keep the semantic core shared, then derive the different views from it.
That is a much stronger architectural position than trying to realign disconnected models after they have already diverged.
Why this matters for the broader Knowledge Ontology
The broader Knowledge Ontology is not trying to produce one monolithic reading surface. It is trying to create a semantic foundation that can support many forms of organisational interpretation, review, design, governance, action, and eventually automation.
That is why viewpoints matter so much. They are the mechanism by which one shared model becomes widely usable without losing coherence.
What the full multi-page viewpoints diagram set collectively implies
Taken together, the two pages imply that the viewpoints domain is doing two related but distinct jobs:
- defining the classic architecture and perspective families that can read the shared domain stack
- defining a more future-facing operating model in which viewpoints become catalogs, generation surfaces, automation paths, and alignment products
That is a strong signal. It says viewpoints are not just passive visual slices. They are part of the real architecture of how the ontology becomes usable.
So the deeper pattern here is:
- Page 1 gives the classic perspective/architecture reading of the stack
- Page 2 gives the future productized/operational reading of the stack
Next direction for this page
The next evolution of this page should make the viewpoints semantics more explicit around:
- viewpoint types and their projection rules
- how viewpoints differ from collaboration surfaces
- which viewpoints are framework-based versus role-based versus task-based
- which viewpoints are human-consumption views versus operational product surfaces
- how catalogs, generation, provisioning, and alignment surfaces should relate back to the canonical ontology
- how viewpoint outputs remain traceable back to the canonical ontology
