Manageability Imperatives (1 of 3): Solution Must Be Quick to Prototype

This the first in a series of three blog posts on important imperatives for network equipment provider development teams to consider when planning for, and designing on-device configuration management systems. Each post states a claim and expands on the subject with some background, context and ties it into features and benefits of our ConfD product

This post claims that Solutions Must Be Quick to Prototype.

BACKGROUND: Early prototyping is an accepted best practice for modern software development. This approach aligns expectations between the client and the developers and ensures actionable feedback throughout the project. The processes and the tools used by development teams should support this practice and allow for quick prototyping to show clients in a concrete, hands-on way, what the final product will feel like.

IN THE CONTEXT: In the network management context, this means that the team responsible for the management interfaces on the network element is able demonstrate prototype software to both to internal (e.g. product management) and external (e.g. early-stage customers) parties at a very early stage.

FEATURE: ConfD is completely driven by data models. In combination with an internal data store for configuration and operational data, this allows for full prototyping without any requirements for stub code. It is possible to show the full look and feel of all required northbound interfaces by simply writing the models and providing initialization files for example configurations. ConfD prototype implementations can function in a standalone (from the rest of the system) environment such as a demo setup or even run on a developer’s laptop.

BENEFITS: Model-driven prototyping reduces the risk of a rift between the expectations of the clients and the code that is actually being written by forcing the requirements to be concrete enough to be implemented. This approach also helps qualify the requirements and gives the clients an opportunity to better assess priorities based on real experience with the software. It is not uncommon for hard requirements to become softer when the client gets early exposure to an actual implementation. Benefits of this approach include:

  • Lower risk of “requirement disconnects”
  • Reduced investment on non-essential features
  • Rapid response to requirements from early stage customers