TL;DR - Overview
Choosing the wrong Azure messaging service can lead to reliability, performance and scalability issues once applications reach production. This guide explains the differences between Azure Event Grid, Event Hubs and Service Bus, helping you choose the right service for notifications, streaming data and business workflows.
Introduction
A recent LinkedIn article by Marcel Broschk on designing a knowledge hub architecture in Microsoft 365 really caught my attention. His visual breakdown of the common enterprise knowledge problem – information scattered across shared drives, emails, Teams chats, long-term employee memory, and disconnected SharePoint sites — captures something I see repeatedly in customer engagements.
Most organisations do not have a technology problem at first. They have a knowledge problem.
The information exists somewhere. Someone probably documented it. Someone else probably remembers who wrote it. Another person may know which Teams chat contains the real answer. But for the average employee trying to complete a task, onboard into a role, follow the right process, or answer a client question, that knowledge may as well not exist.
This is where the idea of a Microsoft 365 knowledge hub becomes powerful. But I would take the conversation one step further.
A knowledge hub is not only about where knowledge lives. It is also about whether that knowledge is accurate, current, consistent, searchable, reusable, governed, and trusted. Because if the content quality is poor, the hub simply becomes a better-looking version of the same mess.
Knowledge exists, but it is not operationalised
In many organisations, knowledge is produced as a by-product of day-to-day work rather than being deliberately managed.
It often shows up in familiar ways:
- A project team creates a lessons learned document.
- A process owner writes a how-to guide.
- The same question is answered repeatedly in Teams.
- A senior employee knows the “real” onboarding steps, but they were never formally documented.
- A business unit keeps templates in a shared drive simply because that is where they have always lived.
Individually, none of these behaviours is necessarily a problem. Over time, however, they create a fragmented knowledge landscape that makes information harder to find, trust, and reuse.
You end up with:
- Multiple versions of the same process
- Documents with no clear owner
- Outdated guidance still appearing in search
- Critical information buried in Teams conversations
- SharePoint sites created with no consistent structure
- Business users relying on “who knows what” instead of “where is the trusted source”
- Copilot or search surfacing content that technically exists but may not be authoritative
Microsoft’s own SharePoint information architecture guidance makes the same point from an architectural perspective: effective information architecture depends on how content is organised, labelled, navigated, searched, and governed across the tenant. It is not only about creating sites; it is about helping users find what they need in a way that supports their work.
That is why I think the knowledge hub conversation matters so much now, especially with Microsoft 365 Copilot becoming part of the workplace.
Copilot does not magically fix poor knowledge management. In many cases, it exposes it.
This is where many organisations go wrong.
When they hear the term “knowledge hub,” the first response is often: “Great, let’s create a SharePoint site and move documents into it.” That may be a useful first step, but it is not the solution on its own.
A true knowledge hub should be a governed entry point to trusted organisational knowledge. It should make it easy for users to answer questions such as:
- What is the approved way to do this?
- Which template should I use?
- Who owns this process?
- When was this last reviewed?
- Is this guidance still current?
- What has changed recently?
- Which business unit does this apply to?
- Is this the official source, or just someone’s working notes?
In Microsoft 365, this usually means combining several layers:
Layer | Purpose |
SharePoint hub sites | Organise related knowledge areas and provide navigation, structure, and content roll-up |
Communication sites | Publish official, curated knowledge for broad audiences |
Team sites | Support working collaboration for teams and projects |
Metadata and content types | Make content findable, classifiable, and governable |
Help users discover content across the organisation | |
Automate classification, extraction, tagging, and document processing where appropriate | |
Apply retention, sensitivity, compliance, and audit controls | |
Surface and reason over accessible organisational knowledge, where permissions and content quality allow |
Why hub sites matter
SharePoint hub sites play a critical role because they connect related sites through shared navigation, consistent branding, content roll-ups, and scoped search. Microsoft recommends a modern, flat SharePoint architecture instead of deep subsite hierarchies so that each site can be managed independently while still being linked through hubs as the organisation evolves.
This provides the architectural foundation for a knowledge hub, but architecture alone does not guarantee knowledge quality.
Governance must cover content quality
This is the part of governance that often receives too little attention.
In Microsoft 365, governance discussions often focus on permissions, external sharing, retention, sensitivity labels, lifecycle, and compliance. Those controls are essential, but a knowledge hub also needs governance for the quality of the knowledge itself.
- A document can be secure and still be useless.
- A page can be compliant and still be outdated.
- A process guide can be searchable and still be unclear.
- A Copilot answer can be permission-trimmed and still be grounded in poor content.
The real question, then, is how to ensure documented knowledge is good enough to be trusted. That requires a content quality model.
What are some of the basic standards for creating a good knowledge hub?
At minimum, every knowledge asset should have standards for:
Quality Area | What Good Looks Like |
Accuracy | The content reflects the current approved process or truth |
Ownership | A named person or team is accountable for the content |
Currency | Review dates and expiry rules are defined |
Clarity | Content is written in plain language with clear steps |
Completeness | The user can act on the guidance without needing five extra conversations |
Consistency | Similar content follows the same structure and naming conventions |
Findability | Metadata, keywords, titles, and summaries support search |
Reusability | Templates, FAQs, procedures, and assets can be reused across teams |
Compliance | Retention, sensitivity, and access controls are applied correctly |
AI-readiness | Content is structured in a way that Copilot and search can interpret reliably |
This is where a knowledge hub becomes more than a repository; it becomes a managed knowledge product.
Copilot raises the standard for knowledge quality
Before Copilot, poor knowledge management was often painful but partly hidden. People worked around it by asking colleagues, searching Teams, reusing old files, or creating new versions because they could not find the approved one.
With Microsoft 365 Copilot, that standard becomes higher. Copilot draws on the content a user already has permission to access, and Microsoft’s guidance is clear: when organisational data is well governed, current, and appropriately shared, Copilot can produce more accurate, relevant, and secure responses.
That matters because Copilot is not only asking whether content is accessible. It also depends on whether that content is useful, current, and meaningful enough to ground a trustworthy response.
If an organisation has ten versions of the same policy, unclear ownership, old project artefacts, overshared SharePoint sites, and inconsistent metadata, Copilot may surface content that is technically accessible but not necessarily trusted. That is not a Copilot failure; it is a sign that the organisation’s knowledge foundation is weak.
This is why Copilot readiness should not be treated as a licensing exercise. It should be approached as a governance and information architecture challenge.
Where this goes next
If architecture and governance set the foundation, the next question is practical: how do you actually build and run a knowledge hub that stays trustworthy over time? That is what I cover in Part 2 – the operating model, the federated approach for larger organisations, a five-part quality framework, and why human ownership is the thing that makes or breaks all of it.
Stay tuned for Part 2.
Happy Reading!
Singing out,
Delaram
