The ORM Foundation

What are the essential features that an ORM tool must have? Obviously it must be able to draw ORM diagrams, but I think we all expect more from an ORM tool than that. What is your "must have" list?

My reason for asking is that yesterday we released the v0.11 beta of ORM LITE. The new release adds a relational table diagram, a much improved (but still incomplete) Rmap algorithm, and better SQL generation. We would like to ask you to take a look at the tool. It is available in the Library. The documentation explains what is and is not implemented. Our goal is for ORM-LITE to become a powerful introduction to ORM. To make focused improvements to the tool, we need to know: what essential features are missing? and what is the most urgent need? 

Please share your thoughts on this. What is your "must have" features list for an ORM tool?

Thanks for your help!

 

Hi Brian,

Thanks for posting the updated files on ORM Lite. Good initiative! Well done!

You ask "What is the list of "Must have" features of an ORM tool?
My generic answer to this question is "the features that help to solve the perceived problems of the ORM user."
So it seems to me that before you can devise a list of "useful features" you have to answer the questions:
"Who needs ORM?" and "Why do they need it?"

There are probably lots of answers to these questions because ORM can help with so many things.
So that leads to the question "Which of today's big and most urgent problems can ORM help to solve?"
Answer that, and your feature list should be relatively easy to devise.

Now I get the feeling from your website that you are targeting "project managers".
Is it because you think that they have the biggest and most urgent problems that can be solved by ORM?

Ken

Ken Evans:

So that leads to the question "Which of today's big and most urgent problems can ORM help to solve?"
Answer that, and your feature list should be relatively easy to devise.

I'm hoping that some of our ORM folks will offer their perspective on this.

Ken Evans:

Now I get the feeling from your website that you are targeting "project managers".
Is it because you think that they have the biggest and most urgent problems that can be solved by ORM?

Perhaps, at least to the extent that projects are the main tool that organizations have to create change. ORM is a powerful tool for change. My experience is that project managers are often the people who decide on the approach that will be taken to solve problems. They decide what skills are needed and who will be on the team. In many case if ORM isn't on the project manager's radar, ORM wouldn't even be invited to the party.

People interested in ORM will find ORM-LITE even if it is packaged inside of GanttPV. I'm trying to bring ORM to the attention of project managers who didn't know that they needed it.

But, back to "must have" features. What about you, Ken? What problems have you solved with ORM? and what features would have been on the "must have" list for you?

BrianC:

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.

BrianC:

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!"

Ken

Ken Evans:

Well, that's a laudable aim. However - in my experience by the time a project gets to a project manager - its probably too late! 

Good point! It is sad, but true that sometimes the damage has already been done by then. Knowledge of and trust in the ORM approach would have to be much more widespread to solve problems like the ones you describe.

Ken Evans:

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.

Well said. I see ORM-LITE as a small aid in exactly this area. I'm not primarily trying to help people who already know ORM; they can make do with the current crop of ORM tools. I'm trying to get to people who would not otherwise have heard of ORM. When I get their attention, I am sending them to you folks at the ORM Foundation to win them over. ^_^

Ken Evans:

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.

I would love to hear more about exactly what you have learned.

Ken Evans:

So - regarding your "must have" list - all I can say is "at least as good as VisioModeler and VEA!"

What features of these tools did you actually use? Were there features that didn't really make much difference?

 

Hi Brian,

 

I thought there would be more in this thread than this.

 

In 2003 I discovered ORM and used Visiomodeler to attempt to create a model and create the database for a large project (for which I was the data architect).  After producing 45 A3 pages of conceptual model (and ~600 A4 pages of generated reports), it was about 50% captured.  At that point we abandoned ORM.  The following suggestions are derived from that experience.  The main issues were: lack of maturity of product; lack of fitting in neatly with project documentation requirements; and lack of understanding and acceptance by project members.

 

As far as proof-of-concept or small projects, current ORM and NORMA are pretty good.  What I think is lacking for the real world, especially large scale, projects are:

1. better control on the formatting of generated reports, not just to get the information out, but also in a form:
     a) suitable for formal documentation with chapter and section numbering; and
     b) easier reading of the facts;
2. be able to segment the model into subject areas and treat each as a separate section/chapter;
3. be able to record one or more Requirement Numbers against each model element to which they apply, preferably in their own predefined or user-defined property field. (I currently use the Notes field, but it means this item cannot be treated as separate meta-data.);
4. be able to trace the Requirements Numbers through to the Logical Model (at least) if not the Physical Model;
5. be able to report on what business rules in the conceptual model did not get transformed into the Logical Model;
6. be able to:
     a) version a model;
     b) report the change between two versions; and
     c) merge an updated generated report into the project’s documentation;
7. occasionally I had trouble modeling a Requirement and had to use a Note placed on a page (which meant manual intervention in an otherwise automated process);
8. an object type of Collection (such as lists and bags) readily available without having to create one from scratch.  (I’m not sure how this fits into ORM – I also missed having mutually exclusive (abstract) supertypes until it was pointed out to me that ORM is not OO.)

I have now started on a new project and I am just starting to use NORMA.  The first things I noticed in addition to the above are:

1. the real estate on my monitor for the ORM diagram is quite small compared to what I was used to with Visiomodeler;
2. the GUI is not as intuitive – I had to read some of the tutorials to find out how to do basic things – whereas with Visiomodeler I didn’t have this problem; and
3. context help (F1) is essential.

There may be more as I gain further experience with NORMA.  (I consider myself a raw novice with this tool.)

I hope this helps you.

 

Regards, Peter