Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Glassboy

Pages: [1] 2 3 ... 86
General Board / Re: Pros and Cons of mixing TOGAF and Archimate?
« on: August 14, 2019, 07:33:30 am »
Hi Håkan, you'll be fine modelling TOGAF with the ArchiMate notation.  What you need to look at first is actually the TOGAF content meta-model.  If you organize your elements according to the content meta model it all works out.

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 :-(


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 :-)

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.

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).

I've seen some relationships end up with stereotypes from multiple ArchiMate versions.

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.

I've just tested it in 13.0.1310 and it works.  Have you checked you do have an ArchiMate 2 flow stereotype on the relationship you're trying to export?

So to take one part of your problem

The problem in the OP remains, I still do not know if these new actors are humans or systems, or internal or external to the organisation

In reality how do you know these things?

The reason I ask if you have one API that is used internally and externally, and can be invoked by humans and systems you may not know.  That knowledge may only be in the data passed across the integration, which won't allow you to show the different types of agents in your model.

The better solution would be to move to a later version of EA.

I was wondering how long it was going to take before somebody brought use cases into the discussion

I wasn't actually meaning in the strict UML sense.  Just you need to model both how your system is being used and potentially misused.  It makes the security architecture and reviews so much easier to deal with solid cases.

Bugs and Issues / Re: V14 Serious Bugs in Archimate3 implementation
« on: August 02, 2019, 10:15:54 am »
What version/build are you using? I remember plenty of "missing" quicklink entries being reported in v14, and the issue with the composition as well. All 4 of your issues appear to be correct in v15.

He says in the topic :-)

agree but in our case the person is not directly interfacing with the business we are modelling, the person is interfacing with an external 3rd party who in turn is using a system-to-system interface to interact with us. For example, mortgage can be submitted by a broker using and API. An even better example are custom declarations, the majority of the time they are submitted using system-to-system interfaces by external systems capable of automating complex logistic tasks, although some can be submitted through a direct interaction between a Person and the system handling custom declarations. In a nutshell, although there is a human involved in the process, the human on a system-to-system interaction is often out of boundaries and the external system is performing the role of a person. Furthermore, a person will perform one operation - i.e., application/submission - at a time but a system can perform them in batches.

I think that what I have in mind and your Actor/Role/Agent metamodel are not to far away, let me think about it.

When you think about it, keep in mind that you are modelling your use cases, the approach you take should also be able to model misuse cases (such as bad actors).

Yes, it clears the control but not the history.

That's the cause of a lot of organisational data leakage with applications like email clients :-)

When generating MDG files, the wizard starts with being able to optionally select an existing MTS file.  The drop-down list cannot be edited (such as to remove incorrectly typed or no longer required MTS file.

Are you saying shift+delete doesn't work on that particular control?
Yes! It only seems to delete the value selected, NOT the value in the list.

Did you try it?  Maybe I'm not doing it correctly...


I couldn't be bothered mucking up the list to try it, but I asked because most people don't know that's the normal key combination for that sort of control.

Pages: [1] 2 3 ... 86