Concepts

Description of key concepts in the DevGrid eco-system

Entities

Entities are the building blocks of your DevGrid inventory. They are the various things that exist in the technology world. They are fundamental things like APPLICATION or PERSON but also abstract ideas like PORTFOLIO or CAPABILITY . There are a number of core Entities, but DevGrid also supports the creation of custom Entities should you need to extend the core capabilities.

Below is a list of the Core Entities:

Application

Application is the main entity in DevGrid. It is the foundational building block of your inventory. An Application is an (arbitrary) boundary around technology assets that provide a prescribed function.

How you decide to draw the boundaries and decide what the application is can be more of an art than a science. Still, where to draw the line in your context is usually emergently obvious.

Note, Application, and Service are often easily confused. In many systems, Service and Application are interchangeable. Especially given the rise of Kubernetes and how eco-system uses the term "service." In the DevGrid eco-system, Service is a 3rd party Service, like AWS's EC2, and your microservice is most likely an application.

Assignment

An assignment is how a person is assigned to a team. People can be on multiple teams at once, and also move from team to team over time. DevGrid keeps track of the assignment as its own entity.

Business

Business is a way to map your technology all the way to a Line of Business or Product. It will relate to the technology through the Capabilities that support its Business.

For example, at a Bank, you might have a "Credit Card" Business and a "Deposits" Business.

This is a great way for Product and Line of Business leaders to be given entry and visibility into the technology ecosystem.

Capability

Capabilities are the link between technology and real-world business needs. What does this application do? Why do we spend all this money building/buying, operating, and maintaining it?

Simple examples would be something like GitHub provides "Source Control Management" or Auth0 provides "Identity and Access Management."

Component

The component is the other critical inventory entity (besides Application). The component is the granular tech asset. We recommend breaking it down to each deployable asset. For example, in a simple microservice, You might have an API Gateway, an Application Tier, and a DataStore. Those would each be components.

If you ever have questions about how to break things down, please reach out to your technical account manager, and let us help you make those calls.

Component Type

The different types for categorizing components.

Examples include: UI,API, Data Store, Queue, Batch Job, Process, Service, Stream

Location

The physical location for designating workplaces. People can then be attached to them. Useful for understanding the geographical distribution of your team at a glance.

Person

The representation of a person from your organization. Note: this is separate from a user of DevGrid.

This person can have skills, activities, assignments to teams, etc.

Portfolio

Portfolios are arbitrary groupings of applications. They can be nested, and applications can belong to multiple portfolios.

They are used for topical reporting and organizational purposes. Rolling up all data in the applications are their related entities is a very valuable process.

Resource

A resource is an infrastructure resource. Like an AWS EC2 Instance or similar.

Role

The type of role a person fills for an assignment. Example: Software Engineer or Scrum Master.

Service

Skill

Team

Technology

Vendor

Relationships

Relationships are the lines (edges) between all the entities that make up the Grid in DevGrid. They build the knowledge graph of your space to help you understand how everything fits together. Like Entities, there are a number of core Relationships, but DevGrid also supports the creation of custom Relationships should you need to extend the core capabilities.

Below is a list of core Relationships:

Application Has Architect

Application Has Component

Application Has Owner

Application Supports Capability

Assignment Has Person

Assignment Has Role

Assignment Has Team

Component Has Dependency

Component Is Type

Component Leverages Technology

Consumes Service

Person Has Manager

Person Has Skill

Person Skilled In Tech

Person Works at Location

Portfolio Contains Application

Portfolio Has Owner

Portfolio Has Parent

Service Calls Component

Service Has Provider

Team Has Leader

Team Has Parent Team

Team Supports Application