ArchiMate Interface non-icon style issue

[Paolo F Cantoni]

ArchiMate Interfaces can be defined in Sparx EA as:

• Required
• Provided
• Symmetric
• Assembly

The v1 specification only seems to list the first 3, the v2 specification doesn't seem to mention any.
Be that as it may, EA provides the icon view with separate icons for each of the four types, but the non-icon view only shows the provided form - regardless of the setting of the interface type.

Consistency would require that the non-icon view should have the decoration reflect the icon in the icon view.

Before I report a bug, is this just me being consistent or have I misunderstood the way ArchiMate works?

TIA,
Paolo

[Sunshine]

I've just looked at version 2 of the Archimate Spec and it does seem to talk about provided and required interface notation for business, application and infrastructure in Sections 3.2.4, 4.2.3 and 5.2.4.

Interestingly the spec doesn't mentioned anything about different icons in the top right corner for the different types for the non-icon view. I suspect  it may be an oversight in the Archimate Spec and that Sparx will say we've just implemented whats in the spec.

I don't think its a bug its just the spec is missing clarification.

I think the Archimate Spec still requires some work for instance I did notice that spec had data object under structural concepts for the application layer yet the meta model has it as an informational  concept. When I raised it with Sparx I got the we've just implemented the spec response. Thus the data object is under structural elements for the tool box.  

[Paolo F Cantoni]

[size=18]...[/size]
I think the Archimate Spec still requires some work
[size=18]...[/size]

Shoa durss, massa boss!  

Especially in the data area!

We Data Dudes have been "short changed" again...

Paolo

[Sunshine]

I guess ArchiMate can't be all things to all people. It was intended for Enterprise Architects working at a higher level of abstraction and it seems to cover most things reasonably well there. When it comes to data it is a bit light but then again there are plenty of data modelling notations to use so why invent yet another one. It is a bit inconvenient to define a data object in Archimate then have to re-create it in another notation but its possible to automate using transformations. Kind of similar to  PIM->PSM. But then again the guys who model behaviour have the same issue as Archimate doesn't support events and states nor sequence diagrams. I'm in two minds about whether Archimate should become more complicated to satisfy the next level of detail. Its difficult enough to get Business folk and CxO's to understand ArchiMate now without making it more complex. On the other hand it is missing the detail to implement things however there are alternatives such as UML and ERD to mention just a few. I'm okay with mixing notations to get things done but I know it can be difficult for some folk.
Well that's my 2 cents worth as they say.