Parts & trails

A part is a related piece of a product or service that has a lifecycle (creation, operation, evolution, deprecation), and can be recursively made of smaller parts. Events and work items must be related to parts. In general, parts are the core objects that almost all other objects are linked to, which helps enforce the notion of tying everything back to the product or service.

Trails is an extensible interface that allows you to view and manage your part hierarchy and related items. Think of it like a graph canvas that's rendering linkages between items making them easier to navigate and summarize.

The following image shows an example of DevRev's trails view.

For a guided tour of Trails, check out the interactive walkthrough.

There are two core categories of parts: rev parts and dev parts.

Rev parts relate to how a product is expressed, integrated, or consumed. These parts may be consumed by external customers (revs) or internal employees (devs). Although they may also be provided/enabled by dev parts running internally, the customer just sees the product, service, or feature they are interacting with. Rev parts may also be abstractions on other rev parts exposed by 3rd parties (such as Auth0 or s3).

For example, in the digital world, rather than integrating with code or packages, they may integrate with APIs.

Dev parts are those built internally related to code or something the developer relies on or builds, or a service provided by an organization. These may be runnables that may expose APIs or linkables that may be used in other services (such as utils or libraries). Though they may provide the functionality exposed and interacted with by the customer, they are often abstracted and unknown to the user.

Types of parts typically include:

• product
• capability
• feature
• runnable
• linkable

The part hierarchy is at the core of the DevRev platform and is the basis for tying all work and event funnels to a common product or service model and for coordinating across funnels.

The following figure shows the conceptual part hierarchy.

Rev parts

Product or service

At the highest level of the part hierarchy is a product or service. An organization may have one or more products or services they deliver to their customers. Products can also be delivered through one or more conduits (such as tangible goods or as-a-service).

Products typically have the following characteristics:

• Are a unit of profit and loss (P&L)
• Are where customers (internal or external) are onboarded
• Provide the basis for identity
• May have a notion of billing/chargeback (which can be done at this level or further down the stack)

Services may have the following additional characteristics:

• Provide an API or interface
• Define code-based or business services

One example of the difference between a product and a service is Microsoft Office (software product) versus Office 365 (cloud service).

A key to consider is that all must be considered from the perspective of the dev org. A product for them may be a service for another. For example, consider a managed services provider, they may provide a "product" (for example, Microsoft Exchange) delivered as a managed service.

A service may also be a business service like IT (internal), HR (internal), or Consulting (external).

Example products delivered as software or tangible goods:

• Hardware products (Lenovo laptops, mobiles and more.)
• Software products (MSFT Office, Acrobat, and more)

Example services:

• Cloud services (Amazon Web Services, Azure, GCP)
• IT services (Helpdesk, Data center, and more.)
• Facilities services (building services, lunch services)

The following video shows products, capabilities, and features in DevRev.

Capability

A capability exists under a product or service and is commonly the main item of interaction for customers.

Capabilities typically have the following characteristics:

• Exist under a product or service
• Provide the ability to do something (verbs) with entities (nouns); for example create object
• Provide an API namespace
• Provide units of licensing and pricing
• Have its own level of authentication and access control or may inherit from the product

Feature

A feature exists under a capability (or feature for sub-features) and is commonly a unit of configuration or "knobs" in a capability.

Features typically have the following characteristics:

• Exist under a capability (or feature for sub-features)
• Provide a unit of configuration (adjective) for entities managed by the capability
• Enable version history (adjective) on object
• May provide a subset of the API namespace
• Are interacted with only inside the context of the capability or not directly interacted with at all

You can add a sub-feature to a feature for a more granular breakdown of features. These leverage the same feature object and have the same attributes. The only difference is that their parent becomes a feature rather than a capability.

Dev parts

Runnable

A runnable is a dev part and is something that can be instantiated or do something. For example, runnable may be macro services, microservices, or functions (lambdas). Runnables are things that have some direct execution or lifespan. A runnable may serve one or more features and/or capabilities.

A runnable typically has the following characteristics:

• Are a unit of functionality that can be deployed independently or as part of a larger system.
• Have an execution lifecycle be it short (lambda/function) or long (microservice).
• Expose an API.
• Are interacted with directly through an API or UI.
• Are published in a service registry or load balancer.

Example runnables:

• Docker image
• Lambda bundle

Example DevRev runnables:

• Wisp (search)
• Codex (work SOR)
• Partiql (parts SOR)

Linkable

A linkable is a unit of functionality that's designed to be part of a system or application and not used directly. These commonly refer to things like libraries or utils that may be leveraged by multiple runnables.

Components typically have the following characteristics:

• Linkable items are commonly used as libraries or binary artifacts.
• Not commonly exposed to the consumer (but can be).
• Are intended to be used as part of larger services, not on their own.

Example linkable parts:

• Library
• DLL
• Golang package

Example DevRev Linkables:

• All clients (for example, partiql-client, codex-client, mfz-client)
• Shared (logging and so on.)

Trails

Trails is an extensible interface that allows you to view and manage your part hierarchy and related items. Think of it like a graph canvas that's rendering linkages between items making them easier to navigate and summarize.

• Sort and filter: You can apply filters and sort for each column in trails. Filtering by owner and stage can help locate the data you need much faster. Part nodes can be sorted alphabetically by Name or based on events like Created date, Modified date, Target close date, Close date.

• Search navigation: Our top global search bar and localized search bars in each column of Trails now goes directly to the node for that searched part, saving you time and effort.

• Richer part nodes: You can enrich part nodes by selecting additional info like owner and stage.

Manage and link parts

To manage, link, and edit parts, click Product > Trails. For example, you have two products (Product 1, Product 2). Features and capabilities exist under each product.

Product 1 has capabilities namely Prod1 Capability 1 and Prod1 Capability 2. Product 2 has capability namely Prod2 Capability 3.

Let's say that you need to move Prod1 Capability 2 under Product 2 and vice versa. You can do this in either of the following two ways:

Step 1

1. Hover over the capability or feature you want to move and click View and it'll open a right window pane.
2. In the Related section, click Parts to open Link parts dialog.
3. In the Link parts dialog, click the product name in the To field.
4. Select the product name you want to move the capability from the drop-down. Click Link parts. You can see that now Prod1 Capability 2 is under Product 2.

Step 2

1. Hover over the capability or feature you want to move, and click the three dots beside the Add button.
2. Click Manage Links to open Link parts dialog.
3. In the Link parts dialog, click the product name in the To field.
4. Select the product name you want to move the capability from the drop-down. Click Link parts. You can see that now Prod1 Capability 1 is under Product 2.

If you have parent parts and children parts under it then:

1. Move the child parts first.
2. Optionally move linked tickets and issues for each child.
3. Then move the parent part.
4. Apply for this order at all levels: Product, Capabilities, Features, and Sub-features.

Linking parts isn't only limited to capability, feature, or runnable. You can link the following parts:

• Enhancement: A change to a part in the form of addition, deprecation, or transformation.
• Top contributors: Top 10 owners with issues in the closed/resolved stage for any part in the hierarchy.
• Top supporters: Top 10 owners with tickets in the closed stage and not null RevO id for any part in the hierarchy.
• Top customers: Top 10 workspaces with the most number of tickets for any part in the hierarchy.