3 answers
1 accepted
Hey @ihe, my name is Taylor Pechacek - Head of Product for Compass. First off, thank you so much for raising this question here and for taking a look at Compass!
I am going to try to give some clarity based on what our POV is today, but I would very much love an hour to better understand you, your team, and what kinds of problems you are trying to solve. You can sign up here https://calendly.com/tpechacek/compass
Please note, we have Thanksgiving holiday in the U.S. this week and then I will be unavailable the week of Nov 28 - 2nd. But anytime after that, there are lots of options to choose from!
I will try to address each of your questions and then give a broader overview.
With companies already having defined services in JSM, using Opsgenie to track incidents, response teams etc: how can existing defined services be mapped into components in Compass?
TL;DR -> We need to go sync the 'service' object with JSM + OG. This means you an import into Compass to start. If you add in one place, it gets added in another, etc. Single 'service' object across Atlassian so there is no confusion. We intend to do this by the time we go GA, but to be completely transparent there are a lot of companies that are not using JSM Insight nor have any plans too - they will use Compass as their only catalog and then just want that to work well with OG alerting & on-call.
Some more detail on this!
- Compass is very focussed on engineering teams, especially those practicing DevOps, where they are likely to have a strong Platform Engineering team who build tools, services, and frameworks to improve the developer experience and enable self-service use cases including access to infrastructure. The application teams who are building new features in these environments are building and operating software components - usually microservices, shared libraries, and a few other types. Many of these teams we have spoken to are not using JSM and if they are using Opsgenie have no invested heavily in the software catalog + developer experience around that.
- However, to his end, we also have customers who ARE using Opsgenie + Jira Service Management and want to use Compass as well. For these customers, we have plans to sync the 'service' object across Atlassian so there is one representation. However, Compass will have a much richer set of data about those software components as that is why the product exists - for software developers and helping them be more productive in a more complex, distributed working environment.
- So, we know this is getting painful and we are working on the details now and will pick up as early next year. Once we 'sync', it is safe to assume the ID and name will likely be the same and if you are using JSM Insight or OG services already then you can 'import' those into Compass like you would define them in the compass.yaml file. The source of truth can be elsewhere (e.g. git), but then teams use Compass as the primary interface to all of the information related to those services.
To give you an idea of everything you can add around Compass, check out this internal screenshot of our compass-ui frontend microservice that we track in Compass. There is a TON of additional internal tooling that is exposed for developers to use along the left hand side along with basic information related to activity, metrics, scorecards, key links to dashboards, owning team, etc. that we give out of the box.
This is what we mean by our extensibility pillar in that the developer experience can be 'crafted' internally into whatever you want.
So while the main 'service' may sync over to JSM and Opsgenie, Compass provides a much richer experience about those services in which they would use Compass for all that info.
To the last point here, we would then obviously want to show the additional Compass data we have available in context of JSM Incidents and Opsgenie alerts to help engineers triage, make decisions, etc. In that sense Compass + JSM could work really well together but generally are solving different parts of the problem.
Regarding response teams for services in Opsgenie; can these response teams automatically be linked/mapped/imported into Compass? If yes, how is syncing managed?
TL;DR -> This is a tricky one. Compass is brand new so we got to use Atlassian Teams right out of the box. Opsgenie already have a 'team' object that is deeply ingrained in how their product works. They are working to 'sync' Opsgenie Teams with Atlassian Teams so it's the same set of users. Once that is done then Compass + OG Teams (And Jira for that matter) will all be the same global 'team' representation which unlocks really incredible use cases across the Atlassian platform. I would reach out to the OG team to see how that is going. Let me know if you want me to put you in contact with someone!
With Jira projects already being mapped to Gitlab repositories; will a Compass mapping to a Jira project suffice in regards to mapping the component to a repository? Or will all components in Compass have to be mapped to a) a project and b) to repository?
Good question! So, we are finding most customers do not map a single Jira project to a single repo. Instead there are many repos related to a project as the issues they work on span across repos (and components in Compass world). To draw out a scenario - let's say there are individual DevOps teams who own a set of components. They own 7 different microservices and 2 libraries. Each of these have their own repo, so 9 repo links. They use 1 Jira Software project to run their agile workflows.
In this scenario, Compass allows you to add a repo link and a Jira project link to each component. So the repo link will be different but the jira project link will be the same for all 9 (boo - lots of duplication. Maybe we could get a Jira project for that team in Compass and then all services could auto-fill that out unless you override?).
Jira projects are mapped to GitLab repos, but we don't know which repo is mapped to which component. That is the net new thing you need to add.
However, what is GREAT about this, is that in a few months, we will be able to automatically add all the Jira issues related to a given software component because of the Jira issue <-> commit link as part of. normal JSW workflows. That issue is part of a project and the commit is part of a repo. That means we can safely assume which issue is related to which software component and auto-populate your 'backlog of tech debt' for your entire architecture tracked in Compass.
What information in Compass can be displayed in Confluence? Dependencies? Description of each component? Responsible team?
Oh this is a great question! If you paste the URL of a compass component within the editor (Confluence or Jira description) it will auto-render the Compass information.
Now, this is still pretty limited, but we can add anything you want here! We give you Type, Name, Tier (which denotes how critical the service is), Description.
What would you like to see here?
Regarding the announcement-functionality in Compass; are the announcements Compass-specific, meaning will an announcement only be visible in Compass? I realise that with microservices and CI/CD not everything will be applicable into change managements managed in JSM. However, I assume that some planned changes would be relevant to manage in Change management tools. Is there a connection here of some sorts?
They are Compass specific today. But since we have started leveraging the Notifications Platform within Atlassian, we can send these product events as in-product notifications which means they will appear in all Atlassian products with the little bell icon (notifications).
I would love to discuss Change Management tools and how you think Compass might be able to help. Yes, many customers are using CI/CD and have started to 'shift left' by placing security, testing, PR reviews, and other mechanisms as part of dev workflow to 'de-risk' any given deployment or change to production. But Compass might be able to help with the security scorecards or other things to denote that a given component or service is in an 'unhealthy' state as defined by your team and therefore should have higher threshold for reviews/gates/approvals, etc. Whatever you want to put in place to limit that risk.
Ok, I hope all this provides some clarity. But at the end of the day, Compass is really focussed on the Developer Experience internally. So, how can your developers, who work across many different tools and now have additional operational responsibilities be more productive and happy. We want to remove the toil that bogs them down when information gets lost and disconnected.
For Jira Service Management, you still need core ITSM workflows around change, problem, and incident management. JSM Assets let's you model any object you want, which is still greatly needed for that world I believe.
Our aim is that Compass works very well with all of our Atlassian tools like Jira Software, Jira Service Management, Bitbucket, and Opsgenie. There is a bit more work to do re: consolidating some existing concepts together across JSM/OG + Compass to make the user experience much more delightful and expected!
Cheers!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.