Domain modeling – the enterprise problems

On my previous position, I lived and breathed the domain model, the processes and even the information model. Since I was educated in the field, the terms and processes were also near me.

Having moved to a different industry: the leisure travel business, the tables have turned. I have a customer’s concept of the different terms and the domain and my customer’s concept is based on experience from one of the business models used in our business. TUI Travel consists of Fritidsresor in Sweden, Startours in Norway, Startours in Denmark, Finnmatkat in Finland, Tema (Swe, Nor, Den, Fin), Nazar and our flight carrier, TUIFly Nordic. That’s a lot of business models to keep track on. To make things more complex, we’re part of the European TUI group and some of our systems and processes are shared in the whole group. Having worked in a business mainly controlled by Swedish legislation, we now have local legislation in all our countries, and that include destination countries and even the countries we fly over. We also have international legislation on different levels.

Defining processes, domains, enteties and models are seldom easy but in and enterprise environment as mine, the challenge is enormous. How can one possibly set the domain model, information models and processes in such an organisation?

One can easily fall for the temptation that it’s not doable: but this is just not the right answer. Just because you work in the dark doesn’t make it easier. We need to turn on the light even if it’s challenging.

I don’t have any answers here on how we’ll do it. I can just say which methods I use:

1. Force yourself to use the terms that are present in the model. Make sure that you make yourself understood without having to add other words when you talk to business people.
2. Listen to others when they talk about the domain. If they stick to other words, you’ve probably not chosen the right word.
3. Don’t try to turn the big boat around. If people in general is using a word for "the wrong thing" in your model, change your model. People will still think about the old definition all the time. It’s not worth it.
4. Find out the extremes of your domain and test the terms on these problems. Does the models and processes still work when we apply the less than common situation?
5. Test the terms and process description on someone new. People get used to the models and terms so you should try and grab a person who does not meet the model every day. I work with 1500 people at TUI Nordic, so this is the least of my problems.
6. Don’t model everything upfront. Make it a ongoing process.
7. Involve the developers so they use the model in their daily work. Otherwise there will still be other factual models.
8. Make the model an in house model. Someone who is native to the organization has to be the one who owns the model so that it’s owned by the business. Consultants are not bad but they don’t know the business and your model will be clotted by IT terms like Invoice entity, which no business person would ever use.