I always learn more from failure than from success. In that spirit, I'll share a (small) failure with you.
In my last post (Working in the dark), I mentioned that I would be discussing the metamodel [domain model] underlying all the things we do in operating Microsoft IT. In effect, I'm following the precepts of Domain Driven Design, and applying those concepts to the act of software development in an IT setting, from planning through requirements, development through deployment, operations through retirement. I don't know if I will end up with a federated domain model or a single unified model. That depends on a lot of things. In the spirit of agile: I forge ahead.
One of the core principles of my effort, first and foremost, is "Leverage before build" which is a fancy way of saying "don't invent what already exists." That implies that I will look to the [domain] models that exist. One of them is the Common Information Model (CIM) from the Distributed Management Task Force.
To leverage the work of the DMTF, I want to start with their highest level information model (conceptual level). From the concepts, I can understand the classes. I've used this process before, and it works. To the best of my knowledge, this is the process used by DDD.
I opened the CIM from DMTF expecting to find an Information model. After all, the name of their effort was "Common Information Model." And I found out that my nice little plan was not going to work... because the DMTF didn't publish an information model. They published a detailed class model.
(Caveat: I'm no expert on DMTF deliverables. I spent three hours perusing their site, reading docs, and viewing models. If there is a domain model there, I didn't see it. If someone does know of one, please send me a link.)
An example, from the DMTF CIM system model, looks like this (click to see the full picture):
Now for my controversial statement: This is not a good communication mechanism for information modeling, especially when sharing with people who are not already part of your project.
I love Class models. They are great! Unfortunately, they are not a domain model that business people can use. It is not a model that I, as a potential adopter of DMTF models, can use. I need the business concepts first, to make sure I can align and/or adopt.
There's an information [domain] model under the DMTF class model. That much is discernable. But it is not explicit. It is not exposed. Both class models and information models should exist. But if I have to choose one, I'll start with the information model.
(Caveat: I'm aware of their CIM metamodel. It is a model used to describe the CIM meta-elements, not a conceptual model that serves as the foundation for the CIM object model).
So, while I'd like to consume the DMTF work, I'm afraid that the published models of the CIM are not appropriately modeled for me to consume and leverage them. I could re-model them in my own UML environment... but what value would I gain? I'm not sure.
There's always a tension between models for the machine vs. human. It seems like when they try to do both at the same time, they break (no good for human, no good for the machine.)
If you haven't already done so, you may want to take a look at Charlie Betz blog, and specifically at his document about a data architecture for IT Service Management.
I don't know whether the scope of his document completely encompasses the DMTF or your internal work effort, but Charlie advocates the notion of IT needing their own ERP system managing and controling IT work proccess (hence 'ERP4IT'). I have found Charlie's ideas on this subject and the merging the concepts of metadata management with IT service management to quite ground-breaking, and worth your time reading.
Hope this helps,
Thank you Rob! I had exchanged a few e-mails with Charlie about a year back, but I had not realized that he had a data management model. I will check it out forthwith! ;-)
I'm a long time reader and generally find your blog extremely sharp and helpful, but this time I'm not sure what is the message and what exactly was a failure here.
I don't believe DDD focus is about abstract/information models. You might know that
Evan's book that spurred DDD has the subtitle that implies that it's about concrete implementation: Tackling Complexity in the Heart of Software. In fact nailing down abstractions in the concrete form is the goal of DDD and "There's an information model under the DMTF class model" is an anti-thesis of DDD and I believe is labeled Anemic Domain Model anti-pattern.
Sure, you'd use some abstractions to communicate to non-technical stakeholders, but I believe the idea is to bring them as close as possible to your level, not the other way around. I'd also expect the abstractions you use to communicate in such cases are tailored for the purposes of the discussion, therefore don't have to be 1) absolutely correct and 2) all around complete.
Essentially, I believe Enterprise Data Model and/or Meta-model has nothing to do with Domain-Driven Design. You can do one or the other or both, but I don't see how you could relate them.
Perhaps, for a long time reader, my shift to metamodel discussions is a bit sharp. After all, I've been talking about SOA and business process for years, and now, a I jump into discussions of the metamodel, it may appear that I'm still discussing "canonical" or "common" information models.
I am not. I would not put them in the same sentence. My apologies for not making that distinction more clear.
One more distinction comes from the overuse of the word metamodel. Perhaps you are thinking of the metamodel underneath UML, or the metamodel underneath Software Factories. I am not. I am talking about the domain model for IT assets. I slipped up when I used the term "metamodel" in this blog post. In MSIT, we have adopted that term to refer to the domain model. It is incorrect. I should not have put it on the blog. My apologies.
What I am doing, these days, is applying the concept of Domain Driven Development to the problem of "understanding how IT operates as a business (service provider business model)."
In that respect, I need to create a domain model for the domain of our work: offering a set of services to the business for operating and improving information technology and process management.
That domain model forms effectively the data objects that we need to manage, from the concept of a "requirement" to the concept of a "feature" to the concept of a "component." These are the domain objects of IT.
I agree with you that the 'undescribed' model underneath DMTF is an antipattern. I was bemoaning the fact that good people (contributors to DMTF) had made an attempt to solve problems in IT but that they did not make the domain model explicit.
My failure was that I was hoping to adopt their domain model, rather than build my own from scratch. They had done good work (I think) but I cannot adopt it. In that sense, I cannot successfully leverage their work.
It is not a personal failure. I cannot do for them what they did not do for themselves, and that is make an honest effort to understand their own space first.
I apologize for the confusion. [I updated the blog text to attempt to address this mistake.]