NOTE: The final version of this initial post (including definitions) is here.
Public DRAFT - comments requested.
Problems worthy of attack
Prove their worth by hitting back.
-Piet Hein
This post will be a work in progress for a while. Unlike many weblog authors, I continue to revise my posts for some time after initial publication based on feedback & further thought. This is because this weblog is essentially a vehicle for a book, and the longer posts are chapters.
Here is an overall logical model/metamodel that integrates IT Service Management and metadata concepts (click for full size).
continued...
I hope that this will be useful to anyone either building or evaluating a CMDB, IT Governance tools & processes, or an extended metadata repository.
This discussion may also be helpful to those evaluating the OMG or DMTF metamodels, as these models are highly complex. The principles in this metamodel are the same, but everything is at a somewhat higher, more conceptual level. This is a good thing, because the problem in enterprise IT right now is a proliferation of point solutions with no common understanding of how they fit together.
Comments on method: I use the hollow arrow to indicate inheritance, and the crow's foot to indicate cardinality. At this level of modeling I am not concerned with composition vs. aggregation, or optionality. I use my own Visio idiosyncratic notation partly for convenience, and partly for intellectual property reasons so there is no ambiguity between these weblog posts and any work I may perform for hire, nor any question about how I have access to an expensive modeling tool license. Finally, I like having a notation that incorporates both OO and relational symbols.
This is a conceptual data model. It deliberately omits a number of data structures that would ultimately be necessary to realize a solution. The omitted data structures are generally intersection entities and dependent entities that elaborate on the core concepts. Process focused entities are also omitted. Some notes on possible approaches for elaborating this into a full logical data model is covered in the data definitions.
The rest of this post will be a detailed discussion of the entities and their relationships.


Two quick comments:
1. The model appears to be more of a maintenance model than an initiation model - in other words, how do new programs get approved and introduced into the portfolio?
2. Without the accompanying process flow that includes roles and resposibilities from start to finish, the model runs the risk of being meaningful to a small handful of people, which will limit it's impact...
- Demian Entrekin
Posted by: DemianE | July 20, 2005 at 03:44 PM
Excellent model. I agree with Demian E. but I argue that Damian acknowledges that this is only a partial model. Business users (who are not technical and more importantly should not really be concerned with the issues of EAR data model) could then better understand its usefullness.
As indicated at the start "by Peit Hein" the model is a Service Management data model. It only implies a process flow Thats the problem with data models such as the EAR and meta data models!. Most process models are industry/business specific but having a perfect model for guidance is probably a good thing. I for one appreciate that business users wanting contradictory requirements of the rigour of mapping exactly what technolgy can provide with simplicty of what the customer wants/understands. Business analysts are always going to have to compromise when providing models (data hiding) that are understandable for both groups (Business and Analysts).
- Robert
Posted by: rmack | August 05, 2005 at 04:46 AM
Many services cannot be provided without peripherals. I suggest to expand the machine definition to include periperals.
A peripheral class should be added to hold instances of machines like printers, plotters, scanners, Smartcard readers, cameras etc. Like the os instance of servers or workstations the instances of peripherals (mosty) have a unique configuration like an network name, an ip address etc.
Posted by: willy.liszt | September 09, 2005 at 09:28 AM