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.