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.

Work breakdown structure exercise

Today, I was invited to a WBS exercise given by a colleague. One of the absolutely best things about TUI Nordic’s project management department is that we all are eager to learn from each other. We are very different as project managers, persons and our experiences are very different. So, we keep a close culture of listening, learning and sharing. J is an excellent project manager, and I would feel really confident in him succeeding in big, complex projects. I feel I really have so much to learn from this guy. And today, I was again given the opportunity. J is project manager for a project. I’m not really involved but was invited to an WBS exercise. For him, it was a chance to get some new input since he’s new to agile software development, for me it was an opportunity to see how this really can work.

For you who’ve never done this type of exercise, you try to identify the different goals which need to be met to reach an objective. And then you divide the goals into smaller tasks and go on doing this until you have a picture of which tasks are needed. For agile people, this sounds like a story writing seminar, and this is exactly what it was. The goals are like epics and the different tasks are the user stories. We didn’t use the format of a user story but that are details. Instead of using story cards, J used post its and put these on the wall to show the structure. And since the post its weren’t big, there were not room for too much details. So, in other words, you get the shortness of a story. I loved the session, J is a skilled leader and used his two hours well. After this session I think we have a good idea of what needs to be done.

One interesting note was that in the middle of the session, I said we needed a Deployment objective. And then we needed a Maintainance objective. And suddenly the number of tasks exploded. Deploying a big e-com solution is something you need to plan for. You perhaps does not need an actual plan (in Project) but you need to plan for deployment. Make sure that the acceptance environment is available, that we have testers, that operations are ready, user and help desk informed. Etcetera. Etcetera.

Building the stuff is the easy part.

Leadership

Leadership. Leader. Ship. My boss asked the team today what a leader is. And that is difficult to define. It’s different for different situations and different groups. The very essence of being a leader can be so different depending on which leader you look at. It’s very interesting that on TUI Nordic we speak a lot about leaders, and that does not only mean the persons who has a leading role in the hierarchy, it’s about leadership in all roles. The project manager is one of the leaders in the project, but so is the architect, and the test responsible. And our staff on the field are all leaders. They are leaders for our customers.

So, evolving leadership is something that is discussed and is evolving all the time. I won’t go into the tools we’re using, that are corporate secrets, but my boss said something really interesting about leadership. To be a good leader you need to know yourself. You need to know your strengths and your weaknesses. You need to become self aware. This is hard. And then you need to build on your weaknesses and not build on your current strengths.

And this is really in line with my beliefs. Leadership comes from the inside and only after self awareness can leadership be confirmed by the outside. You are only a leader if you believe that you are one, act like one and is treated as one.

Most of my friends are asking if I’ve taken a trip yet (since I’m working in the travel industry). Well, yes. But this has been an inner journey which I’ve just started. And this is just an example of what I’m experiencing during this trip.

The captain of a ship need these traits. I won’t bother explaining why since either you’ve been sailing under bad/good captains and know what I’m talking about or you haven’t and then I have no chance making you understand. But I think this is why a sailing exercise can be so useful as a team building event discussing leadership.

Agile and lean implantations need good leadership and I also believe that agile and lean can help in building these leaders. Getting people to constantly improve themselves and their situation, having people take responsibility and be proud in there work are all things that can make you a better leader.

Avoid accidental architecture using scrum

The CIO at my company often say really wise stuff, things that get me thinking (and I don’t say that because he’s one of my bosses since I don’t think he reads my blog). It not for nothing that he was voted CIO of the year in 2007 by CIO Sweden. I guess he’s not the only one who says this, but for me to hear this from a manager is music to my ears:

We must make decisions on architecture. Either the organization have decided on architecture, or the architecture just happen. And the result will be a really bad architecture.

Developers make decisions on architecture almost every day and if they have nothing to base their decision on, the architecture will just happen and be accidental.

In a scrum project where the stuff with the most business value always should be prioritized, it’s easy to select everything else but removing technical debt and introducing a better architecture. This is why you must not only discuss income but also removed costs when you talk about priority. Still it’s hard when the sales department stand banging on your door, demanding the stuff which makes your product the best in the world.

So, you need a strategic decision that we work on our architecture. And yes, we give it a budget, plan for it and execute the changes. Try including the why clause to the architectural items, so that you can argue for the items and get yourself educated.

During ordinary working time. Architecture being improved on someone’s free time is not an option for a serious business. For a team to be proud in their work, their need of good solutions must also be addressed. So, letting the team have their saying about what in the architecture needs refining is a good reward and recognition that you believe in them as competent team members.

So, now when I’ve perhaps sold the concept of putting the architectural stuff, I’ll leave the details on how you can do that to Boris Gloger. You don’t have to be a developer to read this excellent article and you need not be a manager, business guy at all.