This is the final post in a series for product managers at network equipment providers. Each post discusses the PM’s role and considerations in planning for management interfaces in new networking products.
Though they are often relegated to an afterthought, management interfaces play a critical role in the success of your network products. For product managers who understand the value of addressing manageability challenges early in product development, the next question usually is “Should our developers build software to manage configuration or should we buy it?”
Almost always, this decision resides with the development team. And developers will have a laundry list of reasons why they should develop the configuration management themselves. While it might be fun for developers to build the management capabilities, it’s a risky concept for the PM driving the product. You need to focus your development resources on features and functionality that will differentiate your product, while reducing risks.
It’s not a matter of if your developers can build the configuration management software, but rather if they should. The decision to build or buy comes down to whether your development team would be wasting effort reinventing a management framework. Things to consider include:
- Whether your network equipment or device be easily configured and monitored
- If your roadmap includes new functionality, management interfaces or platform changes
- If you built the embedded management layer and if it is well documented, robust, reusable and carrier-grade
Developers are rarely afforded the time to build a protocol-independent architecture to support future needs. The effort to do so is also frequently underestimated, but missing market windows is not the only risk. Whenever you’re dealing with homegrown software on the device, you’re also accountable for the quality. The problem is you’re relying on one person with knowledge of that software.
Using a third-party management layer not only takes this development off your product’s critical path in terms of meeting market timeframes, but it also formalizes risk in the liability statements of a vendor contract. There is also shared risk and you get to leverage an entire community of people who have worked out the wrinkles.
In-house development certainly has its place and there are instances when it’s the best bet. But when you’re facing a changing landscape of SDN, virtualization and network programmability you need to reduce risk and accelerate time to market. A flexible third-party management layer is a great way to give your development team the freedom to focus on true differentiators.