“A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.”
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.