Showing results for 
Search instead for 
Did you mean: 

How to represent AS-IS and TO-BE in an application environment diagram ?

New Contributor

How to represent AS-IS and TO-BE in an application environment diagram ?


I'm using IT Architecture to represent our information system with application environment diagrams. But it represents the AS-IS situation.

How to represent the TO-BE situation, the new application, the decommissionned applications, the new messages without loosing the AS-IS ?


What is the best practise for that ?

I heard about variantes but I don't understand what it is ?


Thank for your help,

Frequent Contributor

Re: How to represent AS-IS and TO-BE in an application environment diagram ?



This would be a good use case for variants. They let you create a new "version" of an existing object, while maintaining traceability between the 2 versions. When you create a variant, the new object will inherit attribute values, and certain associations from the varied (baseline) object. If the baseline object has any describing diagrams (like an Application Environment Diagram), the variation mechanism will automatically create a copy of that diagram to describe the varied object. It can save a lot of time, especially if the new version only has incremental changes. Some things to keep in mind:

- there is an out-of-the-box report that you can run on the variant or varied object that will show the similarities and differences between the 2 objects. This can be a helpful analysis or communication/education tool

- the variation mechanism only looks at some of associations: you can adjust the perimeter or create a new perimeter to add/remove associations impacted in a variation

- the variant (new version) only inherits certain associations: if you change the name of an inherited component, it will change for the varied object and the variant. If an inherited component changes in the new version (ex: instead of using Windows Server 2008, the new version uses Server 2012), you need to add the new component to the new version, and then replace the inherited component you no longer need with the new one.

- there is some impact on queries: since variants only inherit associations, if you need to include variants in the results of your queries based on association, you will need to add the "inherited" statement to your query code. ex.: Select [application] Inherited where [used technology] =....


Variations are really useful, but they can also become very complex to manage...


I hope this helps a bit.