article page | 1 | 2 | 3 | 4 |

components as pieces of data it can manipulate in different ways, according to well-defined rules.

Data-driven fulfillment does not mean that CSPs need to have a single fulfillment system capable of provisioning every possible network service and operators do not have to rip and replace existing fulfillment systems to gain the benefits of rapid product assembly. When CSPs put in place a central technical product catalogue and common fulfillment process, these can use standard middleware or proprietary connectors to talk to individual fulfillment systems responsible for provisioning and activating specific services.

Data-driven fulfillment is initially slower and more expensive to implement than the traditional silo process-driven approach to fulfillment, since CSPs will need to build a product model, populate a technical catalogue, define component assembly rules, and put in place standards-based integration mechanisms to federate multiple sources of service component data and underlying provisioning systems. The overriding benefit, however, is that CSPs will become more flexible and agile in their ability to bring new products to market, which they can do more cost-effectively and quickly.

Reducing the cost associated with launching new services is a major consideration as CSPs move into a next generation service world. Here they will generate revenue from a “long tail” of inexpensive, niche services rather than from a few, costly, generic services: inexpensive services do not justify the development of their own OSS/BSS infrastructure. Data-driven fulfillment, with its ability to support the rapid addition of new components to the technical product catalogue, and which does not require any changes to the common fulfillment process as a result, is far more cost-effective in the longer-term than traditional fulfillment.