Where Do You Start When You Know Nothing?
You say “Hi!” to everyone, exercise your complete toolbox of people skills, and follow everyone to lunch, etc…but that is not enough, is it?
Being a developer who uses ECO and the strategies proposed by DDD, I know what to do once I know what “the whole thing is about”. However, the client is not well equipped to tell me what I need to know spontaneously, so I need some strategy to extract that information from them.
The Strategy
I know there must be a million ideas on how this is done. This is the way we do it:
- Gather a representative group of people from the domain.
- Set up a workshop and let them brainstorm on whom is showing any interest at all in what they do. More specifically ask them: who calls you on the phone, who emails you, who comes to visit, who delivers stuff, who sends you stuff, who buys your stuff, etc. All these questions are reversible: Who do you call, Who do you email, etc? Collect this information and keep it as the Triggers.
- For each unique persona from step 2, find out what the goal of this persona is; why does X email you, and what is their goal? Why do you email that person, what is your goal? Collect this information and keep it as the Goals.
- Split your group into smaller groups and let them break down each no-nonsense combination of triggers and goals into some steps that are central to getting to the goal. Make them aim for 5 steps. If they have a hard time getting started, encourage them to bring up just 1 step. Example: “Trigger is Customer, Goal is Getting a loaf of bread”. One obvious step is “handing the bread to the customer”. Great! Now, compel your group to explain what they do before and after that step. “Need to fetch the bread from the shelf” is before, and “Receive payment” is after. This is going great! Continue like this, and throw away the silly steps and keep the important steps. What they create here are overviews of what their business is about. Keep this information as Processes.
What Next?
After you have gone through these steps, you will have a pretty good idea of what you are up against. You will have a set of high-level processes. Document these in AppComplete or ECO:
Some of the processes you have already found might be detailing processes for another process. Also, some steps in a found process might need detailing in further steps; you should callback your domain group to help you out with that.
By arranging the processes as “detailing” a step, you build up a structure in the Modlr tree:
Do you need to involve real, domain people? Will it not suffice to read some existing documentation and talk to some IT guys in the company? No. It will not suffice for 2 major reasons:
- You do not know what the real issue is – it might be that the current documentation and/or the current IT crew is wrong.
- You need to get real people involved so that they feel and know that you are on their side. After all, you will be a central player when it comes to change in these people's working environment. You need to earn trust, you need to communicate, and you need to involve them. If you do not, you will have a difficult time trying to get real people to understand the greatness of your work once you are done. And then, it is all for nothing.
When you have come this far, start on the information model. Create 1 class diagram per process and associate the two:
As you focus on a specific process when creating this class diagram, you get a small and readable result:
The Process diagrams indicate that they are associated with class diagrams, and you can click the icon to jump straight to the class diagram:
Furthermore, the Process tree gives you a good structure of diagrams:
Now, you have the big picture of “What it is that happens” from the processes, and you get the “What information” view from the class diagrams. All you need now is the detailed business rules that control this process. Being totally into declarative development, I only consider a short while before starting to write C# code to catch these. The state diagrams are better because the documentation becomes clearer, and maintenance will be cheaper in that form (from our point of view). You can associate these with processes as well:
At this point, you may want to take it to yet another step: declare a ViewModel per process - but, I will save ViewModels for another post.
Summing It Up
The process tree will give you some navigation of diagrams and artifacts. The processes will make it easier for an outsider to understand the domain. If you are a group of people - where some do client communication with process modeling and some take it further with development - you can now share one tool to keep your development efforts collected.
Whether you choose to do everything in your development declaratively - as we do - or as only part of your work and the rest by traditional coding is entirely up to you.