"Want to know what data entities your business needs? Start with the nouns in the business function names."
Starting with the nouns is a very old procedure. I can remember sitting through courses where the first exercise was to underline the nouns in a textual description of some business process. So when I started teaching data modelling, I decided to make this procedure more interesting. I took an extract from George Orwell's essay on Hop-Picking, and got the students to underline the nouns. Then we worked out what these nouns actually signified. For example, some of them were numbers and units of measure, some of them were instances, and some of them were reifications. (I'll explain shortly what I mean by reification.) Only a minority of the nouns in this passage passed muster as data entities. Another feature of the extract was that it used a lot of relatively unfamiliar terms - few of us had experience measuring things in bushels, for example - and I was able to show how this analytical technique provided a way of getting into the unfamiliar terminology of a new business area. I included this example in my first book, Pragmatic Data Analysis, published in 1984 and long out of print.
One problem with using this procedure in a training class is that it gives a false impression of what modelling is all about. Modelling is not about translating a clear written description into a clear diagrammatic structure; in the real world you don't have George Orwell doing your observation and writing up your interview notes for you.
Now let me come on to the problem of reification. The Zachman camp has started to use this word (in my view incorrectly) as an synonym of realisation - in other words, the translation and transformation of Ideas into Reality. (They claim this notion can be traced back to the ancient Greeks, but they do not provide any references to support this claim. As far as I am aware, this is a mediaeval notion; it can for example be found in the work of the Arab philosopher ibn Arabi, who talks about entification in apparently this sense.) However, modern philosophers of language use the word "reification" to refer the elevation of abstract ideas (such as qualities) to Thingness. One of the earliest critics of reification was Ockham, who objected to the mediaeval habit of multiplying abstract ideas and reified universals; his principle of simplicity is now known as Ockham's Razor.
In our time, Quine showed how apparently innocent concepts often contained hidden reification, and my own approach to information modelling has been strongly influenced by Quine. For example, I am wary of taking "customer" as a simple concept, and prefer to deconstruct it into a bundle of bits of intentionality and behaviour and other stuff. (See my post on Customer Orientation.) As for business concepts like "competitor" or "prospect", I generally regard these these as reifications resulting from business intelligence.
Reification tends to obscure the construction processes - tempting us to fall into the fallacy of regarding the reifications as if they directly reflected some real world entities. (See my posts on Responding to Uncertainty 1 and 2.) So I like to talk about ratification as a counterbalance to reification - making the construction process explicit.
Of course, John Owens is right insofar as the grammar of the data model should match the grammar of the process model. And of course for service-oriented modelling, the grammar of the capabilities must match that of the core business services. But what is the grammar of the business itself? Merely going along with the existing nouns and verbs may leave us short of discovering the deep structural patterns.
Related posts: Business Concepts and Business Types (May 2009), Business Rule Concepts (December 2009), Conceptual Modelling - Why Theory (November 2011), From AS-IS to TO-BE (October 2012), BankSpeak (May 2015), Mapping out the entire world of objects (July 2020)
I agree. My own experience of the word was hearing Kim Cameron saying that Cardspace "reifies" digital credentials. What he meant was that it shows you pictures to represent otherwise abstract concepts... which is a fairly weak reading of the term.
ReplyDeleteThis comment was made in a Tweet on Twitter that limited the context to 140 characters, so please do not be too harsh!! :-)
ReplyDeleteThe tweet said to START with the nouns but nouns on their own would give a very sparse data model - and what about the structure and the relationships?
My full technique, which ensures that all of these can be realised, is described in detail my eBook IMM Data Structure Modelling available http://tinyurl.com/clsst6.
The technique can be followed in detail or in principle depending on the experience of the analyst. It will always give quality results that ensures that the data model is directly linked to business functions and processes.
In an exchange on Twitter, John proposed the following example:
ReplyDeleteFunction names begin with verb in the imperative "Sell Products and Services to Customers" gives three candidate entities.
My response was that this function might equally have been called "Make Sales", with Sales as the only noun.
John objected that "Make Sales" is a sparse name - does not describe what the function is all about - could not extract much information.
I could have chosen a more elaborate function name - for example "Make Sales of Products and Services to Customers" - which would have contained more nouns. Or I could have included the extra information as adjectives - for example "Make Customer Product Sales". But the primary data entity still seems to be Sale, which was not visible in John's function name.
Obviously if you already have a good function model, then the data entities are implicit. The function modeller chooses (by choice of function name) whether the primary data entity is going to be Sale or Customer. So John's procedure makes it seem that the function modeller is doing all the thinking, and the data modeller merely picking the nouns out of the function names.
I have no doubt that his book provides a more nuanced approach than it is possible to state in a 140 character tweet. I should be delighted to receive a review copy.
It was not my intention to be "harsh" to John. I've made it clear that I've also played the "find the nouns" game with my students, although with some further twists.
ReplyDeleteMy harshness is largely reserved for people who use fancy words (such as "reification" or "holism") without bothering to look them up on Wikipedia and find out what they actually mean.
Again, Orwell is my guide here. In his essay Politics and the English Language he attacks pretentious diction, and complains about a professor who "is unwilling to look egregious up in the dictionary and see what it means".
Elimination of pretentious diction is a good aim. Maybe I should call it Orwell's Razor.
Time to reread Lakoff's "Women, Fire and Dangerous Things". A wonderful treatise on categorization and structure in linguistics and language.
ReplyDeleteSomehow we have to drive into the context - discover those things that are implicit in our conversations. I think all of us who have taught data modeling have used the "find the nouns" approach. And, in classes we have usually presented quite clear environment statements so the nouns are findable.
It isn't a rote process though. Some of the nouns are derived from verbs. So in the examples given sale comes from the verb "to sell", so while a sale is a noun, it is abstract. We modelers have to have an understanding of that concept in order to probe what's is really going on. Since sale is derived from a ditransitive verb, we would expect to see a subject (a useful noun), a direct object, and an indirect object - all of which are likely to be useful nouns/entity candidates.
Where Lakoff comes in is figuring out what category to apply to these various nouns. What's the suitable concept word for the subject of that sentence? Does that same concept word apply in other parts of the business? There's obviously much more than would be sensible to write here.
The major point being that when looking for your nouns, beware of those that are disguised verbs, and then attempt to construct sentences. If you don't know the language (or the language doesn't have that kind of a grammar), modeling gets much harder. For example me attempting to model from instructions written in Arabic.
As Chris points out, lots of nouns are disguised verbs. In fact most if not all nouns can be interpreted as disguised verbs.
ReplyDeleteA bright 8-year-old child should be able to sort words into Nouns and Verbs. But proper grammatical analysis needs something a bit more sophisticated. Transitives, gerunds, ablatives, you name it.