Motivation Layer Modelling – Part 1

I Wanted to share how I approach motivation modelling, as there are many approaches, and I often see important things missing in this area. .

I will be breaking this down into two parts. This first part is focusing on stakeholders, drivers and goals. There are of course many approaches that could be taken but this one is mine; I would love to hear others. I have in fact spoken about simple motivation views in my Planning Work With ArchiMate blog. This blog talks about creating full motivation views rather than the minimal things I wanted to express at the time of writing that previous blog. Bear in mind this example isn’t fully realistic. I made it up.

The Finished view

I will start by presenting a view I created for the CEO of my fictional web hosting service provider. As I mentioned this is only half a model – in the next part I will be talking more about outcomes, principles and requirements..

Figure 1 – Motivation view

When I was drawing this originally I was going to create a motivation view including multiple stakeholders, but just in real life it didn’t work out that way. There’s so much that can be going on it didn’t make sense to start everything on one view. So I created one for the CEO – just as I may well do the same for other stakeholders. I may then go back and create a master view that brings all these views together in a singular view that tells a story.

Stakeholders

I blogged about Stakeholders In Architecture previously; and ensuring we cover as a minimum a set of stakeholders. The reality is that I still sometimes see stakeholders missed – so as a double check, especially in large projects – its a good idea to look at the organization chart. The heads of business and key roles are normally stated there and usually have an interest in our architectures. I also sometimes look at the examples of stakeholders in ISO42010; It mentions users, operators, acquirers, owners, suppliers, developers, builders, and maintainers. I don’t think the writers of ISO42010 meant for this list to be definitive but it has always served as a good starting point. The only issue I had there is it requires a fair amount of thinking to ensure you do not miss stakeholders – for example think about security.

When I state stakeholders I try not to mention names in the elements. because names often change over time and you need a record of how things are at a specific snapshot of time. In the tool we use, Enterprise Studio, we sometimes put labels on the stakeholders to identify specific people in specific views. The advantage there is that the labels are not in the actual object model. For example if a stakeholder was “Owen Richardson – EA” then in 6 months time another architect came in and we renamed the element, all the views that were once Owen Richardson, would now be named with the new architect – which may not be representative of what happened in projects past. Labels stop that from happening.

Its important that the defined stakeholders are resolvable. As in you can identify who they actually are from your model – whether it be by looking them up in the organization structure or by having the actual names of people on the labels.

Relationships

I tend to use influence relationships in my models. I do not do any advanced decision analysis with them. Sometimes I will put positive and negative strength indicators on them. This often confuses people, so sometimes I will leave them off if I think it doesn’t provide value. You can see some examples of how I use influences, and the indicators in figure 1.

Drivers, Assessment & Goals

Drivers are the reasons why someone does something, goals are the things you do to satisfy those motivations. Some drivers are obvious, we normally get the drivers and assessments from talking to our stakeholders. They will normally tell you what they want, and give you reasons – those reasons I treat as assessments. Sometimes they will also give you the goal; or sometimes it may be down to the architect to suggest the goals. In those conversations with the stakeholders I normally create a high level goal then I need to think about how to make it quantifiable, so i go a level down. and have lower level more defined goals influencing the higher level ones. These are important because later on when we start doing implementation architecture and deciding how goals are reached we will be reusing these. Its possible several stakeholders are going to have the same goals; at that point i will sometimes consider creating a higher level motivation view showing just how the stakeholders and goals fit together. You can create as many motivation views as you need to tell the story of how your architecture is motivated.

When creating assessments its very easy to end up with statements like “we need to do ” which could end up as goals or requirements – I try to avoid requirements until later and will sometimes reword elements to avoid confusion. “We need to automate” might be a good example. This could be a driver of a stakeholder, or it may be a goal, or even a requirement. You need to think a little in the context of what you are doing and ask is it really something that drives a stakeholder, or is it something that’s a result of whatever drives them?

Some of my goals in figure 1 influence each other:

Figure 2 – Goals influencing

You will find talking to different stakeholders that in some areas they have a more defined idea of what they are needing. It may also be that you are already thinking about how your goals will be realized when you create your motivation view. In the example we can see our goal isn’t really fully realized until all the goals below it are met. Sometimes you will have this level of detail at the outset – other times this will come up later in design conversations. Motivation views can go through several iterations, as can any architecture view. Its worth mentioning SMART – when it comes to goals (Specific, Measurable, Agreed, Realistic, Time Based). More specific goals in general are more useful when it comes to actually realizing them. The more vague and fuzzy a goal is the more different possible ways there are to make the goal happen, and the less likely that it is that all the goals working together will end up in a desired outcome of your project or architecture.

Values

Goals provide value. I like to have a standard set of values that i map onto different architecture models. Values like cost reduction, risk reduction and improved efficiency will come up time and time again when management start new initiatives to improve things. Its good to get ahead of them. if next time my manager asks for a cost reduction i can show him a value, connected to a goal, which is connected to a work package (which would be created in an implementation and migration view), It would be very easy to show how we are already working towards those goals, and then reprioritize work with the management if need be.

Prioritizing goals

Sometimes we may chose to prioritize our goals. Priority may have a significant impact on project planning when we come to do implementation and migration work and when it comes to thinking about how we realize our project. In BES we use MoSCoW prioritization (Must Have, Should Have, Could Have, Won’t Have).

Figure 3 – Our Prioritized goals.

Representing Out Motivation To Stakeholders

ArchiMate is a fantastic way for architects to iterate through a design process; and more important than the actual views we create is the process we are running through of identifying stakeholders and connecting them together with the drivers and goals.

I would always think twice before sharing a motivation view with a senior stakeholder in the organization. They can look complicated and do nothing for the more senior members of the organization, beyond maybe showing that architects are doing something! The value we are bringing is in making sure that all the motivations are considered, so when somebody presents a PowerPoint with our goals on, you can be sure the goals are considered from different directions, and are good.

Validating the motivation views

Its important that the stakeholders feel ownership of the architectures we create; our value comes through ensuring that the needs of all our stakeholders are being managed as part of our architecture. Its important that we get this part of the architecture right, before we go on to look at how to realize these stakeholder desires. Understanding the goals and drivers of all our stakeholders may give cause to reprioritize how we do our developments. Sometimes it takes multiple iterations to get this right, but its important to do, because without understanding the things I show today there is a real risk that a project, or architecture may not be fit for purpose, or we may never be able to show that it achieved the value or goals that were intended. There’s nothing worse than being half way through a project and then realizing a stakeholders needs have not been met and have to redesign things..

Continued in Motivation Layer Modelling – Part 2.