nanog mailing list archives

Re: Inventory and workflow management systems


From: "Justin M. Streiner" <streiner () cluebyfour org>
Date: Mon, 20 May 2013 11:37:51 -0400 (EDT)

On Mon, 20 May 2013, Christopher Morrow wrote:

I haven't looked lately to see what's out there, but I'd imagine there *has*
to be something.

I bet this is a market/cost thing... there are ~100 people who want
this? it's going to take a few million in SWE resources to build, and
probably recovery of that expense is going to be difficult :(

True, and would explain why the systems I've seen tend to be very expensive.

I have taken a look at netdot from UOregon, and it looks like it has lots of nice features and an active development community. The main thing there is I need to really sit down and see how painful modifying the default DB schema will be to capture some of the fiber plant data I need, and preventing that all from getting blown away by the next cycle of software upgrades. Tying it into some other back-end systems we already have is another challenge that I really haven't had time to dig into yet.

I can understand why many telcos ended up building their own systems,
because many of them use(d) different or home-grown
provisioning/billing/plant management/trouble ticketing systems, and
different back-end systems in general, making a one-size-fits-all solution
tough to do.

this MOSTLY gets to the ins/outs formats, right? 'billing system at
$TELCO requires CSV output' (or something) and telco folk don't always
like to think about 'standards'.

That, and there can belots of general compatibility issues. Something like:

The provisioning system is running on an old VAX mainframe, and $PROGRAM expects CSV with CR-LF, rather than just CR, but the billing system is built on a DB2 database on an IBM mainframe and doesn't know how to output the data in an acceptable format. A lot of it is probably centered around software engineering/DBA tasks, often requiring people with lots of institutional/legacy knowledge to get the appropriate pieces talking together correctly. In some cases, those people are no longer around, and consultants with the right skills (and often a pretty hefty hourly rate) need to be brought in.

I would imagine that's why some of the telcos that went on acquision binges during the dot-com boom (coughcoughworldcom ;) ) never fully integrated the back-end systems of those acquired telcos into their own, even though it does/did make like more painful for their customers and their own ops people. Example: "Oh wait... that's an MFS circuit. I need to get into a different system to look at that..."

jms


Current thread: