Full Internal Software Catalog

Question

Hello, community!

Does anyone know of a good way to create an internal software catalog and/or request portal? I've bounced around a few communities and haven't found much info on the subject matter. So, I'd figure I's ask the community. We're hosting on Jira-Cloud.

Some additional details/requirements;

* An internal page where our employees can request software/services that our IT team offers
* Approval workflow to request approval from stakeholders for new requests
* Automated procurement and deployment of the software to the user. (Maybe using an MDM or something of that sort.)
* Able to track requests on a per-user and per-department base that would allow for some reporting as to which departments are using the most of our licenses or requesting things the most. 
* Ability to track which users have what software installed. Possibly in hand with an MDM solution like JAMF, Intune, or Qualys.

I've seen things like Insight be suggested, or the term "CMDB." I wanted to post this question out there to see if anyone has found a good way to achieve something similar.

TL;DR - A process for users to request software/service, log a ticket with approval, then automatically deploy the resource to the user once approved. Has anyone achieved something like this in Jira?

Thanks!

An edit for anyone who stumbles on this post | 04-JAN-2022

Now that it's been almost a year, we've come up with a solution for this;

Here's a quick summary of how it was accomplished;

* We created a new Jira project utilizing the newer Jira Service Management (JSM) suite/project type. (This was crucial since it had approvals somewhat configured out of the box that the older Jira projects did not. The workflows were then heavily customized to meet our org's requirements.)
* We created a new object schema within Insight to house our Software Catalog data.
* Created a custom customer request type, a couple of custom insight field(s) on the customer request type, and a new workflow to support the new customer request type.
* Created a hand full of Jira automations to extract data from the custom insight field(s) to drive logic on the issue workflows.
* Also had to create quite a few custom screens/schemas/workflows to support all this.

This is an excerpt from a reply to Jim, down below. You can read more there.

Jim Anderson_9180ag · Answer

Jeret,

Thanks for the update on your own project (and congrats on working out a solution)!

This confirms what I've come to believe is the best way to accomplish a list of supported softwares and services for users to select from when submitting access requests. Thank you!

The other side of this challenge is whether or not to (and if so, how) publish a formatted service catalog, such as this one from UC Santa Cruz. Remains to be seen whether that is worth the trouble or not...

Hope you have a great 2022,
Jim

Jeret Shuck_hfty3t · Answer

Hey Tokcum,

Please see my updated summary and response to Jim below. It's been a while, but I have made some progress on this.

Jeret Shuck_hfty3t · Answer

Hello Jim,

This was/is without a doubt, a hard nut to crack.

Since I made this post almost a year ago, we've made some pretty substantial headway on this project. We actually ended up going with Insight.  It's been a bit of a bumpy road, and we've run into a few snags or limitations along the way, but nonetheless; we have a full catalog of about 400+ software catalog items that users can select from to open access requests against. These requests then support multi-staged approvals (such as compliance, manager, and service owner approvals) throughout our org, which are all captured on Jira issues.

Here's a quick summary of how it was accomplished;

* We created a new Jira project utilizing the newer Jira Service Management (JSM) suite/project type. (This was crucial since it had approvals somewhat configured out of the box that the older Jira projects did not. The workflows were then heavily customized to meet our org's requirements.)
* We created a new object schema within insight to house our Software Catalog data.
* Created a custom customer request type, a couple of custom insight field(s) on the customer request type, and a new workflow to support the new customer request type.
* Created a hand full of Jira automations to extract data from the custom insight field(s) to drive logic on the issue workflows.
* Also had to create quite a few custom screens, and screen schemas to support all this.

It's a bit hard to clearly summarize everything in a single post. This project took quite a bit of documentation, brainstorming, and fumbling around in the dark so to speak. 😅

To try and answer some of your questions more directly,

> Perhaps I'm overthinking it and the solution is to simply create two Confluence pages for each approved resource. One page would be for end users. The second would be for "internal use only" by the IT Team

Instead of confluence, we actually used Jira's out-of-the-box support portal. That allowed us to use custom insight field(s) on customer requests types, that users can interact with directly. Not saying it's impossible to use confluence, I just don't know if it'll support the creation of Jira issues directly from a Confluence page. I'd assume it can, but I haven't tested that.

>  I think where I get stuck is in the layering and relationships of the different types of documentation that need to be created and managed for each resource, which then "roll up" and combine into services

We accomplished this using a custom Insight object schema and broke up the data structure into two different objects. The parent "Software" and the child "Role." Then, used insight to create parent-child relationships between the objects. Using these relationships, in hand with Insight field IQL filters, we were able to control what software/roles are exposed to which users in our org.

Happy New Year,

Jeret