Organizing a tree structure in Confluence

[Varvara K_]

Our team would like to organize all of our work into a single, central space (Confluence) that will contain the main reference information for our work. Of course, more detailed information would be links to other documents from other spaces. But we're at a costly crossroads because we don't know which perspective is best to build our vision from. We work in a variety of IT areas. We have first-line support and second-line support. We have teams like CloudOps, SysOps, NetOps, and TechOps. We work with many services. Perhaps someone has already encountered this. I'd be grateful if you could share your approaches and structure. Thank you!

[Staffan Redelius]

Hi @Varvara K_ 

This is truly a broad and interesting topic.

I would recommend to start with a inventory to get a better understanding of the scope.

• Who creates the information?
• Who consumes/uses the information?
• What format is the information in? (picture, document, pdf, database etc.)
• Where is the information stored today?

You don't need to dig deep but at least you need a healthy amount of information to start building the structure.

If you want your document structure to be relevant over time you need to organize it by something that will not change that often. For example your organization and team structure will probably change more often than your capabilities/services/products.

Another thing to consider is to organize the informaton so it can easily be shared with the group that needs to consume the information. You might want to publish the end user information on a public site or page but want to keep the System management documentation to a small group of people. 

Below is a example of how you can organize the documentation in different areas so it is easy to handle access and permissions.

The structure under the yellow "capabilities" should be fairly standardized so it is easy to find and update when changed.

"Team documentation" is normally work in progress and can be fairly unstructured. How and what is stored can be decided by the team itself

I hope this helps!

Best regards,
/Staffan

[Dave Mathijs]

Hi @Varvara K_ That's an interesting question/discussion!

You could start with a single entry point, with everything else linked outward.

For example:

IT Knowledge Hub

• Services
• Operations
• Support
• Teams & Ownership

---

Services

• Email Service
• VPN Service
• Cloud Hosting Platform
• Network Connectivity
• Identity & Access Management

Each service page contains:

• Service overview
  • What it is
  • Who it's for
• Business criticality
  • Tier
  • SLA
• How to request support
• Known issues / Knowledge Base
• Runbooks
  • Start/stop
  • Incident response
• Dependencies
  • Infrastructure
  • Vendors
  • Other services
• Links
  • Technical documentation
  • Monitoring dashboards
  • Other spaces

Operations

Process-centric, not tool-centric:

• Incident management
• Problem management
• Change management
• On-call & escalation
• Monitoring & Alerts
• Maintenance Procedures

Each page answers:

• When does the process apply?
• Who is responsible?
• What are the steps?
• What services are affected? Link back to services, not teams.

Support

First-line support needs fast answers:

• Common Issues (FAQ)
• Troubleshooting guides
• How-to articles
• Knowledge Base (KB)
• Templates

Link a support article to exactly one service

Teams & Ownership

• CloudOps
• TechOps
• SysOps
• TechOps
• Support Teams

Each team page contains:

• Responsibilities
• Link to owned services
• On-call & escalation contacts
• Stakeholders

[Varvara K_]

@Dave Mathijs It is really interesting point of view. Thank you for your answer!