[163118] in North American Network Operators' Group
Re: Inventory and workflow management systems
daemon@ATHENA.MIT.EDU (Justin M. Streiner)
Mon May 20 11:38:14 2013
Date: Mon, 20 May 2013 11:37:51 -0400 (EDT)
From: "Justin M. Streiner" <streiner@cluebyfour.org>
To: NANOG list <nanog@nanog.org>
In-Reply-To: <CAL9jLaZHK-_qGbmoT3dHsD+us+GETR77upFsLWusY=SBZPSZmA@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
