Parts & Trails
We define Part as a related piece of a product that has a lifecycle (creation, evolution, deprecation), and can be recursively made of smaller parts. Events and work items can be specific to any type of part.
We break a "part" down into two core categories:
Rev parts relate to how a product is expressed, integrated, or consumed. These parts may be purchased and interacted with by internal (employees) and external (revs) customers. Rev parts are of three main types Product, Capability and Features.
At the highest level of the part hierarchy is a product or service. An organization may have one or more products or services that they deliver to its customers. A product is usually the entity around which a business is organized and its Profit and Loss(PnL) is monitored. These are some guidelines to define a Product:
- The Product should have a Minimal set of capabilities (i.e., the product’s platform)
- The Product should be at the lowest level in the part hierarchy where revenue can be assigned
- The Product should be at the lowest level in the part hierarchy where a market category is created
Following are typical examples of products:
A website has been set up for Maple Software to serve as an example. We will use the contents of this website to define parts as well as visualize how the company would use DevRev Parts and Trails.
An independent set of features, that is prominent enough to define a minimum product offering and is measurable, observable, upgradeable, and potentially monetizable.
For the products above, the capabilities could be defined as below based on the pricing models displayed on their websites.
Freemium Startup Enterprise
Pro Business + Enterprise Grid
A feature exists under a capability and is commonly a unit of configuration or "knobs" in a capability. Features typically have the following characteristics:
Exists under a capability Provides a unit of configuration (adjective) for entities managed by the capability Enable version history (adjective) on the object May provide a subset of the API namespace Are commonly not interacted with outside the context of the capability (if directly interacted with at all)
Building on the examples above, we can now list the features linked to every capability.
This information maps directly to their websites.
Features: - Cards
Features: - Cards - Pay
Features: - Cards - Pay - Rewards
Pro Features: - message history - apps and integrations - lightweight, voice-first huddles - Secure work with other companies using Slack Connect channels Business + Features: - message history - apps and integrations - lightweight, voice-first huddles - Secure work with other companies using Slack Connect channels - 99.99% guaranteed uptime - User provisioning and de-provisioning - SAML-based single sign-on - Data exports for all messages Enterprise Grid Features: - message history - apps and integrations - lightweight, voice-first huddles - Secure work with other companies using Slack Connect channels - 99.99% guaranteed uptime - User provisioning and de-provisioning - SAML-based single sign-on - Data exports for all messages - Unlimited workspaces - Support for data loss prevention (DLP), e-Discovery and offline backup providers - Designated customer success teams - HIPAA-compliant message and file collaboration
The code, service, or components built or used by the developer are called Dev Parts. A Dev Part may be a "runnable", like a microservice or an executable. Runnable parts often expose APIs.
The Dev Part currently exposed in the Trail is a Microservice runnable part.
Features and Capabilities (Rev Parts) are often served by one or more Microservices (Runnable Dev Parts).
Microservices typically have the following characteristics:
- They expose and are interacted with via APIs, RPCs, or UI
- They may be published in a service registry or accessed through a load balancer
- They are a unit of functionality that can be developed and deployed independently
DevRev Trails visualizes the entire Product hierarchy, connecting the Dev Parts to the Rev Parts to attribute development effort to customer consumable features and eventually the revenue.
This is an example Trail for Maple Software.
The Trail can be populated manually by creating the Product, Capability, Features, and Microservices and linking them. A many-to-many mapping exists between the features and microservices. is also possible to view the Tickets & Issues associated with the Part in the Parts Details Page.
Our Parts Discovery[BETA] offers Parts suggestions as well as suggested links to assist with Trails building.
Parts Discovery [BETA]#
The customer will need to opt into Pars Discovery since it is still a beta offering.
The customer can use any or all of the following options to seed our Parts Discovery with data:
Custom File Upload#
The customer can provide information about the API paths, services, and routing rules using a
custom_routing.json file that implements a simple schema.
Following is an example of the custom file and the corresponding trail showing the parts discovered through it:
The Import option on the Trails View in the Product provides an easy interface to download a template file, which can be filled and uploaded.
Link Git Repository with API Documentation#
Features are discovered by analyzing OpenAPI specification files found in the git repository integrated with the DevRev App.
Kubernetes Based Discovery#
The Trail can be discovered by installing the DevRev Kubernetes Collector on your cluster. Parts Discovery algorithm relies on the Feature APIs exposed via the Kubernetes Ingress context. The helm charts to install the collector along with the instructions to install are available via our git repository here Please note our collector is a lightweight cron-job which runs once in 6 hours and consumes minimum resources. We cap our utilization and expose the limits in this public helm value file.