While watching an episode of Star Trek the other day, the opening title sequence in which Captain Kirk narrates, “These are the voyages of the starship Enterprise. Its five-year mission: to explore strange new worlds…to seek out new life and new civilizations…to boldly go where no man has gone before,” got me thinking.

Why was the Enterprise only exploring and not discovering strange new worlds? The answer in fact provides a great analogy as to why exploration and not discovery is right for dynamic infrastructures. The Enterprise only had five years in which to explore strange new worlds. If the crew spent too much time discovering one planet and its inter-relations with nearby planets, their explorations would be limited, and more often than not, changing relationships between planets would mean their discoveries would be outdated.

In dynamic infrastructures, the details as to the nature of an entity, what the entity is connected to and how this connectivity widens to encompass relationships with other entities is not just a one-way conversation. In fact, it would take significant amounts of time to discover such a set up. Also in modern networks the connectivity is so fluid, any connectivity discovery would be quickly out of date and subsequently useless.

With the RiverMuse central discovery manager process (topod), a collection of Explorers and Embellishing Agents just go out and create the raw presence, or add information about a known entity in the network. So by coupling a definitive list of ‘what is out there’ with the configuration of a network management system in an object orientated way; thereby, defining logically the things you do every time you come across an ATM switch, or a router, or a server, you can automatically create the running configuration for a network management system.

Also, if this definitive list of ‘what is out there’ is dynamic, as the network changes you can automate the creation of the definitive list of that configuration.

In short, if there are ‘N’ entities in a system, discovery is an ‘N2’ process, as you have to talk to each entity, and then to each of the entities that it is connected to, whereas exploration only involves interrogating each entity in turn. Exploration is much faster than discovery, and in a modern enterprise that can mean the difference between a current and up-to-date configuration and one that is obsolete before it is complete.

Captain Kirk had five years; our customers must explore their universe in five minutes!

RiverMuse PRO includes a Reusable Business Logic (RBL) engine to streamline the creation of all configuration components in a single reusable package.

The configuration is loaded through a text file; it is then parsed and converted by a back-end engine that updates the configuration of multiple components within the RiverMuse product. This is a vast change from traditional Manager of Managers (MoM) solutions as configurations from multiple components are incorporated in a single configuration.

The RBL engine serves to:
– Map organizational processes into the product through one configuration channel
– Fuel the creation of a community driven repository (aka App Store). Configuration packages can be shared or bought. (i.e. a configuration package for grouping events by event type, and performing isolated problem correlation; a configuration package for interpreting Cisco alarms and integrating with Cisco inventory tools to populate RiverMuse dynamic variables).

RiverMuse PRO also incorporates a presence management engine that can discover entities on demand.

This is most useful when new alarms are reported for devices/entities not yet present in a CMDB or inventory management system. A RiverMuse Business Logic Package can first lookup Configuration Item information from the CMDB, and if nothing is found, attempt to perform a discovery using the RiverMuse Presence Management System. This will provide many additional variables that can be leveraged through correlations, automations, and escalations.

RiverMuse PRO includes a centralized rules management wizard.

Whether there are 1 or 50 remotely deployed collectors, rules are configured in a central location through a GUI. Within a traditional Manager of Managers (MoM) solution, the process of obtaining events, performing correlation, and providing business context are usually separate and distinct. Legacy MoM architectures typically require business logic rules to be updated at various levels and multiple components within their system and frequently using different, proprietary scripting languages. This creates a management challenge – and makes it hard for operations teams to keep up with infrastructure shifts.