"Stakeholder" in ArchiMate

[Paolo F Cantoni]

ArchiMate (since v2) has had a "Stakeholder" object.  The definition is:

A stakeholder is the role of an individual, team, or organization (or classes thereof) that represents their interests in the outcome of the architecture.

In its own words, ArchiMate seems to be defining a relationship between the Actor (individual, team, organisation) and the item they are interested in.

Consequently, I'm interested in what others think of dropping the Stakeholder item and creating, instead, a 'stakeholding' relationship.
There are a number of interesting upsides from this mechanism - such as adding various properties to the relationship.

Thoughts?
TIA,
Paolo

[Sunshine]

I can see why you might want to drop stakeholder as the examples like CIO, CFO given could simply be actors. Stakeholder could also be replaced by role. After all its just a specific type of role. However, I can't really see the value of creating yet another relationship called 'stakeholding'. May be you could elaborate with an example of how that would work better than just an association called 'stakeholder'?

[PeterHeintz]

Well, I am not a ArchiMate guy (at least not up to now).
The different contexts I know, a stakeholder is always the individual, team, organization and not a role.

I would say a stakeholder is a special actor (a “relevant actor”) and a stakeholder can play several roles.

But maybe in ArchiMate is : Stakeholder=Role.   

[Paolo F Cantoni]

I can see why you might want to drop stakeholder as the examples like CIO, CFO given could simply be actors. Stakeholder could also be replaced by role. After all its just a specific type of role. However, I can't really see the value of creating yet another relationship called 'stakeholding'. May be you could elaborate with an example of how that would work better than just an association called 'stakeholder'?

The current Stakeholder item is NOT a relationship it is an element.  The Stakeholder "CIO" would need to be created in addition to the (for example) "CIO" Actor - so we have two items for the same real world object.

The idea behind "stakeholding" is that relationships are named in the adverbial form.  Semantically, an "Association" named "Holds stake in" is identical to the "Stakehoding" relationship.

Paolo

[Glassboy]

What you're actually articulating is the whole Motivational layer is poorly thought out and semantically barren and is really just a sop to the TOGAF folks.

I do not agree tho' that you should replace it with a relationship.  The relationship isn't "stakeholding", it is instead one of the choices in what ever responsibility matric (https://en.wikipedia.org/wiki/Responsibility_assignment_matrix) your organisation has chosen to use.

For example

<marketing:stakeholder> -- accountable --> <drive better brand recognition:goal> <-- realize -- <all web sites will use our brand colours:principle>

[Simon M]

I would prefer to preserve the Stakeholder element and how it is used on ArchiMate diagrams. Instead I would define one or more relationship types to explicitly relate the stakeholder and the actor whose interest it represents.

This means that anyone familiar with ArchiMate but new to your models will still understand your model. You still have a clear place to document the exact interest the stakeholder explains, and the existing element can still be extended to add properties etc.

[Paolo F Cantoni]

What you're actually articulating is the whole Motivational layer is poorly thought out and semantically barren and is really just a sop to the TOGAF folks.

I do not agree tho' that you should replace it with a relationship.  The relationship isn't "stakeholding", it is instead one of the choices in what ever responsibility matric (https://en.wikipedia.org/wiki/Responsibility_assignment_matrix) your organisation has chosen to use.

For example

<marketing:stakeholder> -- accountable --> <drive better brand recognition:goal> <-- realize -- <all web sites will use our brand colours:principle>

Yes, that is exactly what I'm articulating.   

However, while I accept that we'll need the RACI (or RASCI) style relationships, I think the Stakeholding relationship is not quite the same semantics (unless ALL actors having a RASCI relationships are to be considered Stakeholders, perhaps - which is what you're saying yes?).  Until I sort it out, I've found that, in modelling, it's better to initially "go overboard" and consolidate afterwards that to try and separate incorrectly conflated concepts later.

Paolo

[Paolo F Cantoni]

I would prefer to preserve the Stakeholder element and how it is used on ArchiMate diagrams. Instead I would define one or more relationship types to explicitly relate the stakeholder and the actor whose interest it represents.

This means that anyone familiar with ArchiMate but new to your models will still understand your model. You still have a clear place to document the exact interest the stakeholder explains, and the existing element can still be extended to add properties etc.

Where things make sense, we do.  But when they don't, we don't.

One of my (adaptable) aphorisms is:  How understandable do you want the wrong answer?

Paolo

[Glassboy]

However, while I accept that we'll need the RACI (or RASCI) style relationships, I think the Stakeholding relationship is not quite the same semantics (unless ALL actors having a RASCI relationships are to be considered Stakeholders, perhaps - which is what you're saying yes?).  Until I sort it out, I've found that, in modelling, it's better to initially "go overboard" and consolidate afterwards that to try and separate incorrectly conflated concepts later.

Nothing paralyzes an organisation like no one knowing who makes decisions and no one making decisions.  That's what you're modelling with a "stakeholding" relationship.  While it may be a reflection of reality, you normalize and approve it if you model it.

I strongly encourage you not to do it and instead used Inform instead.

Stakeholders can only pretty much only have association relationships with every other element and if that isn't labelled with an accountability roles descriptor then you're probably modelling something very weird. 

[Glassboy]

but you know, if you want to build chaos and inconsistency into your model do it! :-)

[Paolo F Cantoni]

but you know, if you want to build chaos and inconsistency into your model do it! :-)

Spent just about all of my professional life NOT doing that... Not going to start now... 

I think your other post has convinced me.

However, just to make sure I understand you correctly.

You ARE saying that if an actor has a RASCI (/RACI) relationship with an item; then they are a stakeholder in that item (since, by definition, they have a stake in that item).  The nature of that stake holding is defined by the RASCI value.

Paolo

[Glassboy]

Short answer yes.

Longer answer.

I'm saying that the entire motivation layer was added to make it look like Archimate is a notation to do TOGAF with, i.e. suitable for Enterprise Architecture.

I'd hate to have a conversation with most Enterprise Architects about exactly what an actor is but a stakeholder is a party in a role with an interest in the element in concern.  Your average EA probably hasn't anything but the woolliest idea about the nature of the stake that role has in the situation.  And frankly as long as they have a legitimate person to have coffee meetings with they often don't care.

As an Enterprise Architect who often gets thrown into situations where everything has gone pear shaped the first two things I do is codify exactly what stake all the involved parties have and exactly whose money we're spending.  Generally I will create a UML diagram and stereotype associations between Actors and the elements I've used to model the problem space.

My take on the Archimate "stakeholder" is that stake refers to ownership and that we need to be explicit about what that ownership relationship is.  At a minimum you have the user community, the manager with the DFA for the asset, and the manager in the ICT organisation who has the DFA for the staff and other resources who support the asset.

You could use any term you wanted to describe ownership but chances are you have some sort of Risk or Security group that is doing a very similar thing to what you are with the Motivation layer and it just makes sense to use the same RACI\RASCI\RAPID language they do.

You will always come across some person who likes to think they have a stake, but they are neither responsible or accountable nor do they use the system et al in question.  They may be a manager who used to have a stake, an internal competitor, or someone with influence who feels they are a subject matter expert.  The benefit here is that using your accountability matrix to describe the nature of ownership\stake-holding you can neutralise their danger early.  And the danger to me is generally reality distortion to the model.

[Paolo F Cantoni]

Thanks GB,

Very useful!

Have a good weekend.

Paolo