* What replaces the traditional framework?
Nobody talks about buying a “framework” anymore. (If you are, I’d love to hear about it.) That might be largely because vendors stopped using the term themselves when “frameworks” became synonymous with endless deployment cycles. But our consulting and research indicate – and logic dictates – that if you don’t want to default to an all-point-product approach, you need to invest in something like a framework.
What IT rightly seems to be moving toward is a “central point of automation and integration,” for, at least potentially, multiple products from multiple vendors. That’s a lot different than the frameworks’ total philosophical and monetary commitment to a single brand that, in the past, offered very little in the way of real integration and almost no satisfactory levels of automation.
“Platform” is a far more neutral word, and considerably less territorial than “framework” in nature. There are lots of ways to slice and dice platforms – most commonly by domain (network management) and by discipline (fault management, performance management, configuration management, etc.). So one thing that’s cropped up in the wake of real frameworks has been a kind of ad-hoc embracing of a few chosen platforms.
The assumption is that these platforms will be easier to deploy, more functionally rich and more effective than all-or-nothing frameworks. Of course, while this is not universally true, it’s true enough to make the “multi-platform” approach seem viable, at least as a near-term compromise. Each platform may, in itself, become a point of integration for more narrowly focused point products – and this, too, is a not a bad trend.
But what we’re left with today is a lot of “halfway there” answers – a balance of all-too-often unsatisfactory compromises. Many platforms really aren’t all that deployable, and investing in multiple platforms may only add to that burden. Management software is getting more expensive and complex, and at the same time management challenges are becoming more demanding and complicated, as well.
There are industry and technology trends coming to the rescue. One can only wish that they would come at a faster pace. And there is a new way of defining “platform” or “framework” choice – and that’s the Configuration Management Database (CMDB). Based on IT Infrastructure Library’s notion of a central, trusted data source to support virtually all management disciplines, the CMDB is, by its own definition, a central and necessarily dynamic source of integration and automation. It includes dynamic and current insights into topologies, application service interdependencies, current configuration states and current software. It is designed, or at least should be, to support process automation in support of policies directed at compliance, IT governance, and operational efficiencies.
So, is the CMDB the heart of the next-generation “framework”? Logically, the answer is yes. In reality, it’s much more of a puzzler, as the market evolves in its own sidling and often self-contradictory fashions. And, of course, the jury’s out on whether CMDBs can be made to work – at least in the holistic, “framework,” sense. Most successful CMDB implementations to date are targeted at more of a subset of possible functions and are linked to best-practice process initiatives, as well. And of course the CMDB is just an enabler – having one buys you, well, nothing, if it isn’t used to support specific management processes and applications.
Nevertheless, aside from sheer “brand loyalty,” which has never been a particularly overwhelming force in the enterprise management marketplace (probably a good thing) – selecting a core CMDB provider may be, or become, about as central to making a framework decision as you’ll ever get. That’s my opinion, but now consider this last sentence a question. What do you think? Let me hear from you at mailto:drogseth@emausa.com
