Order Management in Converging Environments

Last week I visited the TelemanagementWorld conference and with Andreas and John we did a session to explain why the Order Management API is perfect for converging environments like Telco, Cable, ISP, Mobile. The presentation can be downloaded from the TMForum web-site (session SYS33). But, because it is only accessible to TMForum members or a visitors of the conference, I’ll provide a summary below.

Convergence in the Communication Service Provider industry (Telco, Cable, ISP, Mobile) is taking place from 3 dimensions:

• Industry: Telco, Cable, ISP, Mobile operators are merging or broadening their offerings.
• Technology: Fixed Line, Mobile, IP
• Services: Voice, data, video, presence, messaging services are being offered by all industries

From these 3 dimension we derived a number of requirements that are specific to Order Management and checked/explained if the Order Management API imeets these requirements.
For the Industry dimension it is important that the API is not limited to industry specific products and interoperability between systems is important. Furthermore order management systems must be very scalable because the increasing number of subscribers, increasing number of offerings, marketing actions, etc. will lead to growing number of orders being processed. Especially when you take into account that one product order may break down into multiple service orders, which may break down into multiple resource orders. The Order Management API meets these requirements because it is based on industry standards like JavaEE and some of the WS-Standards. Using these standards you can build scalable and interoperable systems.
The API does not define any product specific details, just the abstract concept of a product and the extensibility options to define your own product details. In this way the API is not limited to any particular set of products.
For the Technology dimension it is (just as with the products) important that the API is not limited to any particular technology. And as you probably expect, it can be used for Fixed Line, Mobile, IP and other (currently maybe even unknown) technologies. There is no limitation in the API. The speed at which an order can be processes may very per technology. For example, for mobile phone you may walk out the shop with a fully operational device, for IP it might be needed that a modem is shipped to you before the IP service can be delivered and the order completed. The latter is a process that could take days or weeks. Therefore long-running transactions for these orders should be supported and these are supported. The Order Management API can also be used as an abstraction layer to create a consistent interface to legacy/silo order management systems. To facilitate this, the model for orders and order states is extensible and there is support in the API to query meta-data (for example which orders or order states are supported by this implementation).
For the Service Dimension there cannot be limitation on the types of services. Just as with the previous two dimensions there is no limitation on types of service orders supported, the model is extensible. The service offering will typically be stored in a catalog and to process orders for a particular service the order management system needs the details of those service definitions and will need to store details of activated services in an inventory. For this the API provides an easy integration with the Inventory Management API. This API can be used to manage the catalog and inventory. The Order Management API itself does not define how catalog/inventory should be managed. The speed at which service offerings change is constantly increasing, therefore it is important that the API can easily support new service definitions without changes to the API. This is supported by the Order Management API by using the Characteristics concept that is defined in SID and OSS/J Common API.
Other cross cutting capabilities that are relevant for convergence are:

• The fact that the API provides one consistent interface for various types of orders (Product, Service, Resource, Work), learn the API once and you can apply it to different domains.
• It integrates easily into a SOA, see previous blog posting.
• There is support for stand-alone and related orders (relevant for example for bundled products).
• And much more that is less relevant from a convergence perspective, see for example this blog posting.

So in summary the Order Management API is can be a great help to converge your legacy or silo-ed order management systems to a consistent, flexible, scalable, standards based order management system.