This article gives me a chance to post a picture of my son:
.
Thanks, yes I know he's cute. He's a happy boy :-). What I want to draw your attention to is the Skwish(tm) toy he's holding.
I want to talk a little bit about the reporting side of ERP for IT. Been talking a lot about technicalities, that at the end of the day don't mean much unless they enable information to be presented to leadership.
Metadata is like yet unlike other forms of data, and as I continue to work in this space the distinctions are becoming clearer. The issue has to do with data complexity, which I discuss in depth here. To summarize that discussion: regular business data is like a deck of cards:
You can say,
"Show me all the red cards between 3 and 8"
"Show me all the jacks"
"Show me all the hearts and spades"
and it's a pretty simple problem. The hearts don't have much to do with the spades, and there's not a lot of ambiguity.
The Skwish toy represents interconnected data. It's troublesome. You can say, "show me a small red sphere," but what if you say "show me everything connected to the small red spere"? What do you mean by that? The whole toy? Or just things immediately connected to the red sphere? By elastic? By wood? Where do you draw the line?
What does this have to do with reporting for ERP for IT (and IT service management)? Much reporting is of the deck-of-cards variety. You can handle this with the same tools your business users use: relational databases and reporting/BI tools such as Crystal, Brio, Microstrategy, Actuate, and others.
Using these well-established techniques, I can answer all of the following questions (assuming the data is consolidated into a data mart):
What services do I have?
Have I met my service levels for a service?
What is the history of changes associated with a configuration item?
Is the project on schedule? On budget?
What projects contributed to building this system, and what did they cost?
What does this system cost to run?
But those tools don't handle reporting on interconnections. With relational databases and query tools, it's very hard to answer the following questions:
What is this service dependent on (other services, applications, hardware, network)?
What depends on this infrastructure piece, directly or indirectly?
For a project, what tasks are on the critical path?
What is the complete lineage of this data item in this report? Where did it come from, what systems did it flow through? (A very important Sarbanes Oxley issue!)
What are all the downstream destinations for this data element? What middleware infrastructure does it flow across? (Important security questions.)
Basically, if you have language like "direct or indirect dependency" in a requirements spec, you probably are into the Skwish type problem. This is known as graph processing in computer science (see this Google search if you are interested in the fundamentals). The problem is that while the theorists have been kicking this around for a while, no standard approaching SQL has been implemented across multiple platforms. This in turn is closely intertwined with the relational database vs. object database debate; OODBMSs being better suited to graph information (this is why metadata repositories and CAD/CAM tools are usually built on a direct object persistence layer).
The ideal CMDB/metadata repository tool would handle both of these issues. It should expose relational tables over an ODBC interface for ease of reporting, so companies can use their preferred reporting tools (even Excel or Access!) And it should have a framework or solutions development kit so that graph-based queries on interconnections can easily be defined by power users.
The tool that takes top honors for attempting an easy-to-use graph query capability is Troux, with its proprietary TQL; Adaptive has standards-based capabilities here but they require software engineering sophistication in traversing the MOF-based object models and rendering them as SVG. Informatica's SuperGlue will reportedly have the best of both worlds; an OMG MOF-based metamodel and relational reporting tables.
Clearly, an easy-to use SVG/MOF-based graph query framework would be a substantial contribution to the community; if anyone is aware of any open-source work here please let me know.
Finally, a note to all internal IT tools vendors: I question why so many of you seem to be doing reporting modules. You'll never catch up with the dedicated reporting vendors, especially now that Microsoft has entered the market with the very well-received SQL Server Reporting Services. Even the smallest shops have Access, which is a fine front end for relational data. If I were you, I would focus on (meta)data capture, correlation/reconciliation, tool interoperability (e.g. through Web services) and the challenges in making graph processing usable.
-Charlie
