Make-to-Stock Software Architecture via Service Interfaces

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Large and complex enterprise software systems require a scalable and cost-effective architecture that allows for reliable implementation and efficient interaction between multiple components across different hardware platforms, which existing solutions fail to address effectively.

Innovation Solution

A software architecture design for a make-to-stock process is implemented using multiple process components interacting through service interfaces, allowing for scalable deployment across separate computer hardware platforms and enabling effective reuse of software units, with each component performing specific business processes and interacting in a pair-wise manner.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If enterprise software systems are implemented as large and complex monolithic systems, then they can provide comprehensive functionality, but they become difficult to deploy, scale, and maintain across different hardware platforms

Engineering Contradiction:

Improvedeployability across hardware platformsVSAvoidsystem architecture complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent applies segmentation by dividing the enterprise software system into multiple independent process components, each encapsulating specific business logic (e.g., sales order processing, production planning, inventory management). These components communicate through well-defined service interfaces, allowing the system to be deployed across multiple hardware platforms independently while maintaining comprehensive functionality.

Inventive Principle:

Principle #1Segmentation

2Productivity

If software components are tightly coupled to achieve efficient interaction, then processing speed improves, but the system loses scalability and flexibility for deployment across separate hardware platforms

Engineering Contradiction:

Improvecomponent interaction efficiencyVSAvoidscalability across hardware platforms

Core Design Contradiction:

ProductivityVSAdaptability or versatility

Solution Approach 1:

The patent introduces service interfaces as intermediary layers between process components. These interfaces define standardized communication protocols that enable efficient interaction while maintaining loose coupling. This allows components to be deployed on separate hardware platforms while preserving interaction efficiency through well-defined service contracts.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Adaptability or versatility

If the software architecture is designed for high scalability with loose coupling, then deployment flexibility improves, but interaction efficiency and integration reliability may deteriorate

Engineering Contradiction:

Improvedeployment flexibilityVSAvoidcomponent interaction reliability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements universal service interfaces that can serve multiple process components across different deployment scenarios. These interfaces are designed to be platform-agnostic and can handle various interaction patterns, ensuring reliable communication whether components are deployed on the same or different hardware platforms, thereby maintaining both flexibility and reliability.

Inventive Principle:

Principle #6Universality (Multi-functionality)

4Adaptability or versatility

If comprehensive enterprise software functionality is implemented, then all business processes can be supported, but the cost of implementation and maintenance increases significantly

Engineering Contradiction:

Improvebusiness process coverageVSAvoidimplementation cost

Core Design Contradiction:

Adaptability or versatilityVSEase of manufacture

Solution Approach 1:

The patent segments the enterprise software into modular process components that can be selectively deployed based on specific business needs. Organizations can implement only the components required for their particular processes (e.g., just sales and inventory management without production planning), reducing implementation and maintenance costs while still supporting comprehensive business processes when needed.

Inventive Principle:

Principle #1Segmentation

Data Source

PatentUS8402426B2Architectural design for make to stock application software

Publication Date: 2013.03.19 SAP SE

AI summary

Methods, systems, and apparatus, including computer program products, for implementing a software architecture design for a software application implementing a make to stock process. The application is structured as multiple process components interacting with each other through service interfaces, and multiple service interface operations, each being implemented for a respective process component. The process components include an Accounting process component; a Production process component; a Site Logistics process component; a Confirmation and Inventory process component; a Customer Requirement Processing process component; a Demand Forecast Processing process component; a Supply and Demand Matching process component; a Production Trigger and Response process component; an In-house Requirement Processing process component; a Sales Scheduling Agreement Processing process component; and a Demand Planning process component.