Drawing the Functional Boundaries on Fulfillment and Inventory

There's nothing like a spirited debate to sharpen the mind and help sort through complex issues. And over the years, the BSS/OSS market has seen its share of cerebral sparring matches: custom vs. off-the-shelf software; best-of-breed vs. integrated solutions; charging vs. billing; and service bureau vs. licensed software delivery — to name a few.

So here's a controversial topic: What's the proper boundary line between service fulfillment and inventory functions? Exactly how far should an inventory system go in modeling and maintaining logical configuration data that has traditionally resided in the service fulfillment or provisioning domain?

Well, that particular issue was a pretty hot topic 5 or 6 years ago as companies like Cramer Systems (Amdocs), MetaSolv (Oracle), Netcracker (NEC), and Granite Systems (Telcordia) championed a fresh idea at the time, namely that inventory should be given a more central OSS role and begin to control many provisioning functions.

Now, not everyone agreed with that thinking. A number of service fulfillment vendors including software vendor Syndesis, now Subex, believed in the need for a clearer separation between service fulfillment and inventory.

So we're please to have Steve Cooper, vice president of Product Management for Subex, joining us to present his side of the debate and lend his perspective on some interesting OSS trends.

DB: First, Steve, can you refresh us on what Subex is up to on the service fulfillment front? How have things changed since the Syndesis days?

Steve Cooper: Well, service fulfillment still remains our strong suit, but we've evolved our product line to solve some of the more pressing challenges service providers face. In years past, we focused quite a bit on fulfillment of broadband access services such as DSL and “Fiber to the Node” and still see opportunity in those areas. In addition, we have seen growing demand to support enterprise services like Metro Ethernet and IP-VPN.

Specifically however, IP-VPN services have been a challenge for service providers; the technology behind it is inherently complex and standards are lacking. Each of the equipment vendors more or less chose its own path to implement IP-VPNs and that caused both configuration options and maintenance costs to mushroom.

Compared to IP-VPNs, Ethernet is a breath of fresh air for service providers. First, the Metro Ethernet Forum has done a stellar job of defining the standards and ensuring their adoption. In addition, with Ethernet, it is the enterprise customer's job (not the telco's) to maintain the IP layer. So in general, Ethernet looks much cleaner with standard offerings, streamlined support and a more profitable model for providers going forward.

In the past few years, Subex has enjoyed some good success with Ethernet fulfillment as the growth of smartphones and mobile data have driven the need for mass Ethernet deployment in the wireless backhaul networks. We also see opportunity with the cable companies who are trying to leverage Ethernet to compete with traditional telecoms in the enterprise market.

DB: What's the industry’s biggest technical challenge supporting Ethernet fulfillment?

SC: The biggest challenge is getting an accurate representation of the network. Frankly there are hundreds of logical settings across many different vendors devices that have to come together for an Ethernet service to work such as VLANS, VPLS, Class of Service, Traffic Management, Ethernet QinQ framing, and other ugly stuff.

To solve this challenge, we automatically discover all the equipment, logical configuration attributes and re-create end to end services directly from the network. This ensures that our fulfillment solutions are based on a foundation of total data accuracy.

One problem service providers face with inventory systems is that they rapidly get out of sync with the actual network. As you'd expect, this causes many issues around provisioning, planning, assurance, and troubleshooting.

Then there's the damage to the customer experience. Bottom line, if the inventory system is not accurate, it leads to trouble.

DB: Steve, I know you have some strong opinions about the expanded role of inventory in OSS. What are your thoughts here?

SC: First of all, inventory systems are critical to manage the end to end lifecycle of the network including all the passive inside and outside plant and wiring. Subex supports inventory and has products such as TrueSource that reconciles the physical network with inventory.

In the past, some B/OSS vendors felt it best to migrate data from the provisioning domain into inventory so you could model and maintain the network and the detailed logical configuration data in the same place.

There were two main reasons for this shift in thinking. First, it was a time when "OSS transformation" was a business focus and there was a drive to consolidate OSS systems to save costs. Second, there was an architectural elegance to having a single place to go to retrieve data.

Well, looking back with our 20/20 hindsight, we can now say that many of the high profile, enterprise-wide OSS transformations did not meet a number of their original objectives and expectations – in some cases, resulted in major time and cost overruns.

OSS transformation projects ran into challenges because people under-estimated the costs and complexity of migrating and maintaining logical and service layer provisioning data in inventory.

DB: So what's your advice to operators? Where should they draw the line between the inventory function and service fulfillment?

SC: To answer that question, it's best to think about the traditional role that inventory was designed to play in the OSS.

Inventory basically manages the network and equipment life cycle including planning, commissioning/decommissioning, maintenance, upgrades/downgrades, testing and as well as managing spares.

DB: But taking Metro Ethernet service as an example, does inventory really need to know that you have a certain VPLS and VLAN connection and other logical configurations on a particular circuit?

SC: At Subex, we think not. That sort of data should reside is in the system that communicates with the network; the service fulfillment and provisioning system. If inventory tries to maintain that level of detail, it becomes too costly and you have trouble loading the data and keeping it accurate.

The service fulfillment system already models the service, discovers the network, and keeps track of the settings for the many different equipment vendors. As we move to a world of highly complex and more ‘logical’ services, the network itself becomes your inventory.

DB: Finally, Steve, I'm curious about your outlook for fulfillment systems? Where are the opportunities?

SC: The focus for service providers is now on the customer experience and fulfillment is a key enabler for service providers to clearly differentiate themselves in this area. The ability to rapidly bring new services and applications to market and offer them all on a web portal with immediate fulfillment is where service providers are heading.

We believe communications service providers need a top-to-bottom solution for fulfilling IP-based services over any underlying network connectivity. That solution needs to be end-to-end, carrying the service forward from the web portal order, to configuration of the network, application servers and end user devices.

The business driver to automate fulfillment has

changed from reducing operational costs (which is still important) to enabling strategic differentiation and improving the service providers’ relationship with customers.

Stephen Cooper is vice president of product management at Subex. He has over 17 years experience in telecom and has obtained a wealth of knowledge in the areas of business optimization, service fulfillment, test and verification. In his current role Steve is accountable for the forward looking direction of Subex's Product lines. Steve has earned a BASc in Electrical Engineering from the University of Waterloo, Ontario.

Dan Baker is Technology Research Institute’s (TRI) principal market synthesizer and co-founder. He is a former market analyst at Venture Development Corporation (VDC), where he tracked the telecom and real-time computer markets. In 1992 while at VDC he authored one of the first multi-client research reports on the Advanced Intelligent Network software and systems market. From 2004 through 2008, TRI sold its research reports exclusively through Dittberner Associates. Baker was the research director and principal analyst for reports in the Dittberner OSS/BSS KnowledgeBase.