Pieces of the provisioning puzzle

The art of simplicity is a puzzle of complexity.”
Douglas Horton
.

Consolidated service orchestration requires you to solve the puzzle of complexity and deliver a wonderfully simple, repeatable engine for your operations team.

It looks simple and it sounds simple, but the following list provides just a handful of the pre-requisite tasks you’ll need to complete before even considering building a consolidated service orchestration capability:

  • Naming Conventions – Your service designs / templatesĀ and all related service instance data has to be consistent, reliable and adhere to pre-determined conventions, otherwise the custom parsing / pattern-matching algorithms won’t produce consistent orchestration of services
  • Inventory – Your inventory database has to be highly reliable and accurate in real-time (not just after daily or weekly reconciliations) because the orchestration tools will be consuming and discarding resources on a regular basis
  • Processes – Your processes have to be well defined and capture any variants in setting up a service, as well as having exception handling capabilities for the other ones that just don’t adhere to the variants you know about
  • Workflow Engine – You need to be able to coordinate not just one instance of the process defined above, but many instances of many different processes. Your workflow engine may coordinate various types of tasks, whether manual or automated, and should track activities for every single order
  • Product / Service Catalog – This builds on the processes and makes up the building blocks of flows/activities that comprise various aspects of end-to-end services. Some service catalogs even have in-built process. This might seem very similar to the previous item, but generally a service catalog will only support a sub-set of the activities coordinated by a workflow engine. For example, a workflow engine will be responsible for all the field workforce activities like cabling, rack and stack, patching, council approvals, etc as well as the activities of the service catalog such as sending programmatic commands to network devices
  • Integration – You can only send programmatic commands and reconcile against inventory, etc if you have established interfaces with these other solutions
  • Billing – Now that you’re turning service up and down on a whim, you may need to consider how you’re going to bill – flat-rate or volumetric. If volumetric, where are you gathering the stats to bill for the dynamic allocation of resources to customers that you’ve now establish
  • BSS – Aside from billing, you also have other tools that will need to be alerted to your service activations / de-activations such as CRM, SLA/contract, service management, etc. Some of these aspects may be established at the start of the service activation process (ie before it gets to service catalogs) but they may also need notifications that services have commenced or changed
  • Adds / Moves / Changes – Don’t forget that your provisioning puzzle doesn’t just consist of activations, but also needs to consider moves, changes and de-activation workflows too
Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

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.