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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.