Data Model
Your Data Model is the structure formed by all the blueprints defined in your Rely.io account. It encompasses their properties and the relationships between them.
This model encapsulates the entire schema of how data is organized and interconnected within your system. It also determines all the available data that can be stored across your Software Catalog.
Default Data Model
Rely.io provides an out-of-the-box data model based on common use-cases, but you are free to tailor it to your specific needs and expand it by creating new blueprints or editing existing ones.
The out-of-the-box scorecards, automation rules and dashboards were designed with the default data model in mind. Deleting core default blueprints (such as service, resource, or team) or their properties may require adjusting other default settings later to accommodate these changes.
Below, we provide an overview of all the core default blueprints as well as its descriptors.
Team
The Team blueprint represents groups within an organization, highlighting the roles of members and leaders. It includes properties like leader, members, on-call responsibilities, and communication channels.
Service
The Service blueprint defines an individual service within your software ecosystem, such as a micro-service. It includes properties related to the service's type, lifecycle, programming language, and various communication methods. Key relations include links to the teams responsible for the service and dependencies on other services, underlining its integration within the broader software architecture.
Resource
This blueprint is focused on physical or virtual resources, such as cloud infrastructure components. It includes details like resource type, location, and specific cloud service identifiers.
Environment
The Environment blueprint encapsulates different deployment environments, such as production or testing.
Running Service
A Running Service represents an instance of a service actively running within an environment. This blueprint includes detailed monitoring and configuration properties. Relations are established with the base Service blueprint, the Resources supporting the service, and the Environment in which it is deployed, illustrating the dynamic aspects of service management.
Deployment
This blueprint details the deployment processes for services, including timing, approval, and status. It is related to both Services, indicating what is being deployed, and Running Services, showing the outcome of deployments. This highlights its role in tracking and managing deployment activities within the software lifecycle.
Feature
The Feature blueprint is used to describe specific functionalities or features within services, including documentation, ownership, and related analytics dashboards. It is linked to Services that support the feature, pointing to its role in outlining how different services contribute to broader business functionalities.
Domain
The Domain blueprint defines high-level business domains, such as functional areas or product lines. It includes properties concerning documentation, ownership, and business objectives. Relationships are formed with Features and Services, indicating the domain's encompassing role over specific functionalities and the services that implement them.
Learn More
Last updated
Was this helpful?