Information Architecture Domain Module

Making information findable, usable, and governed.

Information Architecture is where meaning meets structure. It defines how the organisation classifies, organises, and manages information as a business asset — not the databases and pipelines (that's Data Architecture), but the business understanding of what information exists, what it means, and who should be able to access it.

Unfortunately, most organisations have information chaos dressed up as information management. The same concept has different names in different systems. Nobody knows where to find authoritative data. Classification schemes exist on paper but not in practice. Teams create their own taxonomies because the enterprise ones are either missing or unusable.

Information Architecture, done right, creates the shared vocabulary and structure that makes information accessible and governed. Done poorly, it produces glossaries nobody reads and taxonomies nobody follows.

This module provides the practical foundation for information architecture that connects business understanding to data reality.

What This Module Provides

How It Plugs Into the Governance Core

Information Architecture integrates with every component of the Governance Core:

Guardrail Framework — Information guardrails define boundaries for how information is classified, accessed, and retained. These aren't technology rules (those belong in Data Architecture) — they're business rules about information handling.

Example guardrails:

• "Customer information must be classified according to the enterprise classification model before being stored in any system"
• "All information assets must have an assigned information steward"
• "Master data entities must be sourced from designated authoritative systems"

Tiered Oversight — Information decisions vary in impact:

Decision Records — Information decisions need documentation. When you decide how to classify a new information type, which system becomes authoritative for customer data, or how long to retain project records — these decisions affect many teams and need to be traceable.

Key decisions to record:

• Classification model changes
• Authoritative source designations
• Retention period determinations
• Access boundary definitions
• Glossary term arbitration

Architecture Passport — Every system's passport should include information architecture context: what information it holds, its classification, whether it's authoritative for any master data, and what information flows in and out.

Technical Debt Register — Information debt is real. Systems without proper classification. Duplicate master data across sources. Inconsistent terminology that nobody's had time to reconcile. This debt needs visibility — it affects data quality, reporting accuracy, and AI readiness.

Delivery Integration — Information architecture questions should surface during delivery:

• Sprint planning: "What new information types does this feature create?"
• Design reviews: "Does this align with our master data strategy?"
• Definition of Done: "Has the information classification been applied?"

Architecture Registry — This module populates the information layer of your registry: classifications, glossary terms, information assets, flows, and the relationships between them.

Core Artefacts

Information Classification Model

An Information Classification Model provides a consistent approach to categorising information for governance and discoverability. This isn't security classification (that's Security Architecture's domain) — it's business classification that helps people find, understand, and appropriately manage information.

Why it matters: Without classification, information is ungoverned. You can't apply consistent retention rules to information you haven't categorised. You can't manage access to information you haven't typed. You can't find information that isn't organised. Classification creates the foundation for everything else.

Important distinction: Information classification and security classification are related but different concerns:

Your Information Classification Model should integrate with Security's classification — they tag the same information from different perspectives.

Classification Dimensions:

Information can be classified along multiple dimensions. Choose the dimensions that add value for your organisation:

AI Readiness Consideration: Well-classified information becomes dramatically more useful for AI applications. When information is consistently categorised and tagged, it's ready for retrieval-augmented generation (RAG), knowledge graphs, and intelligent search. Organisations with chaotic classification struggle to get value from AI investments because their information isn't structured for machine consumption.

Framework Reference: DMBOK (Data Management Body of Knowledge) provides comprehensive guidance on data classification and categorisation.

Taxonomy & Controlled Vocabularies

A taxonomy provides the hierarchical structure for organising information. Controlled vocabularies provide the specific terms allowed within that structure. Together, they create consistency in how information is labelled, tagged, and found.

Why it matters: Without controlled vocabulary, you get chaos. The same concept gets tagged as "Client", "Customer", "Account Holder", and "Consumer" across different systems. Search fails because nobody uses the same terms. Reporting aggregates incorrectly because categories don't align. AI hallucinates because it can't reconcile inconsistent terminology.

The problem with organic vocabularies: Every team develops its own shorthand. What Finance calls "revenue recognition" might be "income booking" in Sales and "money in" in casual conversation. This works within teams but breaks down across the organisation. The taxonomy provides the translation layer.

Taxonomy Structure:

Organisation Taxonomy (example)
├── Customer Information
│   ├── Customer Profile
│   │   ├── Contact Details
│   │   ├── Preferences
│   │   └── History
│   ├── Customer Transactions
│   │   ├── Orders
│   │   ├── Returns
│   │   └── Payments
│   └── Customer Communications
│       ├── Correspondence
│       ├── Support Tickets
│       └── Marketing Consent
├── Product Information
│   ├── Product Catalogue
│   ├── Pricing
│   └── Inventory
└── [...]

Controlled Vocabulary Governance:

Vocabularies need active management. Without governance:

• Teams add terms without checking if equivalent terms exist
• Synonyms proliferate (the same thing with different names)
• Homonyms cause confusion (the same name for different things)
• Deprecated terms persist forever

Vocabulary Governance Model:

AI Consideration: Your taxonomy directly affects AI performance. When building retrieval-augmented generation (RAG) systems or enterprise search, the taxonomy determines how content is chunked, indexed, and retrieved. A well-designed taxonomy means AI can find the right information. A poorly designed one means relevant content gets missed.

When to say "no" to new terms:

• A synonym already exists — use the standard term
• The term is too granular — aggregate to existing category
• The term is too broad — decompose into existing categories
• The term is temporary — not worth adding to permanent vocabulary

Records Management Integration: If your organisation has records management requirements (most government agencies do), your taxonomy should align with your records classification scheme. In Queensland, this means alignment with the General Retention and Disposal Schedule (GRDS) or your agency's specific schedule. The National Archives of Australia provides guidance on records classification that applies across Australian government.

Business Glossary

A Business Glossary provides authoritative definitions for business terms. Not technical definitions (those belong with Data Architecture), but business meaning — what does "customer" actually mean in this organisation?

Why it matters: Arguments about data often trace back to definitional disagreements. One report says you have 50,000 customers, another says 73,000. Neither is wrong — they're using different definitions of "customer." The glossary resolves these disputes before they start.

The glossary isn't a dictionary. It's not about defining common words. It's about establishing authoritative meaning for terms where ambiguity causes problems. If everyone agrees on what "revenue" means, don't define it. If Finance and Sales have a running argument about whether refunds reduce revenue or represent a separate line item, define it.

Glossary Entry Structure:

The "Exclusions" field matters. Half the arguments about definitions are actually about boundaries. Does "customer" include prospects? Former customers? Internal departments who consume services? The exclusions clarify the edges.

Glossary Governance:

• Don't try to define everything at once. Start with terms that cause active confusion. Add terms as disputes arise.
• Stewardship is essential. Every term needs an owner who can arbitrate disputes and approve changes.
• Connect to data. Glossary terms should link to the data elements that implement them. "Customer" the business concept should map to the technical fields that store customer data.

Term: Active Customer

Definition: A customer who has completed at least one transaction 
within the last 24 months and has not requested account closure.

Context: This definition applies to customer counts in management 
reporting, marketing campaign targeting, and service level 
calculations. Product-specific definitions may vary.

Synonyms: Current Customer

Related Terms: Customer, Inactive Customer, Prospect, Churned Customer

Steward: Customer Data Steward (Marketing)

Source: Customer Data Governance Committee, Decision Record DR-2024-042

Examples: 
- Customer who purchased in June 2024 → Active (within 24 months)
- Customer whose last purchase was March 2022 → Inactive (>24 months)
- Customer who purchased in 2024 then requested account closure → Not Active

Exclusions:
- Prospects (no completed transaction)
- Former customers (account closed or >24 months inactive)
- Staff accounts (internal, excluded from customer counts)
- Test accounts

AI Content Governance: As AI-generated content becomes more common, your glossary becomes increasingly important. AI tends to use terms loosely unless constrained. A glossary integrated into AI systems ensures generated content uses terminology correctly. Consider adding fields for "AI usage guidance" where definitions need particular precision for machine consumption.

Information Lifecycle Framework

Information has a lifecycle: it's created, used, potentially modified, archived, and eventually disposed of. A lifecycle framework ensures information is managed appropriately at each stage — available when needed, protected while relevant, and disposed of when required.

Why it matters: Without lifecycle management, organisations keep everything forever (legal and storage risk) or dispose of things too soon (compliance and operational risk). They struggle to find current information because it's buried in obsolete content. And they waste resources storing and protecting information that should have been destroyed years ago.

Lifecycle Stages:

Retention isn't just "keep it." Retention rules must address:

• Minimum retention: How long must we keep this? (Legal, regulatory, business need)
• Maximum retention: When should we dispose of this? (Privacy, risk, efficiency)
• Trigger events: What starts the retention clock?
• Legal holds: How do we suspend disposal when litigation is pending?

Lifecycle Integration with Systems:

Information lifecycle must be enforced in systems, not just documented in policies. This means:

• Automated classification prompts at creation
• Metadata capture as part of workflows
• Automated retention enforcement
• Disposal workflows with appropriate approvals
• Audit trails for lifecycle actions

AI Training Data Consideration: The lifecycle framework should address AI-specific concerns:

• Can this information be used for AI training? (Consent, licensing, sensitivity)
• When AI models are trained on organisational data, what retention applies to the training data vs. the model?
• What happens to AI-generated content — does it follow the lifecycle of its sources?

Records Management Alignment: For organisations with formal records management requirements, the lifecycle framework must align with your Records Authority or Disposal Schedule. In Australia, this means compliance with the Archives Act 1983 (for Commonwealth) or state equivalents. The National Archives of Australia provides guidance on records lifecycle management.

Metadata Standards

Metadata is information about information. A metadata framework defines what metadata is captured, how it's structured, and how it's used to make information manageable.

Why it matters: Information without metadata is information you can't find, govern, or trust. When did this document get created? Who approved it? Is it current? What classification applies? Metadata answers these questions at scale.

Metadata Categories:

The minimum viable metadata set:

Not every piece of information needs exhaustive metadata. But certain fields should be non-negotiable:

Metadata Quality:

Metadata is only useful if it's accurate and complete. This requires:

• Automated capture where possible — system-generated metadata is more reliable than human-entered
• Mandatory fields enforced — don't allow saving without required metadata
• Validation rules — reject invalid values
• Regular auditing — check metadata completeness and accuracy

AI-Enhanced Metadata:

AI can assist with metadata management:

• Automated classification suggestions based on content analysis
• Auto-tagging against controlled vocabularies
• Extraction of entities, dates, and relationships from unstructured content
• Quality scoring to identify poorly-documented information

But AI-generated metadata needs human oversight. False confidence in automated classification can create governance gaps.

Information Flow Maps

Information Flow Maps document how information moves through the organisation — where it originates, where it's transformed, where it's consumed, and what happens along the way.

Why it matters: You can't govern what you can't see. Information flows across systems, teams, and organisational boundaries. Without visibility into these flows, you can't ensure consistency, identify gaps, or manage risk. When something goes wrong (data breach, quality issue, compliance failure), flow maps help you understand impact and trace root cause.

Flow Map Elements:

Levels of Detail:

Information flows can be mapped at different levels:

• Enterprise level — major information domains flowing between business areas
• Domain level — flows within and across specific information domains
• System level — technical data flows between applications (often owned by Data/Technology Architecture)

Information Architecture typically focuses on enterprise and domain levels, with linkage to technical flows managed by Data Architecture.

                    ┌─────────────┐
                    │   Website   │
                    │  (capture)  │
                    └──────┬──────┘
                           │
                           ▼
┌──────────────┐    ┌─────────────┐    ┌──────────────┐
│  Call Centre │───▶│     CRM     │───▶│   Data       │
│   (capture)  │    │ (master)    │    │   Warehouse  │
└──────────────┘    └──────┬──────┘    └──────────────┘
                           │
                           ▼
                    ┌─────────────┐
                    │  Marketing  │
                    │  Platform   │
                    └─────────────┘

Flow Documentation:

For each significant flow, document:

• Business purpose (why does this flow exist?)
• Information content (what's being transferred?)
• Quality requirements (accuracy, timeliness, completeness)
• Security requirements (protection during transit)
• Failure handling (what happens when it breaks?)
• Dependencies (what else relies on this flow?)

Master Data Concepts

Master Data represents the core business entities that need consistent, authoritative representation across the organisation — customers, products, employees, locations, suppliers. Master Data Concepts define the business perspective on these entities.

Why it matters: When the same entity is represented differently in every system, chaos follows. Five systems, five different customer records, five different addresses. Reports don't reconcile. Customer experience suffers. Compliance becomes impossible to demonstrate.

This is the business view, not the technical implementation. Information Architecture defines what master data means and why it matters. Data Architecture (a separate module) addresses the technical implementation — MDM platforms, data hubs, matching algorithms.

Key Master Data Questions:

Common Master Data Domains:

• Party — customers, employees, suppliers, partners, contacts
• Product — products, services, offerings
• Location — addresses, sites, regions, territories
• Organisation — business units, cost centres, legal entities
• Reference Data — codes, lookups, classifications that support master data

Authoritative Source Designation:

For each master data domain, designate the authoritative source — the "golden record" system. This decision has significant implications:

• All other systems should consume from or sync to the authoritative source
• Data quality investment focuses on the authoritative source
• When conflicts exist, the authoritative source wins

Document this decision: Authoritative source designation is a significant decision that affects many teams. Use a Decision Record.

Master Data Governance:

Master data needs governance because it crosses organisational boundaries. A single customer exists across Sales, Service, Finance, and Marketing. Changes in one area affect all areas.

Governance model elements:

Internal Access Boundaries

Internal Access Boundaries define who can access what information within the organisation — not from a security controls perspective (that's Security Architecture), but from an information governance perspective. What information should be available to which roles, teams, or functions?

Why it matters: Not everyone needs access to everything. Sales doesn't need HR performance data. Junior staff don't need board papers. External contractors shouldn't see internal strategy documents. Access boundaries ensure information is available to those who need it while protected from those who don't.

The difference from security access controls:

Information Architecture defines the requirements. Security Architecture implements the controls.

Access Boundary Dimensions:

Common Boundary Patterns:

• Hierarchical — each level sees their level plus below
• Functional — each function sees their function's data
• Geographic — each region sees their region's data
• Chinese wall — certain combinations of access prohibited (compliance, conflict of interest)
• Aggregated only — individuals can see summaries but not details

Privacy Integration: Access boundaries must respect privacy requirements. In Australia, this means alignment with the Australian Privacy Principles (APPs) for personal information. Note that detailed privacy implementation is Security Architecture's domain — Information Architecture ensures the boundaries are defined to enable compliant implementation.

Integration with Other Domain Modules

Information Architecture shapes and is shaped by every other domain:

The Information-Data Relationship:

Information Architecture and Data Architecture are complementary:

• Information Architecture = business meaning, classification, governance, access intent
• Data Architecture = technical implementation, storage, pipelines, quality management

A business term in the glossary maps to technical fields in the data dictionary. Information flows map to data pipelines. Master data concepts become MDM implementations. Classification models drive database security.

Keep them aligned but don't conflate them. Business users care about information. Technical teams implement data. The architecture bridges both.

Populating the Architecture Registry

This module provides the content that populates the information layer of your Architecture Registry. If you've established the registry structure from the Governance Core but have empty information architecture sections, this is where the content comes from.

What goes in the registry:

Relationship integrity: The power of the registry comes from relationships. Every information asset should link to its classification. Every glossary term should link to the systems where it's implemented. Every flow should link to source and destination assets. Without these relationships, you have lists instead of architecture.

Anti-Patterns to Avoid

The Glossary Graveyard

Symptoms: Created a comprehensive glossary. Nobody uses it. Definitions are outdated. When disputes arise, nobody checks the glossary.

Root cause: Built in isolation from business processes. No integration with systems. No governance to keep it current.

Fix: Start small with contentious terms. Integrate glossary into systems where terms are used. Assign stewardship. Review regularly.

Taxonomy by Committee

Symptoms: Taxonomy design involves every stakeholder. Compromises create a structure nobody likes. Takes forever to finalise. Changes require re-negotiating with everyone.

Root cause: Treating taxonomy as democracy rather than architecture.

Fix: Establish clear ownership. Use principles to guide structure. Consult stakeholders but don't require consensus. Make it easy to evolve.

Classification Without Consequence

Symptoms: Classification model exists. Systems don't enforce it. Users ignore it. No difference between classified and unclassified information.

Root cause: Classification is documentation, not governance.

Fix: Connect classification to actual controls — retention, access, handling. Make classification meaningful by attaching consequences.

Master Data Without Mastery

Symptoms: Designated authoritative sources. Other systems ignore them. Duplicates persist. Quality issues in "authoritative" source.

Root cause: Designation without enforcement. No investment in source quality. No consequence for using alternatives.

Fix: Enforce consumption from authoritative sources. Invest in source quality. Make the right path the easy path.

The Perfect Metadata Schema

Symptoms: Comprehensive metadata schema with 50+ fields. Users fill in three. Most fields empty or wrong.

Root cause: Designed for comprehensiveness rather than usability.

Fix: Minimum viable metadata that's actually captured. Automate what you can. Add fields when there's genuine need and capacity.

Metrics That Matter

Getting Started

If you're establishing Information Architecture capability for the first time, don't try to cover everything at once.

Week 1-2: Minimum Viable Foundation

1. Identify your top 5 contentious terms — Which business terms cause arguments? Define those first.

2. Draft basic classification categories — Even a simple list: Customer Information, Employee Information, Financial Information, Operational Information.

3. Map one critical information flow — Pick your most important or problematic information flow and document it end-to-end.

4. Designate one authoritative source — For your most duplicated master data, which system is authoritative? Document that decision.

5. Establish one information steward — Someone needs to own information governance, even if part-time. Start with one domain.

Month 1-2: Build Core Structures

1. Expand glossary to top 20 terms — Add terms as disputes arise, don't try to be comprehensive.

2. Develop classification model — Move from simple categories to a structured model with multiple dimensions.

3. Define metadata standards — What must be captured for all information assets?

4. Map additional information flows — Cover your highest-risk and highest-value flows.

5. Document master data domains — What are your core entities? What's authoritative for each?

6. Define initial access boundaries — For sensitive information categories, who should access?

Quarter 1-2: Scale and Integrate

1. Integrate with systems — Classification enforced in key systems. Glossary embedded in reporting tools.

2. Establish governance cadence — Regular stewardship reviews. Glossary update process.

3. Connect to delivery — Information architecture review in project methodology.

4. AI readiness assessment — Evaluate information structure for AI consumption.

5. Full flow mapping — Comprehensive view of enterprise information flows.

6. Maturity assessment — Where are you strong? Where are the gaps?

Roles and Responsibilities

Information Architecture doesn't require a dedicated Information Architect role to start — but someone needs to own the artefacts and coordinate governance.

Scaling guidance:

Tooling Options

The artefacts in this module can live in various tools depending on your maturity and budget:

Don't let tooling block progress. A well-maintained spreadsheet beats an unused enterprise tool. Start simple, upgrade when the simple approach becomes limiting.

The Bottom Line

Information Architecture creates the shared understanding that makes information usable. Without it, you have data scattered across systems with inconsistent meaning, unclear ownership, and unmanaged access. With it, you have information that's findable, governed, and ready for whatever comes next — including AI.

Start with what's causing pain: the terms people argue about, the flows that break, the data nobody trusts. Build from there.

The goal isn't perfect documentation. It's information that works for the organisation.

XAF Connected Architecture | Developed by InnovateX Solutions