Looking forward
Concept Maps (such as CmapTools) is primarily targetted for learning and knowledge management.
In those disciplines the are only a few standards. One is Topic Maps (an ISO-standard), which is primarily used by knowledge managers and information architects. Another standard is OWL (Web Ontology Language) developed by the World Wide Web Consortium (W3C). OWL is based on RDF and XML Schema. OWL is part of the Semantic Web movement, also known as Web 3.0.

A very interesting recent development is the SBVR standard from Object Management group, OMG. SBVR stands for Semantic of Business Vocabulary and Business Rules. SBVR combines much of the best: Business Rules, Semantics (RDF etc.), ER modelling and more. And most interestingly SBVR is heavily influenced by the so-called fact oriented modelling, which is at the heart of ORM! Seems that then loose ends are being tidied up, finally!

Good book about ORM in particular and modelling in general

For an in-depth treatment of ORM, see Halpin, T. & Morgan, T. 2008, Information Modeling and Relational Databases, Second Edition (ISBN: 978-0-12-373568-3), published by Morgan Kaufmann Publishers, an imprint of Elsevier.
The book reveals the true power of semantic data modeling (covering ORM, ER, and UML), as well as addressing business process modeling, relational databases, and other modeling topics such as the semantic web.

The Puppy sample / Normalization Poster

The little Puppy / Kennel database originates from a poster issued by Database Programming & Design in 1989 about normalisation. The author is Marc Rettig - the then technical editor. Reused here with the kind permission of Marc. The poster is a very good presentation of normalisation taken to the fifth normal form. © Marc Rettig, 2006

Concept Mapping explained

The process of mapping business concepts is straightforward.
Initially the business analyst interviews a select few representative business users to get an overview. At the same time he/she also asks for samples of reports, memos, spreadsheets, documentation of it systems, screens and so forth - of relevance to the project. The analyst then produces one or more draft Concept Maps; using eg. CmapTools; based on the "harvested" concepts in all those documents.
Selected business representatives are then gathered for one or more workshops with the purpose of actually producing an initial version of the Business Concept Model. It may look this:

Note that this is a very simple representation including only business concepts, the relationships between them as well as indication (by way of arrows) of one-to-many relationships. Nothing more; it is important that the terminology is really the day to day language of the business. Also note that the diagram can be read in sentences (eg. Puppy can do Puppy Trick), which is very nice for verification purposes when you sit in a brainstorming session with business users.
For more information check our eLearning offerings!
In subsequent iterations on workshops and using other potential feedback mechanisms such as emails, intranets etc., the Business Concept Maps are further refined, and the final result may look something like this:

Note that in the second version rectangles with rounded corners are used to denote attributes. This is nice, because the diagram in that form is easily translated into a multidimensional model, where the natural hierarchies are clearly visible to everybody. There is also some potential riscs in doing that. Note that "Kennel Location" is probably not really an attribute, but is more likely to a placeholder for a complex geographical concept model, such as a postal address or similar.

Definitions and other specifications

What remains to be done is a simple document listing all the concepts and providing textual descriptions such as:
  • Definition
  • Description and comments
  • Type
  • Special rules
  • Sample values
This applies to both concepts themselves and to the relationships between them.

And then IT comes in

Once the project owner and his/her advisers have signed off on the Business Concept Model, it is time to let loose the it developers (but that is another story).
One of their first jobs is to produce a logical datamodel, which can be a UML class diagram, and which may have alle the bells and whistles like subtyping, detailed cardinalities and so forth. But only if it is really necessary, of course!

Object Role Modelling (ORM)

It is really quite amazing that business analysis and modelling on this level has not gotten the attention it deserves in the it community.
There are a few exceptions, though. Go to the website of Object Role Modelling, and you will see that modelling on the "atomic level" was invented in Belgium in the late seventies. At Control Data in Brussels I believe they even had a DBMS up and running, directly implementing the ORM metamodel. Prof. Sjir Nijssen was the chief architect behind that. There still exists a community of devoted practioners of ORM. One of the best known evangelists of ORM is Terry Halpin, who came with Visio to Microsoft. ORM is actually supported in Microsoft Visio. The reason why I do not go full scale into ORM is that for the purpose of simple business concept modelling, the diagrams on ORM are a bit too complex for most business people. ORM diagramming is intended for communication between the modeller and the "domain expert" (superuser), not with the business manager, who allocates the budget for the project. This situation is the same for many Knowledge Management tools, by the way.
But I do indeed favor the notion of the "atomic" modelling - meaning that the level is that of concepts and all concepts are independant, but related to each other.