Guest Post: Making Things Work Together Again, and Again, and Again…

(Author’s Note: This entry submitted by Dennis Drogseth, VP of Research for EMA.) I remember when I worked with Cabletron SPECTRUM 13 years ago – it was “Cabletron” not CA or Aprisma back then, which was one of our problems (SW lost in a HW company culture). But that’s not the point here. The point for this blog entry is how actually progressive we thought we were! We had a partner program with three types of integration – event-level (you forwards SNMP traps, big deal!); GUI-launch-able (integrated GUI access, no console switching); and data-level-integration, which leveraged SPECTRUM’s core modeling capabilities for capturing interdependencies and harvesting its inferencing analytics. So it struck me how much this is very much like what I’m doing (documenting, championing, worrying about) now. Now, as some of you who know me are probably aware, I spend a lot of my time working with CMDB Systems where the goal is to have a cohesive and reconciled way of sharing data across multiple management sources and systems. Not entirely unlike SPECTRUM back then, this can involve a whole host of technologies, although we’ve progressed in some serious ways. These current technologies include data replication, policy-based data access, normalization and reconciliation “engines,” etc. And now we have Web Services, and UDDI registries, and an evolving standard – CMDBf – that is getting above average traction (I know that’s not saying too much). We are also far more now in the era of ITIL, with its very astute attention to process. We didn’t talk about “trusted sources” or “management processes” at Cabletron, although we did talk (at least some of us did) about enabling better and more consistent cross-domain collaboration. But the balancing act between effectively accessing information and actually integrating it at a data level to support, potentially, more advanced analytics remains. One of the more successful options for CMDB Systems, especially in reconciling time-sensitive monitoring environments for critical CIs, is accessing data without actually replicating it or moving it. This still needs to be thought out or else it can just accelerate access to a non-sensical array of inputs. It needs to be based on policy and normalized semantics for referring to the same thing in the same way – so, for instance — you’re not calling up the same HP server by its IP address from one source and by its brand/model number by another source, or by some cute proprietary name like “Nosferatu” by another source. Actually, I’ve always thought that Nosferatu would make a good name for a problematic server. Anyway, I do think this is progress. Progress in the “21st Century Network Management” sphere in any case, because major management trends, like finding better ways for assimilating multiple management sources in a way that finally works – takes time! As I’ve often written, this slower pace is dictated as much, if not more, by politics and culture, and even by the psychology of how professionals approach their tool sets and their jobs (the two are in many people’s minds pretty closely linked), as it is about technology in itself. But I believe that we have the force of history on our side if we don’t blow it — as there are whole new groups emerging, increasingly under the banner of “service management” versus just “IT Operations,” trying to solicit input from stakeholders in different organizations to understand how they can best evolve a federated system of CMDBs and management data sources to fit multiple and diverse constituencies. In other words—it’s not about forcing people to expose everything they do and sit together naked in one big fishbowl, it’s about providing useful and diverse services through toolsets that support cohesive versus fragmented decision making. The rise of these “CMDB Teams” is perhaps the single most important innovation of all – and it’s far from a trivial occurrence. If what they’re really trying to do is successful, they may change the world even more than distributed computing did to mainframes. So don’t let this innovative new mission get buried in either a pure play ITIL initiative, or even worse, just the notion that they’re deploying somebody’s product (that happens to be a CMDB or at least calls itself one). This group uniquely combines dialog, architecture, process awareness, and unrelenting political will. They, rather than any single technology, are willing to take on the onerous task of making things work together again and again and again – as each deployment phase moves into the next, and as tangible new efficiencies, cost savings, and improvements in service quality continue to emerge.