Flow-through Provisioning

“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”
Douglas Adams

Auto-provisioning is the holy grail of OSS because it is the foolproof design that allows CSPs to reduce the number of specialised network/service designers on their books and is hence easily quantifiable in a business case.

What is not so easily quantifiable is the number of stars that need to align for auto-provisioning to work on a circuit-oriented, cross-domain service. The following are but a few of those stars:

• The network must be completely and accurately modelled in the OSS
• The end-to-end service must be fully understood and modelled in the OSS
• The service order must be fully defined
• The sequence and format of all provisioning commands must be fully defined
• The provisioning engine and MDD must be fully established (ie interfaces established, then commands and responses programmed)
• Service allocation and resource checking must be undertaken programmatically before issuing the provisioning commands
• Once the sequence of activities are established, nothing in the generic end-to-end service design must ever change (refer to VPI vs VCI story about rendering an auto-provisioning engine inoperable)
• The self-service customer must enter their order data correctly
• The provisioning engine must be set up to catch any exceptions
• But most importantly, the integrity of the data in the OSS must be flawless

For connectionless services (eg mobile service activations or IN [Intelligent Network] functionality), it is usually much easier to create auto-provisioning engines than for circuit-oriented services.

But when the stars do align, auto-provisioning provides a fantastic sense of achievement.