What component types would you like to see?

[Patrick Hill]

Hey Compass Community!

We’ve been researching component types to explore how we can best let you change which component types are available on your Compass site, and we’d love to get your input. Right now we have four main types:

• Service - Used to model anything from microservices to monoliths and everything in-between (including Lambdas)

• Library - Reusable packages of code that are used in Services, Applications and scripts. We’ve used this type to model frontend components, sidecars and many other types of reusable software.

• Application - Think of all the Mobile Apps, SaaS Apps, Desktop Apps, CLIs and many other apps you use everyday!

• Other - Our catch all for when it’s a bit too hard to fit it into other categories.

You can read more about the types here: https://developer.atlassian.com/cloud/compass/components/create-view-update-and-delete-components/#component-types

We’re interested in adding a handful more in the next few months, and want to hear from all of you about what you’d want to model in Compass (and why).

What component types would you like to see in Compass, and what else would you like to model? Feel free to leave your suggestions as a comment below.

[Mac White]

I would like to see a 3rd Party or External Component. This would allow us to track our dependencies on these External systems. This is particularly important if and when we need to reach out to partners to discuss any issue we are seeing. Additionally we would love to be able to tie in the status of our Partners to our own Status Page integration and have an area in Compass for our Support team to craft messages as well as update status for our critical Partner components and integrations.

[Valentyn Serdiuk]

Can we just define component types by ourselves? I mean every company have slightly different processes and services and name them differently, also everyone have different model how to group services, for example how we group it - lets say we sell pizza, our model be like:

Tier 1 - business processes like customer creation and onboarding,  pizza constructor, order processing and so on - top-level entities that are crucial for our business as pizza sellers

Tier 2 - business services like payments, customer cart creation and management, user creation, user onboarding, user verification etc etc etc - services that business processes from tier 1 is consist of

Tier 3 - actual services like customer cart service, user onboarding service, user profile services, pizza ingredients catalogue etc etc etc  -micro, monoliths, serverless functions etc - something that is actually a code/database/etc that implements building blocks for tier 2

Tier 4 - hardware and software like aws ec2 server, actual hardware server in basement, actual instance of Oracle database etc etc etc - something that provides building blocks for tier 3

So, in our case we need a lot more component types then just services, apps, libraries and other. I mean I can't even describe Tier 3 with it because of tier 3 consist of actual services(ok, we have them), FaaS(we use both lambdas and self-hosted, so it's 2 and none of them is present), databases(nope :( ), mq ( we use 3 different types, but need at least 1 type, zero for now), we have a bunch of third party software(which is not services nor libraries, for example SDK, BPMS etc).

My point is that no matter how hard will you try you'll never do fit-it-all solution without giving end users customisation option, yes, custom fields is great even now in that stage, but if you didn't give us option to create our own component types our "others" section will be trash bin like it is now. And it's a huge blocker for us to implement it org-wide because everyone asks how can they create their own components(I mean most of this requests is definitely trash, but some of them are really needed) 

[Mircea Braescu]

I'd actually like the option to create custom components, with custom icons (from a preset library like you have in Jira, for example). 

This is useful because I see the potential of Compass to be more than just a catalogue of components and applications. It can be an overview of all the functionalities that a product offers, We've done something similar internally where we have:

User types <--> business processes <--> Applications <--> Services

And this can be incredibly useful for onboarding people on projects and showing all the functionality that a platform offers. 

Having the freedom to define our own custom component types would make things even better (instead of using "Other")

[Robin]

I'm missing 2 that I consider to be 'major' components: 

• Third-party
• Monolith

Third-party

This could be anything that you do not develop yourself. Such as a package to integrate the JIRA API into a project, or Slack, or Sentry, or another. 

Certain packages can be used by multiple internal products. A few example that perfectly fit that bill are Sentry (Exception monitoring) and Navision (Microsoft's enterprise book keeping software). If they were to release new versions with backwards compatibility breaks, it would be extremely important that all Product Teams that have a dependency on those packages (anywhere through the dependency tree) get notified. 

Some will have nothing to do with it, for example a product using an Order service has no direct dependency on Navision, but the Order service itself does, as does an Invoice service. 

Having the ability to specifically map them also shows which third-parties should be regarded as critical or high-impact when they change something. 

Monolith

Where I work we have a couple of monolithic applications. I know, they should be cut down into smaller things, and we're working on that. But real-life is that those behemoths will be around for years to come. 

I would suggest a monolith to be different from other components as well, as in: it's not "just a single component", instead being comprised of multiple Components. 

Take "Monolith Truckshop" for example, it will have a bunch of components handling different parts of the business in it, such as "invoice", "order", "truck", "brand", "user", "authentication", and many, many more. 

In our case we have a couple with millions of lines of code. 1 of which has 12 Product Teams dedicated to handling a selection of components each. 

[mwelter27]

While we could use Other, another component(s) I could see being useful would be around 'Database' & 'Middleware'

These are important when you start looking at announcements and dependency linking

[Jan-Hendrik Spieth]

We need this! :-)

[Andrew Krock]

We do *lots* of background processing via event driven workers, and while we could use "Application" to track these I feel it would be beneficial if we were able to separate them as their own Worker Component Type.

Especially as we won't have the same metrics for a background worker as we would for say a web application w/ a UI.

[Katie Silver]

@Valentyn Serdiuk , you bring up a good point. We are actively thinking about component type customization along with these additional types. There are a couple reasons for this: 

- we want to help users understand what types of data can/should be tracked in Compass

- we want to be able to suggest best practices for how to manage this data in the future

On the flip side, we totally get that one size does not fit all in this circumstance. So we're thinking about customizable component types along with these helpful defaults. 

[rain.ettienne]

Love to see that we can be apart of the development of Compass!

How about a component category strictly for tracking certifications?

The purpose of this can be to track where certs are located, their dependencies, and to keep track of expiration dates.

[Ole Øyvind Skaaret]

Sure thing, I forgot that when writing. 

[mwelter27]

Hey @Patrick Hill if we had more flexibility, I would actually break this into more granular components but 'UI' would at least be used for our JS/React codebase. When I think 'Applications' in today's world, I would put any of our native Mobile & Desktop Apps into that category. Additionally, any legacy JSP type monolith applications would get thrown here, I'd like to say these don't exist anymore but I would be lying. 

[Ole Øyvind Skaaret]

would have been very nice if we could name the components ourselves.

And tags/labels would also be very nice 😊 

[Alfred]

When mapping out the relationships within a mind chart, we want to holistically capture all of the elements that are directly and indirectly interconnected. What we are missing is having the capacity to categorize what that particular service does. Maybe we are referring to a marketing automation tool, perhaps the purpose of a particular tool is to serve as a switchboard and interconnect other elements so that they may properly push and pull from one another. By having different methods of categorization, beyond just “Service”, we can then spot redundancies in the tools and/or procedures that we are currently using. It answers questions concerning where exactly the overlap is between these elements in terms of function.

[Janne Jaula]

Standard, Business Process, Process Artifact/Object, similar (e.g. being able to refer to regulated entities like technical file or proof of compliance.

[Robin]

Additional point of feedback about the "Component" in Compass: 

Can it please be linked directly to the Components defined in Jira? 

Or even better: Can Components be defined in a dedicated location for Components, and can we then assign a Component to both a Jira Board and Compass Component? 

Advantages:

• Handling Components in a centralized location
• Allows a Component to be assigned to X
  • X being anything that uses components, such as: 
    • Jira Board
    • Compass Component
    • Team
    • Mentionable in Confluence using @ or something else 
• Allows easier clean up of the current messy states of Components everywhere
• Makes a Component a primary core feature 

Disadvantages

• Incompatible with current Jira Component
• Big refactor / replacement component
  • Could exist simultaneously while creation of current component type is disabled
• Impacts workflows, plugins, etc etc etc
  • BC Break

[Katie Silver]

@Valentyn Serdiuk , if you use the new Advanced Search screen (described here,) you can filter by labels!

We're also thinking about a label "quick search" like in Jira where you can click the label and the whole search results pop up. We could also go further like in Atlas and show an actual label dashboard of sorts that aggregates information about the labeled components. Interested to hear what would be valuable for you! 

[Valentyn Serdiuk]

@Katie Silver yeah, but I'm not able use search/group by etc in lables :(

[Katie Silver]

Haha, no worries 😁

[Alfred]

These elements can have multiple uses, not just one capability. A "service" can be a marketing automation tool. Though its "capability" can be email, phone, and it can also serve as a medium for "push/pull" where the data stored therein is then transferred to another platform.

Other elements may serve merely as "switchboards" whose purpose is to interconnect tools so as to allow "push/pull".

Sources can be categorized even further by two types, "front-end" and "back-end". Which in even further detail can describe the relationships between these interconnected elements. Think about a service that is interconnected by just front end to a destination vs. just backend to another. 

[Patrick Hill]

Thanks for the response @Alfred - we've been using Custom fields to do more finer grouping as the type is the broad category (e.g. a Service has availability and reliability, whereas a Library does not) and then using Custom Fields to get a a sharper resolution within that type.

I'd be interested in hearing more about how you'd want to categorise components though - we're thinking of introducing the concept of a "Capability" which may fit your purpose better in identifying where there is unwanted redundancy.

[Patrick Hill]

👋 @mwelter27 - Can you expand what would you use it for? We've seen some  internal usage around individual UI components, entire websites and a few other use cases but keen to hear more.

[Katie Silver]

Hey @Ole Øyvind Skaaret , thanks for the comment! 

We do have label functionality on individual components. Have you tried those out? If that's not what you're looking for, I'd love to hear more about what you're trying to do.

[mwelter27]

I'd like to see one for 'UI'