As part of my job, I have been reviewing quite a few products for the internal IT market. (Again, for newcomers to this blog, the concern here is not for our business customers, but rather for enterprise IT's own internal processes and the automation solutions being proposed for them.)
The common denominator among every single one of these vendors is they all are building their own repository, usually based on SQL, and with their own proprietary data model.
I have done a detailed analysis of several such data models for such tools, and continue to be dismayed by the huge overlaps. One reviews an asset management system from company A and finds it has a nontrivial incident management capability baked in, as does the change management system from company B, while the configuration management solution from company C has a little bit of everything. All have their own tables for key enterprise IT reference data such as location, calendar, and staff, none of which IMHO should be sourced in any such application (such data should have well-established enterprise masters). This is not to mention core information such as server, component, system, and business process, all of which needs to be easily interchangeable.
So, we are pushed into buying such solutions, and then the IT capability winds up with the same integration headache we've been solving for our clients for years. If you're lucky, there is an app server or at least a library with a public API. If you're unlucky, dual entry or maybe you can hack the tables and cram stuff into them (risking vendor support). And even in the best case scenario of a robust public API, you still have to figure out its semantics and map the source to target. If you want a canonical publish/subscribe representation -- what then?
Well, one answer would be to use the OMG's XML Metadata Interchange as your canonical format between such tools. But this raises an interesting question - why don't the vendors just support XMI as a common i/o format? This might actually have some radical consequences, the end result being I think the commodification of the repository capability. If every repository simply understands XMI, and supports specific key models such as the definition of systems, components, and their deployment to nodes - that's a huge part of the problem domain right there, that no longer needs to be modeled by each and every vendor.
If MOF-compliant repositories become commonplace, and the OMG continues to crank out useful metamodels (including the IT Service Management Metamodel I'd like to see), then the market really shifts. Repositories are hard to do right, and companies that want to play in that space should focus on them -- but they may well become a commodity infrastructure technology.
The value-add stuff will come in understanding the IT business processes better. If you can show an application that integrates (meta)data from disparate sources and is clearly best-in-class in such categories as managing internal IT workflow, supporting analytics, and other IT process related applications, you will succeed. And you might well find you don't need to build yet another repository.
-ctb
Each vendor's tool started as something else, and build on the existing platform* to add functionality, regardless of the existing platform's strength or versatility.
Acknowledging that each vendor's tool is/was optimized for a single function, and also that most companies cannot sacrifice the sunk cost to switch to another vendor, an open process-enabling tool data interchange standard is needed for both intra-company as well as inter-company process data interchange/interaction.
* Honoring the ancient axiom: Every programmer writes only one program from scratch. All others are revisions.
Posted by: Martin Erb | November 04, 2003 at 04:39 PM