One of the great opportunities that came from being a JavaOne exhibitor was the chance to meet a variety of people: everyone from business managers to day-to-day developers. Many had a story to tell about their dev-to-ops problems.
One visitor to our booth introduced me to two acronyms I hadn’t heard before but they certainly reflect the philosophy that drives the development of our open source software projects. When guiding him through the demo of our Workbench CMDB tool, he pointed out that was the “WIRSB” aspect of our tool. Next when I showed how our execution framework and automation modules were driven by the CMDB data, bringing the environment in line with the model state he exclaimed that was the “WIRI”.
WIRSB? WIRI? These were two acronyms that were new to me and I stopped and asked him what those meant.
WIRSB: What It Really Should Be
He explained how a tool that changed the state of an application – either its topology, configuration, or runtime state – should be based on an integrated model. This model should include information about the machines, software packages, essential configuration settings, as well as, a model for how the change will actually be done. It’s the specification for how things should be.
WIRI: What It Really Is
With the specification described by WIRSB in hand, one can imagine that management tools should be able to compare the current reality to the idealized form described by the specification. Difference represent cases of non-compliance. Additionally, it should be the job of other management tools to transform the environment to match the specification.
The ultimate goal is a minimal difference between WIRSB and WIRI pictures at any point in time. If you look at emerging next generation solutions, they each seem to incorporate the paradigm of WIRSB vs WIRI to some extent. Solutions that don’t adopt this paradigm will eventually become scaling bottle necks that really do slow down innovation.
Of course, anyone familiar with model-driven architecture will perceive this WIRSB/WIRI idea as the same concept. What I found encouraging is this thinking is penetrating into the operations world, too. Perhaps we are seeing an evolutionary step away from traditional administration tools that too often assume a two dimensional static state, or the
stone axes hurriedly made in house.
Maybe the end state is a graphical tool that allows a service operations manager to define the WIRSB model. The management tools would then be driven by the model to transform, maintain and monitor the environment, always ensuring that WIRSB == WIRI.