Technical Configuration Decoupling for Cloud Software Updates

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional technical configuration updates for cloud-based software products often require significant downtime and are inefficient, as they involve executing all task lists simultaneously, which can lead to issues with partial updates and software changes, especially when customer and service provider changes are intertwined.

Innovation Solution

A technical configuration module calculates changes in the software, determines necessary updates, and decouples them from software changes using virtual change requests, allowing only affected configurations to be updated, with restartability and resumability features, and separates customer and service provider changes to prevent blocking updates.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If all task lists are executed simultaneously to update technical configuration, then the update process is comprehensive, but the downtime is significant and the efficiency is low

Engineering Contradiction:
Improvecompleteness of configuration updateVSAvoiddowntime during update
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the technical configuration update process into two independent parts: software changes and configuration updates. Software changes are applied first, then configuration updates are triggered separately through virtual change requests. This segmentation allows the system to update configurations without re-executing software changes, significantly reducing downtime while ensuring comprehensive configuration updates.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements preliminary action by creating virtual change requests that capture the intent of configuration updates before actually executing them. These virtual change requests are prepared in advance and can be applied selectively to only the affected configurations, allowing the system to minimize downtime by pre-planning the update sequence and avoiding redundant operations.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If all task lists are executed simultaneously, then the update is thorough, but partial updates and inconsistencies may occur when software changes are intertwined with customer and service provider changes

Engineering Contradiction:
Improvecompleteness of configuration updateVSAvoidconsistency of update application
Core Design Contradiction:
ReliabilityVSManufacturing precision

Solution Approach 1:

The patent segments different types of changes (customer changes vs. service provider changes) into separate change requests with distinct priorities. This segmentation allows the system to process changes in a controlled sequence, applying software changes first, then customer-specific configurations, and finally service provider configurations. This approach ensures consistency by preventing interleaved execution that could lead to partial updates or conflicts.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces virtual change requests as an intermediary mechanism between software changes and configuration updates. These virtual change requests act as mediators that decouple the dependency between software changes and configuration updates, allowing the system to apply only the necessary configuration changes without re-executing software changes. This intermediary layer ensures that updates are applied consistently and selectively to affected configurations only.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Adaptability or versatility

If customer and service provider changes are processed together, then the system handles all changes uniformly, but updates may be blocked and efficiency is reduced

Engineering Contradiction:
Improveability to handle different change typesVSAvoidupdate efficiency
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The patent segments change requests into different types (customer changes and service provider changes) with distinct priorities. Customer changes are processed with higher priority and can proceed independently, while service provider changes are processed separately. This segmentation prevents blocking between different change types, allowing the system to maintain adaptability in handling various change scenarios while improving update efficiency by avoiding unnecessary waiting and re-execution.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS10915309B2Technical configuration delta-driven update and decoupling
Publication Date: 2021.02.09 SAP SE
  • US10915309B2 patent drawing
  • US10915309B2 patent drawing
  • US10915309B2 patent drawing

AI summary

A method and system including a technical configuration module; a software application; a technical configuration processor in communication with the technical configuration module and operative to execute processor-executable process steps to cause the system to: receive a change request including one or more changes to the software application; determine one or more changes to at least one object of a technical configuration of the changed software application; receive a virtual change request including a list of changed objects; and execute an update to the at least one object of the technical configuration based on the determined one or more changes received in the virtual change request. Numerous other aspects are provided.