Service Delivery Framework Application Objects
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional service delivery models in telecommunications are inefficient, requiring lengthy software development cycles, high costs, and poor integration between services, leading to unprofitable operations, especially when usage is low, due to system duplication and poor interoperability.
Innovation Solution
The introduction of a Service Delivery Framework (SDF) utilizing Application Objects (AOs) based on an Application Component Model (ACM), which combines Graphical User Interface (GUI) and Service Oriented Architecture (SOA) programmatic API functionality into an object package, enabling rapid creation and deployment of customer-facing service offers through a portal framework and Interactive Development Environment (IDE), allowing for configuration, management, and monitoring without specific portal integrations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional service delivery models are used with system smokestacks and custom OSS/BSS development, then service-specific functionality can be achieved, but development time is lengthy (9 months from conception to deployment) and costs are high
Solution Approach 1:
The system segments service delivery functionality into reusable Application Objects (AOs) that encapsulate specific service capabilities. These AOs are composed to form complete service offers, replacing the monolithic traditional development approach. This segmentation enables independent development, testing, and reuse of individual service components, dramatically reducing overall development time while maintaining service-specific functionality.
Solution Approach 2:
The system performs preliminary action by pre-building a library of standardized Application Objects that can be immediately reused for service creation. Instead of developing from scratch for each service, the framework provides pre-configured AOs that can be quickly assembled and customized, reducing the 9-month development cycle to a fraction of that time while preserving adaptability.
2Adaptability or versatility
If traditional service delivery models with complete smokestack solutions are used, then comprehensive service functionality is provided, but system duplication occurs and interoperability between services is poor
Solution Approach 1:
The system applies universality by creating a shared library of Application Objects that can be used across multiple different service offers. Instead of each service having its own complete smokestack, the same AOs are reused across services, eliminating duplication while maintaining comprehensive functionality. This multi-functional approach allows a single AO to serve multiple service contexts.
Solution Approach 2:
The system merges previously separate service-specific systems into a unified framework where multiple services share common infrastructure and components. By combining individual service functionalities into a shared pool of AOs, the system eliminates redundant systems while preserving the ability to deliver complete service functionality through strategic composition of these shared components.
3Adaptability or versatility
If traditional service delivery models are used, then custom OSS/BSS development can be performed, but hardware and software utilization rates are poor and the cost of product failure is high
Solution Approach 1:
The system enables self-service by allowing service offers to be constructed through configuration and composition of existing AOs rather than requiring custom development for each service. This self-service capability maintains adaptability while dramatically improving resource utilization, as the same infrastructure and components serve multiple services simultaneously, reducing waste and lowering failure costs.
4Productivity
If Application Objects combining GUI and SOA API functionality are used, then rapid service offer creation is enabled, but requires an Interactive Development Environment and standardized frameworks
Solution Approach 1:
The system introduces an Interactive Development Environment (IDE) as an intermediary that simplifies the complexity of working with Application Objects. The IDE provides standardized interfaces, visual composition tools, and automated generation of service offers from AOs, making the powerful AO framework accessible without requiring developers to directly manage the underlying complexity. This intermediary enables rapid productivity while managing framework complexity.
Data Source
AI summary
A method of aiding creation of a service offer associated with a Service Delivery Framework (SDF) includes providing a plurality of reusable Application Objects (AOs) that may be associated with an Interactive Development Environment (IDE). The AOs are prototype customer facing service offers that include standardized functions supporting ordering, billing, management and monitoring. The AOs also include standardized event formats and configurable attributes that affect the behavior and pricing of service offers derived from the AOs. A Services Marketplace facilitates reuse of AOs and supports relationships between customers, application creators, service providers and OSS/BSS providers. A computer-readable medium includes instructions that when executed by a computing device aids in creation of a service offer associated with a SDF by providing a plurality of reusable Application Objects (AOs) in the context of a services marketplace.