Business Concept Maps
Information + Quality = Solutions
Concept Modelling explained
The process of modelling 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.
In subsequent iterations on workshops and using other potential feedback mechanisms such as emails, intranets etc., the Business Concept Model is 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
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.