Zayo woes

Tue Sep 19 21:39:40 UTC 2023

It can be even less customer-facing and more entrenched than that…

A uses ISIS and MPLS, B uses OSPF and native circuits.

Putting (e)BGP sessions across the border between those two is pretty quick and easy. 

Integration would essentially require shifting one system onto the other methodology and is neither trivial,
nor fun and either direction of shift is equally problematic.

Owen

> On Sep 19, 2023, at 12:35, Brian Knight via NANOG <nanog at nanog.org> wrote:
> 
> On 2023-09-19 09:41, Matthew Petach wrote:
> 
>> On Tue, Sep 19, 2023 at 7:19AM Mike Hammett <nanog at ics-il.net> wrote:
>>> [...]
>>> I've never understood companies that acquire and don't completely integrate as quickly as they can.
>> Ah, spoken with the voice of someone who's never been in the position of:
>> a) acquiring a company not-much-smaller-than-you that
>> b) runs on completely different hardware and software and
>> c) your executives have promised there will be cost savings after the merger due to "synergies" between the two companies.
>> ^_^;
>> Let's say you're an all J shop; your scripts, your tooling, everything expects to be talking to J devices.
>> Your executives buy a company that has almost the same size network--but it's all C devices running classic IOS.
>> You can go to your executives and tell them "hey, to integrate quickly with our network and tooling, we need to swap out all their C gear for J gear; it's gonna cost an extra $50M"
>> The executives respond by pointing at c) above, and denying the request for money to convert the acquired network to J.
>> You can go to your network and say "hey, we need to revamp our tooling and systems to understand how to speak to C and J devices equally, in spite of wildly different syntaxes for route-maps and the like-it's going to take 4 more developer headcount to rewrite all the systems."
>> The executives respond by pointing at c) above, and deny the request for developer headcount to rewrite your software systems.
> 
> Never mind C vs J, the difference in supported features alone is enough to cause heartburn. Example: the acquired company supports and offers E-LAN service; the acquiree doesn't. From a systems perspective, the acquiree has no way to track those without dev effort.
> 
> And I guarantee IT's #1 focus is not generating route maps or interface config. They're focused on processes and reports for the money people. If the engineering org has no developers, you're either running parallel or you're in for some long nights.
> 
> 
>> The general result of acquisitions of similar-sized companies is that the infrastructure runs in parallel, slowly getting converted over and unified as gear needs to be replaced, or sites are phased out--because any other course of action costs more money than the executives had promised the shareholders, the board, or the VCs, depending on what stage your company is at.
>> Swift integrations cost money, and most acquisitions promise cost savings instead of warning of increased costs due to integration.
>> That's why most companies don't integrate quickly.  :(
>> Matt
> 
> -Brian