Custom System Templates for Flexible Instantiation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing system type definitions are limited by predefined types that are not flexible enough for diverse use cases and custom types that require users to write everything from scratch.
Innovation Solution
A method for generating custom system templates by defining a manifest file that specifies properties of a system type, along with optional components like logos, policies, and assets, which are then compressed and uploaded to an authorization service to instantiate a new system type.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If predefined system types are used, then specific use cases are targeted with optimized configurations, but flexibility for use cases outside those specific targets is lost
Solution Approach 1:
The system type definition is segmented into a manifest file containing structured metadata (kind, apiVersion, version, title, description, parameters, policies, datasources, tokens, discovery, decisions, library) and optional component files (logo, policies folder, assets folder). This segmentation allows users to selectively define only the portions needed for their specific use case while inheriting or omitting other portions, achieving both customization and flexibility.
Solution Approach 2:
The system type definition becomes dynamic through the manifest file structure, which allows users to specify parameters, policies, datasources, tokens, discovery settings, decisions, and library references that can be adapted to different use cases. The system transitions from static predefined types to dynamic configurable types that can be tailored to specific needs while maintaining a consistent framework.
2Adaptability or versatility
If custom system types are used, then flexibility for diverse use cases is achieved, but the requirement to write everything from scratch increases complexity
Solution Approach 1:
The manifest file structure provides preliminary organization and scaffolding for system type definitions. Users start with a pre-defined template structure that includes all necessary sections (kind, apiVersion, version, title, description, parameters, policies, datasources, tokens, discovery, decisions, library), reducing the cognitive load and complexity of creating custom system types from scratch.
Solution Approach 2:
Users can copy and reuse existing system type definitions, policies, datasources, tokens, and library references across different custom system types. The manifest file structure enables efficient copying and adaptation of proven configurations, reducing the need to write everything from scratch while maintaining flexibility for customization.
3Adaptability or versatility
If templated system types are used, then flexibility compared to custom types is improved, but power on the UI front is reduced
Solution Approach 1:
The manifest file structure serves multiple functions: it defines system type metadata, configures policies, specifies datasources, manages tokens, controls discovery behavior, sets decision mappings, references library components, and defines parameters. This multi-functionality consolidates what would otherwise require separate UI configurations into a single structured file, maintaining flexibility while simplifying the operational interface.
Data Source
AI summary
Some embodiments of the invention provide a method for generating custom system templates to define new system types. For a particular system type, the method defines at least a manifest file that specifies a set of properties of the particular system type. The method compresses the defined manifest file to create a custom system template package for the particular system type. The method uploads the custom system template package to an authorization service in order to instantiate a new system of the particular system type.