I'm trying to bring ORM to the attention of project managers who didn't know that they needed it.
Well, that's a laudable aim. However - in my experience by the time a project gets to a project manager - its probably too late!
Note: I "came across" NIAM in 1987 and didn't understand what I was seeing. Then, after a year or two of puzzling and playing with ER tools, I "started with ORM" in 1990 and I have been using and teaching it ever since.
What about you, Ken? What problems have you solved with ORM? and what features would have been on the "must have" list for you?
Well! That's a very good question . The general answer is "lots but...." Here are three examples:
1: An application development manager was under pressure from his management to develop applications "quick".
He called me and asked for my help. I demonstrated InfoModeler to him and to his chief programmer.
The chief programmer was amazed that he could generate a relational database so quickly. The manager bought InfoModeler there and then.
But I could see that the chief programmer didn't really have a clue about what he was doing.
So I proposed that they hire me to teach them why and how to use ORM.
Unfortunately, the manager did not accept my proposal for teaching so I don't think that they got much value from ORM. (The company was FedEx in Brussels)
2: I was hired by a big European bank as the auditor on a huge international project ($100M+ budget as I recall, with a fixed deadline that was set by impending legislation to which the bank had to conform)
My role was to attend the weekly project meetings of about 20 people from 12 countries and to just listen during the meetings and then later give the project manager a report on how I thought the project was going and what I saw as the big issues.
Every week, there were big clashes between the "users" who just wanted "ten new international transactions" and the technical folks who had to implement the "requirements". I was given a free hand to interview whoever I liked. So my "ORM radar enabled" intuition led me to investigate the details behind the "requirement" for "just ten new transactions". I used ORM (VisioModeler) to model the transaction requirements. What I found was that the transaction profiles were affected by issues such as time zones, differences between the rules of national central banks, and of course national legislation. My object-role model clearly showed that instead of "just ten transactions" there were more than 1500!
I tried to explain this to senior banking executives but whilst they could not refute my explanation, they just could not get their heads around what I was trying to tell them. The "problem" was that the senior bank managers with decision power knew very little about stuff like data networks and the demands of IMS-DB/DC whilst the technical managers had very little political power.
Anyway, it was "obvious" to the senior bankers that I was just an outsider who know nothing about banking and how simple it really was.
They made the deadline - but they had to de-scope the project to do it and the techical folks had a two year "death march". (Ed Yourdon's term)
So in neither of these examples did I use ORM to "solve" what were management problems caused by hubris, politics and ignorance - I just got a very close look at them.
3: Some time later, I was hired as the CIO of a multinational with developers in several countries in Europe and North America.
One of the board members came up to me with a "requirement". I asked him for documentation and he showed me a few pages of text and some diagrams with little stick-men on them (Use Cases). These documents were absolutely useless.
My reaction was to write a "requirements procedure manual" and have it approved by the CEO.
Then I hired a data modeler who could have an intelligent conversation about the relational model. I taught him to use ORM and gave him a key role in the requirements process. Board members kicked up a fuss. Why was I making things so complicated?" The OO programmers were perplexed. They had never heard of the relational model and had never been asked to properly document their designs. But since I was responsible for about half of the company, and I had the backing of the CEO, I got my way.
So what I have learned over the years is that "the problem of ORM" will not be solved by better tools (although they will help).
The real problems of ORM are related to awareness, understanding and credibility. Which is why I am running this website and why I spent almost a year of my MSc in researching the deep issues that separate the acceptance rates of UML, ER and ORM.
So - regarding your "must have" list - all I can say is "at least as good as VisioModeler and VEA!"