How to Map Your Dependency Graph in OpenContext

Start answering questions about who owns what within your organization without a doubt.

Alice Chen
Alice Chen
Feb 15, 2023
Context in Action
How to Map Your Dependency Graph in OpenContext

At OpenContext we know mapping your team, code, and infrastructure dependencies is hard. It takes countless meetings across the organization with SMEs in order to create that on-off Figma/Miro dependency graph of your teams, code, and infrastructure. Moreover, almost as quickly as this is done it goes out of date.

This is really frustrating when what you're trying to solve is whether there are any repositories or codepaths without clear owners. If you're trying to identify who owns what so you can triage various issues, it gets even tougher (especially in a monorepo).

We get it, and that's OpenContext makes it easier and faster to map your team, code, and infrastructure dependencies. It also doesn't require a team to manage it. Let's take a look how!

Step One: Auto-Discovery with minimal effort

By leveraging our GitHub repository auto-discovery, you can map your repositories to Code Paths and Contributor. 

Wait, code path? 

Yep, we talk about Code Paths because we know some have monorepos and some have Services and others have a combination of the two. The smallest level of detail is the code path. 

This code path is owned by a person or team. These have been designated as Code Owners in GitHub. When the Code Owners are processed, it will create Code Paths and map the people and team relationships. 

If you are a GitOps shop, you are one and done. This will help you understand who is working on what. If Johnny is working on five projects but only assigned to one, why is Johnny doing this? That’s up to you to find out. (In our experience, Johnny wasn’t able to off-board from older projects and is your secret SME.)

The best part of Auto-discovery with OpenContext is you can get started for free, in minutes without writing any YAML. Not a bad deal, right?

Step Two: Fill in the gaps wherever you’re at 

We know that teams are using tools like Figma, Miro, and Whimsical to assess the general shape of your organization. Who owns what. How are those teams, pieces of code, and infrastructure connected? We also know, our DevOps friends are well-versed in using YAML for Kubernetes as well as defining infrastructure code via configuration management tools. 

We’re leveraging these same methods for you to set up your organization in OpenContext. In fact, we encourage you to leverage some of your existing tooling. Why reinvent the wheel? 

What to do after your auto-discovery is up and running. 

Our recommendation is to leverage the same logic you used when starting to do configuration management. Take a small piece and automate it. Create the YAML based on a portion of your existing Figma/Miro/Whimsical boards. You’ve got the information already. 

I’ve written some detailed documentation on how to get started. Let’s walk through it now. 

You can learn how to map your Infrastructure here which will give you insight into your Scheme or Product Line. 

Your Platforms (How to Group Platforms and Scheme here )

Your Datacenters (Link to the How To here)

And finally, here is how to map your organization which gives you Groups. 

Once you’ve mapped these components you’ll be able to:

  • Make critical decisions on how your teams, code, and infrastructure actually work together.  
  • Create your organization's dependency graph instead of looking at a slice of your team data or code or infrastructure. 
  • See the shape of your organization thanks to our auto-discovery from GitHub and your configurations via YAML.
  • Track if there are any repositories or code paths without clear owners.
  • Identify who owns what (especially in a monorepo) which makes it easier to triage various issues.

All of this gets you to where you can start answering questions about who owns what within your organization. 

Now you can see everything Johnny owns, all the teams he interacts with, and the projects or product lines he’s impacting. Furthermore, you can start to identify critical paths in the technical stack. Or all the SMEs who need to be in that architecture meeting.  And who to talk to when you have a gnarly incident.

Let OpenContext show you what you might be missing

Get started today for free and take our auto-discovery tool for a test drive. Try now.

What could shared context mean for your SDLC?

Learn more strategies and benefits.

Thanks, please check your inbox
Oops! Something went wrong.