Purpose of Capability Component Types

[matthew.seaborn]

Backstage contains the entity type "API" allowing the for the distinction of APIs from the underling implementation.  This is missing from Compass.

The definition of the component type Capability is the slightly vague "A higher-level product functionality that end-users understand and in which they see value. A capability is an abstraction of one or more underlying software components that power it."

https://developer.atlassian.com/cloud/compass/components/create-view-update-and-delete-components/#component-types

Is the intention that an API can be represented as a Capability?  What else is Capability intended to be used for?

[Katie Silver · Accepted solution]

Hi Matthew, thanks for writing in! Short answer, yes, you could use the Capability or Other component types to describe an API. 

Longer answer is, we're still figuring out exactly where an API specifically fits into the Compass architecture. Some users have created individual components for APIs, while some just add API information to Service components as metadata. 

The way we originally thought of capabilities was to serve as a grouping mechanism. As an example, we can look at a checkout experience: 

You might have the "capability" of Checkout, but there are several services that make up that experience - shopping cart UX, payments API, invoicing service, etc. Our thought was that Capability could serve as the feature that all these items roll up into. One way we've also heard it described is that a Capability = "what a support engineer would raise a ticket against." We've kept it flat so far to allow for as much flexibility as possible for users, but turning it into a hierarchy is still on my mind. 

Let me know what you think - does this help with your questions?