Software Dependency Graphs for Faster Change Impact Analysis

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In network environments, accurately identifying and tracking software and hardware dependencies is challenging, leading to decreased operational efficiencies and unintended downtimes due to unintentional overloading and difficulty in managing dependencies as components are updated or introduced.

Innovation Solution

A system using a dependency quotient model generates a dependency quotient based on historical data and relationships between computing components, enabling the creation of a system architecture interface component that includes a decentralized digital ledger to track software changes and their impacts, utilizing graph theory and augmented or virtual reality interfaces for dynamic updates.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Measurement precision

If traditional dependency tracking methods are used in network environments with numerous computing components, then the system can maintain basic operational functionality, but dependency identification accuracy decreases and tracking reliability deteriorates

Engineering Contradiction:
Improvedependency identification accuracyVSAvoidsystem complexity
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent segments the complex dependency tracking problem into multiple layers: infrastructure layer for core dependency data, wrapper layer for processing logic, and data layer for historical records. This segmentation allows accurate dependency identification while managing system complexity through modular architecture.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces intermediary components including a dependency graph generator that mediates between raw computing component data and dependency relationships, and an impact analysis engine that mediates between dependency changes and system-wide effects. These intermediaries improve tracking accuracy without directly increasing overall system complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Measurement precision

If comprehensive dependency tracking is implemented across all computing components, then dependency identification accuracy improves, but processing time increases and operational efficiency decreases

Engineering Contradiction:
Improvedependency tracking accuracyVSAvoidoperational efficiency
Core Design Contradiction:
Measurement precisionVSProductivity

Solution Approach 1:

The patent implements preliminary action by continuously building and updating the dependency graph in the background before actual impact analysis is needed. Historical dependency data is pre-processed and stored in the data layer, allowing rapid query and analysis when changes occur, thus maintaining high tracking accuracy without slowing down operations.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent employs dynamic updating mechanisms where the dependency graph and impact analysis results are continuously refined as new computing components are introduced or existing ones are updated. This dynamic approach ensures accurate tracking adapts to changing system states without requiring complete re-analysis, maintaining operational efficiency.

Inventive Principle:
Principle #15Dynamics

3Reliability

If real-time dependency monitoring is performed to identify all computing component relationships, then dependency tracking reliability improves, but computing resource consumption increases

Engineering Contradiction:
Improvedependency tracking reliabilityVSAvoidcomputing resource usage
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent implements continuous dependency monitoring through the infrastructure layer that constantly updates the dependency graph as computing components change. This continuous action ensures high reliability by maintaining current dependency information without requiring intensive periodic full-system scans, optimizing computing resource usage.

Inventive Principle:
Principle #20Continuity of useful action

Solution Approach 2:

The patent creates a virtual copy of the system architecture in the form of a dependency graph that mirrors real-world computing component relationships. This virtual model allows real-time monitoring and impact analysis to be performed on the copy rather than the actual system, maintaining reliability while reducing computing resource consumption.

Inventive Principle:
Principle #26Copying

4Measurement precision

If detailed impact analysis is performed for each software change across all computing components, then change impact prediction accuracy improves, but processing time increases

Engineering Contradiction:
Improveimpact prediction accuracyVSAvoidanalysis processing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent extracts only the relevant subset of dependency relationships needed for impact analysis from the complete dependency graph. The impact analysis engine selectively queries the data layer for specific computing components affected by a change, rather than analyzing all dependencies, thus maintaining high prediction accuracy while minimizing processing time.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentUS12487801B2Systems and methods for determining software dependencies and software change impacts on computer processing
Publication Date: 2025.12.02 BANK OF AMERICA CORP
  • US12487801B2 patent drawing
  • US12487801B2 patent drawing
  • US12487801B2 patent drawing

AI summary

Systems, computer program products, and methods are described herein for determining software dependencies and software change impacts on computer processing. The present disclosure is configured to identify at least one computing component within a network environment; identify historical data for the at least one computing component; apply the historical data to a dependency quotient model; generate, by the dependency quotient model, a dependency quotient based on the at least one computing component, the historical data, and a relationship between the at least one computing component and at least one secondary computing component; and generate, based on the dependency quotient, a system architecture interface component, wherein the system architecture interface component comprises data of the at least one computing component and the at least one secondary computing component within the network environment.