Modeling the needs and wants from stakeholders can be challenging when you do enterprise architecture. The ArchiMate specification, made by the Open Group, offers a general guidance on the meaning of the elements used to model such objects. Nevertheless, understanding how to create an accurate diagram is critical because you’re about to set the foundation of the whole architecture. 

Probably the biggest obstacle to do this step is the fact that there are so many definitions and ways to understand the word “stakeholder” out there, and on top of that we bring our own preconceptions with us, this may lead us to clash with the definitions laid in the specification specially if you adhere strictly to Togaf, this may be especially true when several people are involved in this phase of the project. I intend to give some explanations and provide an example in order to help any practitioner trying to improve his or her skills, I am by no means an expert and any feedback will be greatly appreciated (and used to enhance this article). 

I am assuming that if you are reading this you are already familiar with some of the concepts of the specification such as “layers”, “relations” or “aspects”, to name a few so I will skip on the most basic definitions and focus on the motivation elements. 

That being said, I would like to begin, so let us talk about stakeholders. 

Who are the Stakeholders?

Stakeholders are usually the people who have an interest in the work to be done when you do enterprise architecture related tasks. They could be project sponsors, the team requesting a change in the systems of the company, C level executives or anyone where the initiative for change originated. In Togaf, stakeholder is usually anyone who will be impacted by a project or activity (customers, communities, investors, etc.) but this is not necessarily true in our Archimate diagram, here we are only concerned with the source of the motivation and therefore it is preferable to be specific. If finance wants to change the ERP (Enterprise Resource Planning) and related processes, then they can be the stakeholders. The CFO requesting the change on F&A department’s behalf can also be a stakeholder in that case, but unlike in a normal stakeholder analysis, the factory workers whose salaries will be controlled with the new implementation would not be the stakeholders as per the need of the modeling process. 

How to identify Stakeholders?

A few questions that you can ask yourself when defining the stakeholders in the diagram are: 

• Who has the final say in the decision regarding the project? 
• Whose budget is paying for the project? 
• Who is going to interact directly with the new tools or systems? 
• Whose processes will change dramatically because of this implementation? 
• If you are the leader of the implementation, to whom are you responsible for this project? 

The answers may not be clear cut, but the newfound information should help you to identify the stakeholders, who may be individuals, teams or departments. 

To help illustrate the concept I here’s an example from a diagram I made recently. 

Who is calling the shots?

In this scenario, an American company that does bio-fuel is losing money due to some efficiency and plant contamination issues, management has requested an improvement of the company processes related to traceability, quality testing and factory productivity. Since the C level execs where the ones starting the initiative, they have been set as the main stakeholders of the process. Ideally this should be a bottom-top process but since this is a relatively small company it is still very hierarchic, so to satisfy the needs of the company following the decision-making structure, the executives and their concerns become the focus of the diagram. 

I know what you’re thinking about this case but here’s a tip: don’t build your architecture on cultural ideals, in my opinion good leadership encourages every employee to lead processes and to make decisions based on their level of involvement in said processes, however, in real life there are different sets of corporate culture and treating the project like the company follows your ideals instead of their own won’t do you any good, if the owner calls the shots and his opinion can derail the whole project then the owner is definitively a core stakeholder, even if he barely touches the implementation. 

All in all, stakeholders should not be hard to identify, quite the opposite, you may end up with so many stakeholders that making a single change down the road will require a mountain of reviews and approvals so do yourself a favor: try to keep it lean (not necessarily ultra simple, just lean).

In the future I will revisit this case to examine the other elements involved in the motivation layer and how they relate to the stakeholders, so check out the tags if you are interested on seeing how to connect stakeholders to drivers… but what the heck are drivers? 

I will answer that in another article, stay tuned. 

This site uses Akismet to reduce spam. Learn how your comment data is processed.