Start answering questions about who owns what within your organization without a doubt.
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!
By leveraging our GitHub repository auto-discovery, you can map your repositories to Code Paths and Contributor.
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?
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?
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:
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.
Get started today for free and take our auto-discovery tool for a test drive. Try now.
Learn more strategies and benefits.