To Configure or not to Configure…

Posted on: 9th March 2012

…That is the Question. Aria Networks CEO, Tony Fallows, asks whether it is better to select a system which is upgraded by the vendor or one which is configurable by the customer.

Aria has built a configurable Capacity Management system. A key question is whether this gives a better strategic platform and improved life-cycle ROI, than a planning system that is not configurable, offering fixed, out-of-the box functionality.

To set the scene, the following defines Aria’s aims and intentions of configurability with respect to our Capacity Management system.

  • To consider the full economics of capacity management – both CAPEX and OPEX
  • An agile system, to quickly amend or add new services, equipment and link types and capabilities
  • Flexibility to run varied ‘what-if’ scenarios
  • Cater for varying degrees of data availability – from simple spreadsheets to fuller inventory imports
  • To enable reports and data export to suit the needs of the integration environment or the users
  • To enable resource consumption policies to be under the control of the users, and not to be dictated to by hard-coded limits of system
  • To provide a system that supports the needs of the expert who wants to control/change the processing, as well as the operational user who wants simple automated steps

It should be kept in mind that Aria’s solution is a commercial-of-the-shelf product with a high level of out-of-the-box capability. Its configuration complements extends that out-of-the-box capability and ensures the future viability of the solution as the telco environment changes.

Is the option to configure or fixed functionality supplied out-of-the-box preferable? Several questions need to be asked.

Q. What is the expected life-cycle of the Capacity Management system?

For the purpose of this debate, we shall assume that an enterprise perpetual software license is used for 7 years (although it may be written off from a financial perspective typically over 5 years, and many systems are used for longer periods).

Q. During the expected life-cycle of 7 years, what can I reasonably assume will change in my network?

  • Will I change one or more hardware vendors that I use to provide devices?
  • Will a device have new line card or port capacities?
  • Will my devices have new or upgraded logical capacities that I need use and plan for?
  • Will I introduce new protection and resilience mechanisms?
  • Will I introduce new technologies to enable a large step-increase in link types or speeds?
  • Will I introduce new architectures and reroute traffic?

Q. During the expected life-cycle of 7 years, what can I reasonably assume will change from a demand or service point-of-view?

  • Will I be introducing new service types or adjusting service policies?
  • Will I be asked by sales to respond to large bids for bespoke B2B opportunities?
  • Will I need to introduce new service derivatives, offering a variety of QoS and SLA options?
  • Will I be asked to determine the impact and ready the network for the introduction of new data-intensive devices?
  • Will I likely see an increased shift towards services that have multiple end-points or require lower delay characteristics?
  • Will I need to better understand and route traffic to local content, CDNs and/or cloud providers?

Q. During the expected life-cycle of 7 years, what can I reasonably assume will change from a process point-of-view?

  • Will I need to change operational use-cases due to changes in business policy, finances or other KPIs?
  • It is likely I will want to evaluate the future mode of operation of a new architecture to predict the impact on traffic, QoS and cost savings?
  • Will new element management, performance management, system-assurance, service fulfilment or inventory data sources change over the next 7 years and as a consequence would I need to change the planning processes, data models or data integration?

Real-World Examples

A tier-1 operator required a new broadband service to be introduced that supported the delivery of TV content. The capacity planning use-case scope included all network components from the multi-service access nodes, a switched Ethernet backhaul and aggregation infrastructure, a core network comprising optical WDM and a routed IP network, as well as the required BRAS components. The architecture utilised several protection and resilience schema. The customer’s key objective was to determine the cost and optimal equipment and link inventory to meet increased customer uptake of the new broadband service. In a head-to-head Aria’s solution was configurable in less than 1 month, while the competitor’s estimates to code a solution was 15 months.

In a similar case, involving a mobile operator, the introduction of four new equipment models by Aria took less than two weeks, while the competitor estimated 9 months to code a solution.

To Configure or not to Configure?

If you have answered “yes” to any one of the above questions, it could render a non-configurable planning system as temporarily or permanently obsolete. You would then find yourself with a dependency on the system vendor’s future roadmap, current development load, and software release process. Not to mention the fees that the planning system vendor will likely impose on your change requests. During which time, you may need to make a decision to either delay the cause for change, revert to a manual process. In either case it will cost you money:

  • If you defer a service introduction you will lose revenue
  • If you defer introducing new equipment, you will incur increased CAPEX (on the assumption you are introducing that new equipment as it is more cost effective than using existing equipment)
  • If you revert to manual planning, it requires more scarce and costly manpower

Summary

While a configurable system will rely upon either the users or an administrator to be able to configure the system as your environment changes, it puts you in control of your destiny. It gives you the option to configure the system to meet your immediate demands, and thereby reduce your dependence on the system vendor’s roadmap. You can introduce new services, new equipment, new use-cases, new processes and new systems, safe in the knowledge your planning system is not obsolete and not subject to large upgrade costs and implementation delays.