Thanks. Now I have a clearer idea of what you are looking for which I summarize as:
1: Defining a procedure for using ORM to maintain a database.
2: Being prepared to explain to your new CIO the reasons why you are using the ORM approach to maintain a database.
First "the DB maintenance procedure".
In our 2003 VEA book we described a VEA based DB maintenance procedure in chapter 16 and "How to do the people bits" in Chapter 17.
As you may recall, VEA had some tool support for what we called "three way synchronization".
If you take out the VEA bits, the procedure we described is the approach that I would still recommend today.
However, NORMA does not have support for this so you would have to do parts of it manually.
Since you are having trouble explaining the procedure to yourself, I recommend that you read Chapter 16 and then base your own procedure on this.
Then you should be able to see where the latest version of NORMA fits and does not fit.
Regarding the "people bits" (CIO included) - The approach we described in Chapter 17 is still valid today. (Except of course that you would use ORM2 diagrams instead of ORM1 and the few VEA specific bits are not relevant).
I see that Amazon.com has used versions of the book for $5 so this seems to be a cost-effective approach for you.
Other aspects of the "Be Prepared To Explain" challenge
I see this in two parts: (a) Why ORM? and (b) Workarounds for NORMA
(a) Why ORM: Terry has written several papers on this (some are in the Library) so you should be able to use these papers to complement your own knowledge and prepare a few PowerPoint slides.
(b) Workarounds for NORMA: After following my earlier advice about the DB maintenance procedure, you should have an abstract process.
It should then be "just" a matter of comparing NORMA's current functionality with the abstract procedure.
A "CIO" related story
In the late 1990's I was apponted as CIO of a multinational software development company which had several teams of developers in five countries spread across two continents. Some teams were DOS based C coders, others were using variants of "OO".
Only one of the teams (about 50 people) was using SQL Server so I focused my initial efforts on them.
Step 1: My first step was to interview every single person on the team. Amongst other things, I asked each of them what they were doing and had them show me some of their code and coding practices. However, not one of them reacted intelligently when I asked a "fuzzy question" about "normalization".
Step 2: Having gathered some information and made a start at establishing good 1:1 working relationships, my second step was to figure out what I saw as "the problems to be solved" and "solutions the problems".
Step 3: One of the things I did immediately was to create a new "database specialist" job and hire somone to fill it.
I had to interview amost 20 people before I found someone who could talk authoritatively about "all things database" including normalization.
Then I taught him how to use VisioModeler and in parallel I began to develop a "people friendly" approach to re-engineering the development practices of the whole team. (to be based on ORM of course)
This took a long time and in the middle of it all the Chief Architect resigned after I asked him to prepare a "CEO friendly non-technical" presentation that explained what his brainchild software package was supposed to do indepedently of his usual "OO mumbo-jumbo-speak" explanation of how his brainchild did it.
From what you say, it seems to me that your new CIO has done "New CIO procedure step 1."
So, it is highly likely that your new CIO is now engaged in his own version of "Step 2"
In my case I had already been collaborating with Terry for many years so I knew the power of ORM and I was also a trusted member of the Board.
In your case, I have no idea of what your new CIO believes is "the correct approach" so I recommend that you find out as much about his background as you can.
For example: If your new CIO is enamoured of the IBM UML toolset then you may be in for a confrontation about why you are not using the "standard" Use Case approach. Same story for other "development methods"
Here are two relevant quotes:
Carl von Clausewitz: "Time spent in reconnaisance is seldom wasted"
Josh Billings: "It ain't what a man don't know that makes him a fool; it's the things he does know, that ain't so."
Hope this helps