Low-Code App Assembly With Tenant-Specific Observability Injection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The challenge of maintaining observability in low-code applications, particularly those hosted outside the enterprise's security perimeter, is exacerbated by the lack of visibility during creation and deployment, leading to issues like unmanaged resource consumption, data leakage, and compliance challenges.

Innovation Solution

Implementing a method to determine tenant-specific policies for low-code applications, dynamically computing injectable tasks, and injecting observability tasks at creation time to enforce runtime observability requirements, ensuring compliance and visibility through a custom observability policy.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If low-code applications are hosted outside enterprise security perimeter to enable rapid development and deployment, then productivity and ease of operation are improved, but observability and compliance control deteriorate

Engineering Contradiction:
Improveapplication development speedVSAvoidvisibility during creation and deployment
Core Design Contradiction:
ProductivityVSLoss of information

Solution Approach 1:

The system performs preliminary actions by determining tenant-specific policies and dynamically computing observability requirements before the low-code application is created. This allows observability tasks to be pre-configured and injected at creation time, ensuring visibility is established upfront rather than attempting to add it later to applications already deployed outside the security perimeter.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary mechanism that acts as a bridge between the low-code application platform and enterprise observability requirements. This intermediary dynamically computes observability tasks based on tenant policies and injects them into applications, enabling compliance control without directly restricting application deployment locations or development processes.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If observability tasks are added after application deployment, then compliance monitoring can be implemented, but resource consumption increases and application performance deteriorates

Engineering Contradiction:
Improvecompliance monitoring capabilityVSAvoidresource consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

Observability tasks are determined and computed in advance based on tenant-specific policies before the application is created and deployed. This preliminary configuration ensures that monitoring capabilities are built-in from the start, eliminating the need to add heavy monitoring agents or tasks after deployment, thus avoiding post-deployment resource overhead.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system dynamically computes observability tasks by changing parameters based on tenant-specific policies and application characteristics. This allows the observability configuration to be optimized for each application's specific needs rather than applying a one-size-fits-all monitoring approach, reducing unnecessary resource consumption while maintaining compliance monitoring effectiveness.

Inventive Principle:
Principle #35Parameter changes

3Ease of manufacture

If generic observability policies are applied to all low-code applications, then implementation simplicity is improved, but adaptability to individual enterprise needs deteriorates

Engineering Contradiction:
Improvepolicy implementation simplicityVSAvoidcustomization to enterprise needs
Core Design Contradiction:
Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The system transitions from static generic policies to dynamic tenant-specific policies. The policy determination process adapts to each tenant's unique requirements by dynamically computing observability tasks based on specific enterprise policies, application parameters, and compliance needs. This dynamic approach maintains simplicity through automation while achieving high adaptability to individual enterprise contexts.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

Instead of applying uniform observability policies across all applications, the system implements local quality by tailoring observability requirements to each tenant and application specifically. Each low-code application receives customized observability tasks determined by its tenant's specific policies and the application's particular characteristics, ensuring optimal fit for each local context while maintaining overall system coherence.

Inventive Principle:
Principle #3Local quality

Data Source

PatentUS12585573B2Assembling low-code applications with observability policy injections
Publication Date: 2026.03.24 CISCO TECHNOLOGY INC
  • US12585573B2 patent drawing
  • US12585573B2 patent drawing
  • US12585573B2 patent drawing

AI summary

In one embodiment, an illustrative method herein may comprise: determining, by a process, a tenant-specific policy for creation of low-code applications; dynamically computing, by the process and based on the tenant-specific policy and one or more parameters associated with a particular low-code application to be created, one or more injectable low-code tasks for the particular low-code application; determining, by the process, a plurality of selected injectable low-code tasks from the one or more injectable low-code tasks; and creating, by the process, the particular low-code application by injecting the plurality of selected injectable low-code tasks into the particular low-code application for execution.