All together now
On the first blog of the “Design Use Cases” series, I covered change in the form or add or replace technologies, services and applications. In this blog I’ll cover Merge and Divest use cases.
It’s the collision of two worlds with different cultures, processes, tools, technologies, applications and services which will not only have to coexist but also to enable the vision that created the merger in the first place. Common drivers are acquisitions and joint ventures.
It’s the opposite of the merge, the split of one world into two pieces, typically driven by a spin-off or the selling of a company’s business unit.
Network design considerations
How does merging or divesting affect network design? These are some considerations:
- Who’s the boss: Although not a network design consideration per se, identifying who ultimately is in charge will be key to getting proper requirements and constraints for the future state of the merged or divested network and avoid getting confusing or conflicting information that can be harmful for the design project from the get go.
- What to keep: First things first, you have to thoroughly understand the current state of the networks (which can be on someone’s head, the current documentation or you’ll have to discover yourself). It is very likely there will be some overlapping technologies, services and/or applications however, what is almost guaranteed is that there will be differences in them including how the two networks are built, ran and managed. It’s important that the teams from both sides come together to outline which equipment (and vendors), technologies, services and applications that will be maintained - some may be mandated. Your design should make sure that connectivity between the two networks is established very quickly (I didn’t say perfectly, did I? ) and loops, conflicts (IP address space is a common one), interoperability, stability issues are quickly identified and resolved. The detailed design and migration will normally come on a more planned way at a later time.
- What NOT to keep: Identified the overlapping technologies, services and applications, a decision will be made on what to phase out. Your design should ensure that any required underlying technologies, connections or tunnels are in place to ensure nothing breaks, and that a migration or phase out plan is in place to avoid impact on the operations of the merged or divested network.
Merging and divesting networks are common yet challenging design use cases, mainly because of the extra human interactions required and the added complexities of having to deal with the integration or tear down of two different network “philosophies”.
Do you consider what it takes to successfully merge or divest networks on your network design projects? Is there a topic you want to hear about on my upcoming blogs? Add it to the comments below!
Elaine Lopes is the CCDE and CCAr Certifications Program Manager and Team Lead for the CCIE program team, and she’s passionate about how lives can change for the better through education and certification.
Here are a few additional ways for us to engage and keep the conversation going:
- Cisco Learning Network CCDE Study Group
- Connect on Twitter too
- CCDE study materials for the Written and Practical exams
- Related Unleashing CCDE blogs: CCDE: Design Use Cases - Part 1, CCDE: Design Use Cases - Part 3, CCDE: Book of Questions, CCDE: The Pillars of the Earth - Part 1, CCDE: Come Together, Customer Engagement in Network Design with Emanuel Lipschütz