Mr. Business - The essential member of your team
A developer that I know refers to an imaginary team member that he has - “Mr. Business”. Mr Business is whoever there is on a project that takes the corner of the business requirements and only sees things from the desired end goal.
Summary: The business requirements are an essential component of any project, but when implementing a modeling practice, often the people implementing it are the same people who have defined the requirements. In such a case it's possible to lose sight of the original goals and in such a situation, a motivation model is a possible tool to let one or more team member’s step back into the business advocate role.
Any implementation project is the output of the conflict between multiple drivers. There's the natural desire to want everything, that conflicts with the issues that you run into implementing 'everything' with a given budget and timescale. I'd hope that this point is not controversial. The trade-offs that result come out of discussion between those implementing the project and those who will be using the output – or their advocate(s).
All well and good, but an issue comes when the advocates are the ones implementing the project – which is generally the case for rolling out a modeling practice (whether business process or architecture). The issue is – how do you have an argument with yourself? With the best will in the world, it's incredibly hard to keep multiple perspectives in one person's head at once, absent multiple personality disorder.
Effectively, there are two versions of the team – the team in the requirements stage, and the team in the implementation stage, and they are separated in time. So what we really need is an easier way for the implementation phase team to think themselves back into the mindset of the business requirements.
One of the techniques that Edward de Bono is known for is proposing the 6 thinking hats – you look at a given issue from 6 different perspectives, and imagine yourself wearing a hat of a given color while looking at the issue from a given perspective. In the same way, in the absence of having a dedicated Mr Business among them, the team rolling out the architecture practice need a way to put on the business hat.
Well, I'm a big advocate for eating your own dogfood, so the proposal here is to define a motivation model for the initiative before starting it. In this way, the team can refer back to it as the project progresses.
There are a variety of different frameworks out there for motivation models. TOGAF has a motivation extension, there's the Business Motivation Model from the OMG, and so on. I'll use the ArchiMate motivation model, for no other reason than ArchiMate seems to be coalescing as the de facto architecture modeling standard in the same way that BPMN has for process maps.
As an example, part of a motivation model might be as follows:
In a perfect world it would be possible to keep every point of view in mind at once, but people are not perfect. So when, as is often the case, the people charged with rolling out the modeling practice are the ones who will be using it and who advocated it, creating a set of motivation models ahead of time can be a useful tool to let the team step back into the "Mr Business" mindset.