TOGAF plug-in - missing relationships

[andrew.ward@ubs.com]

I have just started experimenting with the TOGAF plug-in (version 17.0.4) and I have noticed the following gaps.

In the TOGAF 9.1 specification: 34.7 Metamodel Relationships (page 368) the following relationships should exist:

1. Function "is bounded by" Service relationship
2. Service "Is realized through" Logical Application Component

Both of these appear to be missing. Can you please add them.

Further, I am not clear how best to model the relationship between a Logical Application Component and the Function(s) it supports

In the TOGAF 9.1 specification: 35.6.5 Phase C: Application Architecture - Application/Function Matrix (page 393)

The Application/Function matrix is a two-dimensional table with Logical Application Component on one axis and Function on the other axis. The relationship between these two entities is a composite of a number of metamodel
relationships that need validating:
- Function is bounded by Service
- Services are realized by Logical/Physical Application Components

The mapping between Application and Function is clearly very useful - and I would like to be able to generate the Application/Function Matrix.

If you could comment on this, and perhaps add it to the next version of the manual (when the missing relationships are added) that would be great. The current TOGAF plug-in manual does not demonstrate the use of Functions - however, modelling a functional decomposition and explaining the mapping to applications is very important.

Thanks
Andrew

[lintut]

Hello Andrew,

We support 9.0 TOGAF version in our product, for this reason you cannot find these two relationships. These changes are included in our roadmap.

If you want to analyze your model using matrixes, we offer completely customizable matrices where you can put the elements and the relationships that you want. The example you may see here: http://www.nomagic.com/files/viewlets/D ... .html?ml=1.

Have a nice day,
Lina Tutkute

[andrew.ward@ubs.com]

TOGAF 9.1 was released in 2011. When in your roadmap do you plan to support it?

In your experience, do customers actually use the TOGAF plug-in for real projects, or do they tend to use it for ideas around how to map the TOGAF concepts? (This may be why 9.1 has yet to be implemented.)

I certainly found it useful to experiment with the plug-in to see how the concepts in TOGAF can be translated into UML.

In terms of feedback, you have chosen to map Physical Application Component to Artifact. There is probably some good logic to this (e.g. "physical" implies "deployable" implies "artifact"), but I would have preferred it mapped to Component. The reason for this is that at an Enterprise Architecture level, the "physical" decisions being made are around system selection and interfacing, and are still higher level than "artifact". I like the separation between Logical and Physical, but I still want to model the Information Flows and sub-structures of a Physical Application Component.

Logical Application Component (TOGAF) => "..application functionality that is independent of a particular implementation"
Physical Application Component (TOGAF) => "..application, application module, application service, or other deployable component of functionality"
Artifact (from UML spec) => "..the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system. Examples of artifacts include model files, source files, scripts, and binary executable files, a table in a database system, a development deliverable, ..."

Yes, I could model both the conceptual (logical) and concrete (physical) applications as Logical Application Components, but the Physical Application Component stereotype contains all the tags relating to vendor and non-functional capabilities.

Thanks
Andrew