Real t_diagramobjects for Virtual Connector Ends - please, please, please?

[Paolo F Cantoni]

I've previously asserted that Virtual Connector Ends (VCEs) should be implemented as specialized t_diagramobject items.  That is, they are real diagram objects, but they are clearly identified as VCEs.

I've also mentioned the the Agent as Actor in Role paradigm.  In ArchiMate, Actors can have Roles (Assignment arc) but it can't resolve the many-to-many relationships between Actors and Roles (which the Agent paradigm does).
In the Motivation Aspect, it (ArchiMate) has a Stakeholder element.  I guess that if an Organisational Unit (say, OU1 is a Stakeholder in something, then you'd create a Stakeholder element named OU1.  So far, so good.

However, it's not "Rocket Science" to figure out that you also have an Actor element (at least) calledOU1and it isn't the Stakeholder element OU1- whereas in real life, there is only one OU1and it IS an Organisation Unit.  Sometimes, it acts as an Actor in the Role of Stakeholder (that is, Stakeholder is a Role - the specification says so) and sometimes it acts in a different role in some other context.

We're going to solve this problem by allowing the Shapescript for the Agent to respond to user requests to change its shape to look like a Stakeholder, when required.
So far, so good (again).

Let's suppose that on a given diagram the OU1is both a Stakeholder in something and an Owner of the same thing.  This poses a problem.  Assuming the Shapescript can draw both a Stakeholder and Owner shape, it it infeasible to draw both for the same element!

Fortunately, EA provides a remedy for this infeasibility - the Virtual Connector End.  The two roles are managed by two arcs with the appropriate semantics and so we can could two VCEs, one that is rendered as a Stakeholder, the other as Owner.

Unfortunately, the current (incomplete) implementation doesn't allow you to do this.  If, however, VCEs were implemented as real t_diagramobject items, which then would have individual User Specific Diagram Properties and therefore the Shapescript could react to the specifics of each diagram object.

Please, please, please can we have real t_diagramobject items for VCEs?

Thoughts?

Reported,
Paolo

[Glassboy]

However, it's not "Rocket Science" to figure out that you also have an Actor element (at least) calledOU1and it isn't the Stakeholder element OU1- whereas in real life, there is only one OU1and it IS an Organisation Unit.  Sometimes, it acts as an Actor in the Role of Stakeholder (that is, Stakeholder is a Role - the specification says so) and sometimes it acts in a different role in some other context.

If you're saying that every (Motivation) Stakeholder will have a matching (Business) Actor, then no, that is not true.

From 3.0.1 Spec  Examples of stakeholders are the CEO, the board of directors, shareholders, customers, business and application architects, but also legislative authorities.

Stakeholders may never be expressed at the business layer because they do not interact with the Business Service directly.  If you were particularly thorough you might actually have them interacting with a data object or influencing a contract but you can you can model that across layers.

[Paolo F Cantoni]

Hi Glassboy,

However, it's not "Rocket Science" to figure out that you also have an Actor element (at least) calledOU1and it isn't the Stakeholder element OU1- whereas in real life, there is only one OU1and it IS an Organisation Unit.  Sometimes, it acts as an Actor in the Role of Stakeholder (that is, Stakeholder is a Role - the specification says so) and sometimes it acts in a different role in some other context.

If you're saying that every (Motivation) Stakeholder will have a matching (Business) Actor, then no, that is not true.

It's not me who says that. Section 6.2.1 of ArchiMate 3.0.1 says: "A stakeholder is the role of an individual, team, or organization (or classes thereof) that
represents their interests in the outcome of the architecture."  Since "all of the above" are Actors...  Do you have an example of any stakeholder that is not a role played by an actor? (I could use the Magaret Thatcher interrogative^[1]:  "Name three" )

From 3.0.1 Spec  Examples of stakeholders are the CEO, the board of directors, shareholders, customers, business and application architects, but also legislative authorities.

Cases in point...

Stakeholders may never be expressed at the business layer because they do not interact with the Business Service directly.  If you were particularly thorough you might actually have them interacting with a data object or influencing a contract but you can model that across layers.

Yes, that's the kind of thing we're doing.

My concern WRT VCEs is that should you want to express a relationship arc as a vertex, then you could; explicitly (and with correct semantics) by using a VCE.

Stakeholder was just a convenient example from the ArchiMate Specification.  The mechanism, however, applies to any role played by any actor wrt to any item.

Paolo

^[1]  In the 1980s, Mrs Thatcher was interviewed by the Australian journalist, George Negus (for Oz 60 Minutes).  He started an exchange by asserting:  "People are saying..."  To which "the Iron Lady" immediately interjected: "Name three".  He was stopped "dead in his tracks".

[Glassboy]

You appear to be begging the question somewhat.  The word Actor is not used in 6.2.1, and two of the examples are not business actors, no matter how huge the ego of the application architect is.  The use of the word role in that definition is not business role, its a TOGAFism, which is not they way I would have written the definition personally.

And in terms of an example, the one I highlighted is the perfect example.  Organisations with a regulatory mandate are not responsibility for business behavior (in the ArchiMate sense). 

I think if you look at the relationships allowed from Stakeholder to both Role and Actor, it's obvious a Stakeholder might have an equivalent role (their sigil is the same), and an Actor might be assigned into a stakeholder (role).

[Paolo F Cantoni]

You appear to be begging the question somewhat.  The word Actor is not used in 6.2.1, and two of the examples are not business actors, no matter how huge the ego of the application architect is.  The use of the word role in that definition is not a business role, it's a TOGAFism, which is not the way I would have written the definition personally.

And in terms of an example, the one I highlighted is the perfect example.  Organisations with a regulatory mandate are not responsible for business behaviour (in the ArchiMate sense). 

I think if you look at the relationships allowed from Stakeholder to both Role and Actor, it's obvious a Stakeholder might have an equivalent role (their sigil is the same), and an Actor might be assigned into a stakeholder (role).

Ahh...  It's the old "Oils ain't oils" problem...  A UML Actor is a Role, a Togaf Role is not a Business Role; a Business Role is not a Role.  No wonder the punters get annoyed with us.

I hear what you're saying and while I'm using ArchiMate terms and definitions in this example, we're using our own variant where a Role is a Role is a Role.

As an aside, is the term Responsible used as Executor of or Accountable for?  in this context?  We've decided that the Actor is capable of agency, the Role defines the scope of the agency, but neither actually has agency until they are an agent (an actor playing a role).

Again, though, my main point was wrt to VCEs, not stakeholders...

Paolo

[Glassboy]

Generally my ArchiMate Business Actors are all proper nouns; either real organisational units or real people.  One of the things that I have learnt over the years trying to implement role based security is "job titles" don't actually map to roles.  Every human has a different history and set of capabilities and skills, and consequently they all do different things.

So I use Actor and Role quite distinctly.

[Paolo F Cantoni]

Generally, my ArchiMate Business Actors are all proper nouns; either real organisational units or real people.  One of the things that I have learnt over the years trying to implement role-based security is "job titles" don't actually map to roles.  Every human has a different history and set of capabilities and skills, and consequently, they all do different things.

So I use Actor and Role quite distinctly.

Everything you've said above, I agree with.  With the extension that you've talked about specific Actors.  We allow placeholder Actors that can be "substituted at runtime" so to speak with specific actors.  However, the placeholders can only be specified in terms of the properties of the actor.  For example, a male actor is allowed, CEO (as an actor) is NOT.  However, CEO as an agent is allowed (since it is shorthand for any actor playing the role of CEO)

Do you have any thoughts on VCEs as true t_diagramobject items?   

Paolo

[Glassboy]

Do you have any thoughts on VCEs as true t_diagramobject items?   

I'm stuck with v13 so new functionality is of little relevance to me :-)

[Paolo F Cantoni]

Do you have any thoughts on VCEs as true t_diagramobject items?   

I'm stuck with v13 so new functionality is of little relevance to me :-)

VCEs have been around a while...  I'm pretty certain they were in v13, but I take your point that you may not have seen the relevance or utility (if implemented properly) of the new functionality.  It took me a while to understand what was "going on".

Paolo

[qwerty]

I can confirm that 13.5 has this option in the connector context menu.

However, you know that in Sparxland everyone not up in the trees at three is caught in StyleEx.

q.

[Glassboy]

VCEs have been around a while...  I'm pretty certain they were in v13, but I take your point that you may not have seen the relevance or utility (if implemented properly) of the new functionality.  It took me a while to understand what was "going on".

Oh I understand the utility (and the need for bug fixes), but being at the mercy of an uncaring corporate beast and Sparx not having an evangelist programme, I'm stuck with what my current version does :-(