“Resilience is accepting your new reality, even if it’s less good than the one you had before. You can fight it, you can do nothing but scream about what you’ve lost, or you can accept that and try to put together something that’s good.”
Elizabeth Edwards.
Many leading OSS products have been built around concepts that have little relevance today. They have been enhanced and enhanced by teams of highly talented developers. Depending on your perspective, unfortunately/fortunately many aspects of our industry are changing at an ever increasing rate. Resilience is a term well known in OSS for the ability to cope with failures within any components, avoiding Single Points of Failure. A less used interpretation of resilience is the ability of our OSS to not only respond to change but thrive.
Some aspects of OSS are less likely to undergo significant change. We will always need physical locations with physical devices, so these physical inventory constructs will remain similar to the OSS of decades past. However even with physical inventory virtualisation potentially introduces extra layers in the device hierarchy that may not have previously existed (eg a physical router can support multiple virtual routers on board and they may use physical resources like cards and ports in an exclusive or non-exclusive manner).
Other aspects are undergoing rapid change, including logical inventory, service types/models, revenue models, virtual circuits, multicast services, evolving routing protocols, etc. Attempting to model packet switched networks into constructs designed for circuit-oriented networks like PDH may allow you to service a customer requirement in the short-term, but it doesn’t build resiliency.
Volatility appears likely to continue to increase exponentially. Darwin’s Theory is not survival of the fittest, but survival of the most adaptable. What can you do to make your OSS more resilient?