Pros and Cons of mixing TOGAF and Archimate?

[HLidstrom]

I have some experience using Sparx for UML modeling, but I am rusty. I have worked quite a lot adapting Enterprise Architecture for different organization needs and tools. The organization I work for now has already made the decision to follow TOGAF ADM and use the ArchiMate notation (mostly). My task at hand is to draft the rules that will ensure consistency in our Sparx EA modeling. To that end:

Where do I find documents describing the TOGAF and ArchiMate metamodels, as implemented in Sparx EA? That is, descriptions of element types with their attributes and descriptions of which relationship types can be used (are recommended) between which element types?

Can anybody share pros and cons of mixing TOGAF and ArchiMate types in the same model? E.g., Architecture Principles. Both TOGAF and ArchiMate have a Principle type. I should stick to one. The TOGAF type has attributes (tagged values) for rationale and implications in addition to name and description (which is all the ArchiMate type has) I am tempted to use the TOGAF type, but will that come back to bite me later, in a mostly ArchiMate model?

Any insights would be much appreciated.
Håkan Lidström

[Glassboy]

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.

[Sunshine]

After spending over a decade using UML I started my career as an Enterprise architect using TOGAF but found as it didn't have a formal language just a lifecycle, metamodel along with some guidelines, I adopted ArchiMate way back in 2007 to do the modelling. It had the advantage of being simple and connecting business processes with applications and infrastructure. Looking back that was a good choice as its now a well established standard for enterprise architecture.
The descriptions of the elements can be found in Archimate V3.01 of the specification C179 from the open group. However it does not define attributes. By default Sparx EA provide

• Name
• Alias
• Version
• Notes
• Status
• Complexity

Which provide a good start however not quite enough for all elements to do proper Enterprise Architecture so I've added more attributes through tag values via a custom MDG. For example for the "application component" I've added

• Review Date
• Product Owner
• Number of Users
• Criticality
• Security Classification
• Security Accreditation Status
• ...

I've since had a look at the TOGAF MDG and found it too complex with an unrecognised notation.

I've got a pretty simple approach to EA now

• What's the motivations for change? Capture in ArchiMate Motivation model
• What's the present state? Capture with Business, Application, Technology Architecture views
• Whats the desired future state? Design with Business, Application, Technology Architecture views
• How do we get there? Use implementation diagrams like work package roadmaps and plateau state transitions
• Generate capital plan documents and investment cases from the motivation models and work package roadmap for Governance commitee
• When approved work with Project Management Office to deliver

I hardly refer to TOGAF now.
If you are interested in using TOGAF with ArchiMate there are set of documents written by the Open Group and called "Harmony" that provide guidance. I think it might be a bit dated as it referred to Archimate V1.0 but there is some good pointers. There is even a webinar. https://publications.opengroup.org/catalogsearch/result/?q=harmony

Hope that helps. Good luck on your journey

[Richard Freggi]

TOGAF explicitly says it is notation - agnostic and is compatible with UML, Archimate and others.  No issues!

[HLidstrom]

Thanks all for your replies. I'm really not looking for a discussion about the pros and cons of  TOGAF and ArchiMate as such. That choice has already been made for me.
 I need insights on hands-on modeling in Sparx, using a mix of the ArchiMate and TOGAF types provided in the TOGAF MDG. Yes, TOGAF is a method and ArchiMate is a notation. But when I install the TOGAF MDG I get a TOGAF perspective that provides a set of element types, i.e., a notation. I also get an ArchiMate perspective that provides another set, i.e., the ArchiMate notation. There is overlap between these notations, e.g., the type Perspective that I mentioned in my original post.
 
Another example. There is a TOGAF type "OrganizationUnit". There is also an ArchiMate type "Actor" that can be used to model active structure elements, such as, organization units. Will it matter later on which I use? Will I be restricted to one set of organization relationships if I choose OrganizationUnit and another if I choose Actor? Or, it really doesn't matter because when it comes down to it both are actually stereotypes of Class and I can associate any way I want?

I know Actor comes with a nice shape to show on diagrams and OrganizationUnit just shows as a plain Class box, but I'm not worried about that at the moment. I worry about getting the underlying information structure right. About being able to capture EA information in a way that can be reported on in a format that will give the proper information to decision makers. Keeping in mind that different decisions will require different sub-sets of EA model data.

Any insights on the practical implications of mixing the notations in Sparx EA?

[Geert Bellekens]

Hi,

Using the TOGAF framework with the ArchiMate notation is pretty much a common practice.

In terms of notation, I would try to stick as close as possible to the standard notation.

What we see often is that different areas in the model use different notations, often

- Architecture -> ArchiMate
- Business Processes -> BPMN
- Functional/Technical analyses -> UML

Also very often the standard notation falls short and is extended with organization specific properties.
If done right this is done using UML profiles and MDG technologies.
Also the links between the different notation are (for obvious reasons) non standard and can be added by an organisation specific MDG.

Geert

[Richard Freggi]

Hi,

Using the TOGAF framework with the ArchiMate notation is pretty much a common practice.

In terms of notation, I would try to stick as close as possible to the standard notation.

What we see often is that different areas in the model use different notations, often

- Architecture -> ArchiMate
- Business Processes -> BPMN
- Functional/Technical analyses -> UML

Also very often the standard notation falls short and is extended with organization specific properties.
If done right this is done using UML profiles and MDG technologies.
Also the links between the different notation are (for obvious reasons) non standard and can be added by an organisation specific MDG.

Geert

Just a side comment for the sake of talking and sharing here. Not trying to make a point of anything.
Mixing notations for different levels of architecture (conceptual, logical, physical) is a common practice and a cause of many errors and misunderstandings.
What I have seen working reliably in my experience is

- Architecture -> Conceptual level UML use case, class, package views
- Business Processes -> BPMN Conceptual (logical if needed) -> UML sequence diagrams
- Functional/Technical analyses -> UML -> Logical level UML sequence, class and component diagrams

There is a huge benefit in clarity, accuracy and efficiency in using the same notation and same elements for all architectural levels.

My experience is that Archimate could kinda sorta work but it lacks class diagram / data modeling which is critical for process/system harmonization and robust taxonomy/semantics; also Archimate does not have a robust metamodel which supports model extensibility and scalability as well as UML. 

Getting off my soap box now, sorry for the inconvenience.

[HLidstrom]

Thanks to all for the input. It seems I should not worry too much about mixing element types from different perspectives (if that is the proper Sparx term to use here), as long as I and my team mates do it consistently.

[Paolo F Cantoni]

Thanks to all for the input. It seems I should not worry too much about mixing element types from different perspectives (if that is the proper Sparx term to use here), as long as I and my teammates do it consistently.

Yes, Håkan,

You are absolutely right!  "It is better to be consistently wrong than inconsistently wrong".  I'm not expressing judgement here, it's just one of my aphorisms.  Consistency is what counts!  (see my tag)

When considering the example you provided, I have previously expressed the problem as trying to make one item when the different modelling technologies suggest you need to have more than one.  If you consider a specific instance of an Organisation Unit ("Office of the CEO") it IS (structurally) an organisation unit but it behaves as an Actor.  So my advice would be to create an Organisation Unit and recognise it can also be used as an Actor and be used is the place of an Actor where appropriate.

I have written some stuff on the "Agent as Actor in a Role" paradigm in recent posts.  They may be of use to you.

HTH,
Paolo

PS: Manage Complexity,
   .   .   Reduce Ambiguity,
   .   .   .   .   Eliminate Inconsistency! ^TM

Is what we try to do with our modelling...

[Sunshine]

...
 I need insights on hands-on modeling in Sparx, using a mix of the ArchiMate and TOGAF types provided in the TOGAF MDG. Yes, TOGAF is a method and ArchiMate is a notation. But when I install the TOGAF MDG I get a TOGAF perspective that provides a set of element types, i.e., a notation. I also get an ArchiMate perspective that provides another set, i.e., the ArchiMate notation. There is overlap between these notations, e.g., the type Perspective that I mentioned in my original post.

Similar to what Geert has mentioned I use a mix of Archimate, BPMN and UML for different levels of abstraction. I chose these as they are standard notations. The TOGAF MDG whilst useful for TOGAF practitioners is not standard notation and therefore has limited literature to help use it.
- Enterprise Architecture -> ArchiMate for those high level elements
- Business Process details -> BPMN (elaborates on the Archimate Process with swimlanes and activities)
- Detailed Design -> UML ( Class diagrams, state diagrams, detailed deployment diagrams etc)

Try not to duplicate the same thing in different notations as it becomes an overhead to maintain.

Another example. There is a TOGAF type "OrganizationUnit". There is also an ArchiMate type "Actor" that can be used to model active structure elements, such as, organization units. Will it matter later on which I use? Will I be restricted to one set of organization relationships if I choose OrganizationUnit and another if I choose Actor? Or, it really doesn't matter because when it comes down to it both are actually stereotypes of Class and I can associate any way I want?
I know Actor comes with a nice shape to show on diagrams and OrganizationUnit just shows as a plain Class box, but I'm not worried about that at the moment. I worry about getting the underlying information structure right. About being able to capture EA information in a way that can be reported on in a format that will give the proper information to decision makers. Keeping in mind that different decisions will require different sub-sets of EA model data.

Any insights on the practical implications of mixing the notations in Sparx EA?

I'd suggest just use either the TOGAF MDG or the three mentioned above. If you decide after a period of time you want to change you can run a script to change the types. Like I said before the TOGAF MDG has non-standard notation and so literature is limited on how to use it. On the other hand the TOGAF MDG has attributes on some of those elements that may be useful.

Don't over think it just do some modelling in your preferred option (you know you have one) and see how it works out.

[Modesto Vega]

[..]  If you consider a specific instance of an Organisation Unit ("Office of the CEO") it IS (structurally) an organisation unit but it behaves as an Actor.  So my advice would be to create an Organisation Unit and recognise it can also be used as an Actor and be used is the place of an Actor where appropriate.

I have written some stuff on the "Agent as Actor in a Role" paradigm in recent posts.  They may be of use to you.

Organisational Units and Organisation are indeed Actors in a similar way as people and systems. A common problem with a framework like TOGAF or modelling languages like ArchiMate, UML or BPMN is that they do are not capable of supporting all of the modelling nuances.

I find TOGAF, not necessarily the Sparx EA TOGAF MDG, more extensible than ArchiMate or BPMN. I would not dare to try extending ArchiMate or BPMN.

What I have seen working reliably in my experience is

- Architecture -> Conceptual level UML use case, class, package views
- Business Processes -> BPMN Conceptual (logical if needed) -> UML sequence diagrams
- Functional/Technical analyses -> UML -> Logical level UML sequence, class and component diagrams

In terms of notation, I would try to stick as close as possible to the standard notation.

What we see often is that different areas in the model use different notations, often

- Architecture -> ArchiMate
- Business Processes -> BPMN
- Functional/Technical analyses -> UML

Not entirely sure I agree with this, it depends on what you mean with architecture. My experience is that, if you mean enterprise architecture, I prefer to use UML rather than ArchiMate, because UML is easier to extend (note the emphasis). The biggest 3 problems I have with ArchiMate for architecture are:

• It does not support Organisations, Organisational Units and Organisational (or Data Exchange) Networks
• It does not model Information System and interactions between very well. In fact, it does no have the concept of Information System
• The Business Object is insufficient to make any serious attempt at creating an Enterprise Conceptual Data Model

[Sunshine]

Not entirely sure I agree with this, it depends on what you mean with architecture. My experience is that, if you mean enterprise architecture, I prefer to use UML rather than ArchiMate, because UML is easier to extend (note the emphasis).

The advantage of using ArchiMate over UML for Enterprise Architecture is that you don't need to extended it as its all as done for you. No point in making work for your self aye?

The biggest 3 problems I have with ArchiMate for architecture are:

• It does not support Organisations, Organisational Units and Organisational (or Data Exchange) Networks

Not a problem as Organisations, Organisational Units are supported, if you read the literature you'll see they map on to business actor. Data exchange is modelled as flow. Business interactions can be used to model relationships between behavioural elements and Business Collaborations can be used to model relationships between structural elements.

• It does not model Information System and interactions between very well. In fact, it does no have the concept of Information System

Again if you read the literature you'll see Information System Service is modelled as an application service and the logical and physical information systems are modelled as an Application Components.  Application Interactions and Collaborations are there too incase you were wondering.

• The Business Object is insufficient to make any serious attempt at creating an Enterprise Conceptual Data Model

Enterprise Conceptual data models can be easily modelled with groups and business objects. Granted when you do a logical data model or physical data model and need to define attributes then of course UML is better, however Sparx EA does allow you to add attributes to ArchiMate Business and Application Objects and you can see these by disabling the shapescript on the diagram. I prefer data modelling with UML.

[Modesto Vega]

Not entirely sure I agree with this, it depends on what you mean with architecture. My experience is that, if you mean enterprise architecture, I prefer to use UML rather than ArchiMate, because UML is easier to extend (note the emphasis).

The advantage of using ArchiMate over UML for Enterprise Architecture is that you don't need to extended it as its all as done for you. No point in making work for your self aye?

The biggest 3 problems I have with ArchiMate for architecture are:

• It does not support Organisations, Organisational Units and Organisational (or Data Exchange) Networks

Not a problem as Organisations, Organisational Units are supported, if you read the literature you'll see they map on to business actor. Data exchange is modelled as flow. Business interactions can be used to model relationships between behavioural elements and Business Collaborations can be used to model relationships between structural elements.

• It does not model Information System and interactions between very well. In fact, it does no have the concept of Information System

Again if you read the literature you'll see Information System Service is modelled as an application service and the logical and physical information systems are modelled as an Application Components.  Application Interactions and Collaborations are there too incase you were wondering.

• The Business Object is insufficient to make any serious attempt at creating an Enterprise Conceptual Data Model

Enterprise Conceptual data models can be easily modelled with groups and business objects. Granted when you do a logical data model or physical data model and need to define attributes then of course UML is better, however Sparx EA does allow you to add attributes to ArchiMate Business and Application Objects and you can see these by disabling the shapescript on the diagram. I prefer data modelling with UML.

Sunshine, you are obviously a modelling language polyglot capable of translating from one language/framework to another. This is excellent but may I suggest you may have missed the point.

Of course you can model Organisations and Organisational Units as Business Actors, Conceptual Data Entities as Business Objects, Information Systems as Applications Services, Logical & Physical Systems as Application Components. But you have just given me a translation and I think a lot information has been lost in the translation.

My point is that ArchiMate has a number of vocabulary limitations some of which TOGAF does not have. Those vocabulary limitations can only bypassed through (explained) translations. Sometimes is better to talk a more suitable language, specifically if certain nuances need to be captured.

Edit 23 August 2019: If ArchiMate were a modelling language language short of terms, I would have less of a problem. But ArchiMate is a term rich language and I find very interesting/telling which terms have been left out, either by accident or intentionally.

[Sunshine]

Sunshine, you are obviously a modelling language polyglot capable of translating from one language/framework to another. This is excellent but may I suggest you may have missed the point.

Thanks for the complement being a ployglot but I'll agree to disagree with you on missing the point.

Of course you can model Organisations and Organisational Units as Business Actors, Conceptual Data Entities as Business Objects, Information Systems as Applications Services, Logical & Physical Systems as Application Components. But you have just given me a translation and I think a lot information has been lost in the translation.

My point is that ArchiMate has a number of vocabulary limitations some of which TOGAF does not have. Those vocabulary limitations can only bypassed through (explained) translations. Sometimes is better to talk a more suitable language, specifically if certain nuances need to be captured.

Again tend to disagree regarding information loss in translation. At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.  The other is that those terms used by TOGAF aren't necessarily recognised by business or IT folk so there is translation to fit in the constraints of TOGAF terminology. Granted I think the TOGAF terminology is in some cases better that ArchiMate. The Open Group recognised this short fall in TOGAF and so put a lot of effort into harmonising ArchiMate and TOGAF and it looked like they may combine the two at one stage but I think they ran out of steam.
The fact of the matter is that TOGAF has a content meta model that whilst useful lacks a notation. So when you draw a diagram there is no defined shapes what a business unit looks like. Thus how do you know what that shape represents? Yes Sparx Systems has represented the TOGAF meta model with shapes but they aren't standardised so not necessarily good for communicating with someone who doesn't have Sparx EA.

If you look at other disciplines in building architecture or engineering they all have defined notations which clarifies what things mean on a diagram. Why do they do this? Well so that the person receiving the information in diagram form can accurately interpret it.

In the ideal world I'd like to see ArchiMate Notation meta model elements better named to match TOGAF element types that way we'd all be happy. For now I'm using ArchiMate until something better comes along. Been waiting for 12 years now

BTW: I created my own version of ArchiMate MDG with extensions and attributes that aren't available in the standard ArchiMate 3 MDG because it wasn't up to the job of doing Enterprise Architecture properly. Found the same with the TOGAF MDG but between the two TOGAF was slightly better. Sounds to me like your more comfortable with TOGAF anyway so just stick with that.

[Glassboy]

At the end of the day I think you'll find that TOGAF has limits in the real world too, the biggest show stopper is the lack of a notation.

Well the biggest show stopper is it creates a business for talking about doing IT, when most businesses want people just to get on and support the business that earns the revenue :-)