Best Practice to represent Recovery Site

[jennifer.cui]

Hi there,
Given that Sparx does not allow for the same item to be added to a diagram twice, what is the best practice for creating deployment diagrams with 2 physical sites/locations where the second location is an exact replica of the first using the VMware SRM technology?

http://www.vmwarearena.com/vmware-site-recovery-manager-srm-6-0-part-1-overview-and-achitecture/


Thanks in advance!

[qwerty]

The best is just to avoid it.

However, people have urged Sparx enough to come up with something. If you have two related elements you can use the context  menu of the connector Virtualize connector end. Hard to explain. So play around with it in a test model and see if you can use it. (I wouldn't)

q.

[Paolo F Cantoni]

Hi there,
Given that Sparx does not allow for the same item to be added to a diagram twice, what is the best practice for creating deployment diagrams with 2 physical sites/locations where the second location is an exact replica of the first using the VMware SRM technology?

http://www.vmwarearena.com/vmware-site-recovery-manager-srm-6-0-part-1-overview-and-achitecture/


Thanks in advance!

Hi Jennifer,
Why would you need the same item added twice?  It's not clear to me that the same item needs to be on the diagram more than once.
Don't forget, the pictures that you see in the article you referenced are "pictures" not models.  If you want to model what's happening you shouldn't need to have the same item more than once on the diagram.
<caveat>Not familiar with VMWare SRM</caveat>

Can you explain more why you believe you might need it?

Paolo

[Richard Freggi]

If the recovery location is an exact replica of the other location, it is still a separate instance and must be represented by a separate element.  Sparx approach is correct.  UML provides objects and instances to describe this exact situation.

Two identical things are still two things, not one thing.

[Sunshine]

If you didn't want to duplicate the elements then one trick is to create a diagram of the primary location then create another diagram with two diagram frames (Drag and drop the first diagram from the project browser twice) giving the impression there are two instances (primary and recovery) of the same thing. You can then annotate that second diagram with arrows, labels etc. May be disable the frame around the diagram frame to tidy it up.

[Paolo F Cantoni]

If you didn't want to duplicate the elements then one trick is to create a diagram of the primary location then create another diagram with two diagram frames (Drag and drop the first diagram from the project browser twice) giving the impression there are two instances (primary and recovery) of the same thing. You can then annotate that second diagram with arrows, labels etc. Maybe disable the frame around the diagram frame to tidy it up.

In that case Jennifer should use Visio.

If she wants to create a model rather than a diagram, then she can't reuse the same instances since they aren't (as we've explained).  Why not just export the items and their diagram, and re-import using "strip GUID" as a way to create two sets of instances when can then be used correctly.

Paolo

[jennifer.cui]

Hi there,
Given that Sparx does not allow for the same item to be added to a diagram twice, what is the best practice for creating deployment diagrams with 2 physical sites/locations where the second location is an exact replica of the first using the VMware SRM technology?

http://www.vmwarearena.com/vmware-site-recovery-manager-srm-6-0-part-1-overview-and-achitecture/


Thanks in advance!

Hi Jennifer,
Why would you need the same item added twice?  It's not clear to me that the same item needs to be on the diagram more than once.
Don't forget, the pictures that you see in the article you referenced are "pictures" not models.  If you want to model what's happening you shouldn't need to have the same item more than once on the diagram.
<caveat>Not familiar with VMWare SRM</caveat>

Can you explain more why you believe you might need it?

Paolo

Ya absolutely, so if i have a virtual server called appserver1a modeled using Archimate Node at Location A. If a disaster occurs at my physical Location A, i'm able to bring up an identical server with the exact same server name at Location B using the VMWare SRM technology.

So with that being said, sure we can consider them to be "identical twins" however, they also have identical names. So i'm trying to figure out the best way to represent that using Sparx. And if creating two separate elements with all identical attributes other than the location association is the only way to do it, then that's fine too.

I'm sure others also face similar situations as me and i just wanted some expert advice on what the industry standard/best practices when trying to represent a recovery location using Sparx.
Thanks!

[qwerty]

Identical is not the same. It just has the same parameters. Actually one is a shadow of the other one. You are dealing with instances here. Use two instances of the same classifier.

q.

[Paolo F Cantoni]

Identical is not the same. It just has the same parameters. Actually one is a shadow of the other one. You are dealing with instances here. Use two instances of the same classifier.

q.

To echo q, "Identical twins" are NOT identical, they are SO named because they have the SAME specification (DNA)! 

We solve the problem by naming <Server> @ <Location 1> and <Server> @ <Location 2>  Or you can colour them differently to distinguish them.  EA has no problem with two instances having the same name.  But you have to easily (and unambiguously) work out which one is which.

HTH,
Paolo

[Uffe]

Hello Jennifer,


There is no single best way to represent, well, anything in UML. It's all down to what you want to emphasize in your documentation.

Ya absolutely, so if i have a virtual server called appserver1a modeled using Archimate Node at Location A. If a disaster occurs at my physical Location A, i'm able to bring up an identical server with the exact same server name at Location B using the VMWare SRM technology.

So with that being said, sure we can consider them to be "identical twins" however, they also have identical names. So i'm trying to figure out the best way to represent that using Sparx. And if creating two separate elements with all identical attributes other than the location association is the only way to do it, then that's fine too.

Identical names are not an issue in EA. Names are not identifiers; you can have any number of elements of the same type in the same package with the same names. The actual identity is a GUID.

But you have two different servers here. The fact that they are supposed to be configured identically does not mean that there is only one server. The fact that you are discussing them in terms of master and backup also indicates that this fact is something you wish to make clear in your documentation, in which case they definitely should not be represented by the same element.

When modelling computer hosts, I usually use symbolic names for the model elements and place the configured host names into tagged values or attributes. So in this case I might name the two nodes "master server" and "backup server".  Remember, the purpose of the documentation (the model) is not to mirror reality but to communicate information to people. In this case, the fact that one server is the backup for the other is important, so it makes sense to place that information in the element name. The actual host names are secondary.

Qwerty's suggestion of using instances is a simple solution, but only if your nodes don't themselves contain other classifier elements. If they do, there's nothing for it but to duplicate the structure manually.

HTH,


/Uffe

[jennifer.cui]

Thanks everyone! you have all been very helpful.