I remember many years ago, working for a large American bank when they went through an exercise to change their IP address ranges throughout Europe. Despite the best efforts of the project team, the task was an absolute nightmare. Not so much the actual address changes throughout every European site – that went fairly smoothly – but the sheer man-effort required around the clock to re-configure the many element management systems scattered across the campus. It took almost a week to re-configure everything, and for almost three weeks after that, we were still mopping up mistakes, mis-configurations and syntax errors. Before these errors were rectified, we (the group that I was part of) missed network faults and missed SLAs, and we were suffering from silent failure (not that I knew what that was back then). The department’s name was mud; it took months of effort to restore confidence in the network management team, and we created a function whose sole purpose was to maintain configuration files throughout the company. I just remember thinking that there must be an easier way to do this.

Several years later, working for a European systems integrator, I designed and built a remote network management system. Key to the success of this system was its ability to monitor change; I was very aware of the pain of that experience with the American bank, and I designed this new system to reduce this kind of pain. But, every time a new customer was added, there were still many weeks of frenetic activity before a service could be commissioned. Despite my best efforts, I was still slave to the sheer number of configuration files that required updating every time a network was added, or something changed in a given network. I could automate the heck out of many parts of the system, but there were still situations where manual intervention was required, and these were always the most contentious times.

If I were tasked with doing the same thing again, my criteria when choosing the right tools would be massively different; I would be looking for a system that used a single language throughout, required minimal intervention to get up and running, and one that would let me re-use configuration files time and time again. This last part would allow me to deliver similar services to multiple customers. People who have worked with me in the past will remember me banging on about “light, generic and elegant” systems.

I’ve finally found one.

RiverMuse has developed the concept of Transportable Business Logic (TBL). This, in essence, is a method of configuring how the various components of the Pro product respond to Alerts from any system or device. Written using a simple yet eloquent meta-language called RiverMuse Object Definition Language (or RODL for short), TBL is object oriented in approach, and is completely device-agnostic. So, if a host changes name or IP address, RiverMuse Pro simply adapts to the change (without the risk of silent failure – see above) and the business logic remains intact.

And, because of the structured nature of TBL, I can take any object file and load it on any number of RiverMuse implementations, and it will always work — truly transportable. If I were a reseller of RiverMuse and other related products, my value proposition would be to reduce the time to value through the RMOs I had written around integrations between these products.

The possibilities are endless; what if I could create RMOs and post them in an Apps Store of some description? And what if I could buy and download RMOs for specific functions created by other RiverMuse users? At the end of the day, experience is best shared, so why should I have to re-invent the wheel every time I come across a new (to me) piece of equipment, system, application or condition? The chances are that somebody out there has already been through that experience, so I could benefit from their knowledge. Light, generic and elegant.

Try for yourself. Download RiverMuse Pro free for 30 days and check out Transportable Business Logic.

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.