There are many variants on the above responses but if you look at each in turn, they have one common element – the introduction of multiple vendors will require more software integration testing by the service provider (and higher costs in this area) than in a single-vendor solution that has been fully verified by the vendor. Fortunately, architectural tools are available that can help right-size the required amount of pre-deployment testing of a multi-vendor solution with a well-defined business objective.

The need to balance openness with cost of interoperability

None of the business objectives identified above were ‘Our plan is to introduce an open interface for each specific part of my network and then make huge investments in time and money trying to integrate all those open APIs into a deployable solution’.  That would be counter-productive!

There is an important difference between an architecture which defines all possible dimensions of openness and an implementation which is aligned to business objectives enabled by an open strategy.  The following axiom is useful to remember when implementing an open solution: ‘The more open interfaces you have, the slower and less agile your implementation’.

No amount of standardization will replace network interoperability implementation testing. Every network operator has unique requirements for geo-redundancy testing, feature and functionality testing, security testing, etc.  In addition, no networking standard is truly ‘plug and play’ – although certifications do help.  Fundamentally, the more points of integration introduced into a solution, the more testing, release alignment, user training and other ancillary tasks must be performed prior to deployment. Each time a new release is to be deployed, the full cycle of testing must be repeated, further driving costs, and slowing deployment velocity.

This does not mean open networking cannot be deployed; however, it does mean that a focus on business objectives to guide the implementation will pay back hugely when moving from the lab to production.

Assessing the trade-offs

Let’s use an example from our previous goals to illustrate the point.

• Business goal: Business continuity through supply chain diversity for DWDM transponders
• Technical requirement: Introduce another vendor’s transponder over an existing Open Line System (OLS)

Figure 1 shows two potential open optical implementations which are equally capable of achieving the business and technical objectives.  The choice of the implementation will drive the cost and velocity of deploying the solution.

Figure 1: Trade-Offs of Different Open Optical Deployment Models

The open deployment in ‘Model 1’ has four open interfaces from the Optical Domain Controller, one to each of two transponder vendors, one to the Open Line System (OLS) controller and one to the open planning tool.   This model will provide all the dimensions of open interoperability required by the business objective.   The alternative shown in ‘Model 2’ is much simpler and focuses on the open interfaces required by the key business goal (open transponder deployment) and leaves the remainder of the architecture as a vendor integrated solution.  Both models meet the business and technical objectives. The trade-offs are obvious – one model has significant systems integration costs and timeline challenges whereas the other model opens up key dimensions of the network, while controlling timelines and costs.

Intelligent network control pulls it together

Software control architectures have evolved to the point that multi-vendor infrastructure elements can be controlled cohesively, with increased automation. This has broadened implementation options while maintaining a unified management interface. Both models above require an Optical Domain Controller with open APIs to automate multi-vendor lifecycle operations. Yet the functionality of the Domain Controller in Model 2 is much more expansive, eliminating the need for time-consuming and costly interoperability testing. Such capabilities build on Software Defined Networking (SDN) industry standards with additional advancements for integrated planning and analytics, bringing intelligent network control to optical operations.

Open standards in optical networks are essential for continued progress as service providers seek to satisfy market demands while meeting business goals. There is no single solution which will satisfy every deployment; however, asking the right questions up front will ensure the delivered business outcomes are the ones you want.