Importing Visio via MDG Add-in - how to improve import quality?

[lfgcasey]

Hi,

I've searched the forums pretty extensively for help for this problem with no success so far. Here's my issue:

Our company has an extensive library of Visio diagrams capturing our Enterprise Architecture (Deployment, Infrastructure, Application Systems, etc.), and we're trying to move from Visio to Enterprise Architect for all the obvious reasons. Our stated goal is to make Enterprise Architect the preferred tool for designing, capturing, and documenting IT solutions within our enterprise.

Unfortunately, I've tried the Visio MDG import of many of our current Visio diagrams with very limited success, and I suspect it's due to a Garbage In / Garbage Out situation. The diagrams are very much Visio drawings rather than true diagrams in that the elements are shapes and pictures with embedded descriptive text rather than formal diagram elements. For instance, deployment node elements are drawn as rectangle elements with descriptive text. What happens is that the subsequent imports can, at best, distinguish between

I have explained my hypothesis to my higher-ups, and while they do understand the situation, I've been encouraged to reach out to all the fine folks on this support forum to see what more can be done. Bluntly, the problem is that those people clutching on to Visio can and are using the import 'failures' (their word not mine) to downplay the usefulness of EA and stay with the status quo.

As I see it, we have a few options. First, the EA-literate of us can just re-create the Visio drawings and their embedded elements as proper models in EA, but that represents considerable effort. Moreover, that will just enable and reward bad behavior. Second, we can try post-processing the imported drawings via the EA automation tools but that presumes some method to the Visio madness like naming / shape conventions, and also just enables bad behavior.

The only way that I see to achieve our desired goals would be to show the Visio users how to improve their drawings so they give the EA import at least serviceable diagrams. Problem is that I have completely eschewed Visio and other tools in favor of EA for so long that I just have no idea where to tell them to begin.

So there's my conundrum. I welcome any and all ideas!

Best,
Casey

[Glassboy]

Visio is basically a desktop publishing application not a modelling application.  There is nothing close to syntactical checking in it.  Every diagram is an island.

When you import diagrams you end up

• altering the diagram to follow the actual syntax of the notation
• comparing all of the diagrams that touch the same areas trying to work out which one is the most accurate
• trying to work out how up to date they are
• visually reformatting everything to make it readable
• merging x copies of the same element and trying to work out which relationships need to mve too

It's much easier and takes less time to print them all out and put a line through the elements on them when you recreate it in your model.

[Nizam]

The only way that I see to achieve our desired goals would be to show the Visio users how to improve their drawings so they give the EA import at least serviceable diagrams. Problem is that I have completely eschewed Visio and other tools in favor of EA for so long that I just have no idea where to tell them to begin.

Visio is indispensable in many teams, period!. However Using some standard stencils (BPMN or UML, etc) has always imported better. However random Visio shapes and creative arts are very difficult to handle, unless the tool allows a diligent way to map the random shapes to something reasonable in EA. We have done bulk imports of processes for a few clients and for that We developed some custom Visio post-processing scripts to do the re-stereotyping / retyping of elements and connectors.

The Visio import does one thing well, which is to bring the shapes and layouts, so if you have some scripts that you can run by selecting multiple elements/ or selecting a diagram or selecting a package, it could help.

[Richard Freggi]

Hello Casey,
because of Visio, what you have is artwork, not artifacts.  No model consistency or metadata that you can really use.  You will have to clean up the artwork anyways before you can do anything useful with it, and the easiest/fastest/most accurate way to do it is right at import into EA.  My 2c is to bite the bullet and manually generate useful artifacts in EA using the artwork you have in Visio. 

[Geert Bellekens]

My 2c..

You'll be much better off re-creating the Visio diagrams in EA, making sure they follow the internal guidelines and metamodel.

I'd forget about the Visio import. I don't think it's going to speed up anything.

Geert

[VKN]

The only way that I see to achieve our desired goals would be to show the Visio users how to improve their drawings so they give the EA import at least serviceable diagrams. Problem is that I have completely eschewed Visio and other tools in favor of EA for so long that I just have no idea where to tell them to begin.

To start with, open a diagram in Visio then check for Template property at File | Info
As Nizam mentioned, if there is no relevant template specified like UML, BPMN Diagram, etc then EA wouldn't understand what type of elements are being imported.
If your Visio guys are able to port those diagrams to other new Visio diagrams containing the right templates and if the element types in the diagram does match with the elements in the template then importing those diagrams should work fine.

[Sunshine]

In the past I've found I've had to manually fix up visio diagrams before importing. As I only had a handful it wasn't worth automating. I probably spent just a little less time than manually re-creating in Sparx EA. So if you have a really large number of visio diagrams it might be worth running some automation script to fix the visio diagrams before importing.
Some thing the automation might do to improve import results into Sparx EA are
1. remove superfluous objects such as art work etc
2. ensure connectors are connected at both ends
3. change objects to UML template objects or consistent objects so they can be easily mapped to sparx EA

There are probably other common problems you might be able to fix via automation scripts. However I must stress this is only worth doing if the effort to do it is less than manually recreating the diagrams in Sparx EA. Other times I've found manually recreating diagrams in sparx EA gives you a chance to review those diagrams and find errors other than syntactical ones so there may be benefits to be gained doing that.

[lfgcasey]

Hi All,

Thanks for the responses! I can confirm that using Visio diagram elements from actual templates and stencils makes the import much more useful. Visio "User" elements come in as <<user>> stereotypes, Server nodes as <<node>> types, etc. so there is some promise. It's not perfect, but certainly better than having everything import as <<rectangle>>, <<circle>>, etc.

So now that the technical problem is somewhat taken care of, we'll need to start working on the social problem i.e. either use Visio to create meaningful diagrams, or use EA, and if you 'just want something quick' then use the Whiteboard/Hand-Drawn mode for those drawings.

Thanks again!
Casey

[Nizam]

it becomes 'predictably irrational' if we use the templates. we can then use the power of scripts to restereotype items that will get it much closer to expected output.

whilst ppl argue against Visio, as a EA consultant for years, we've lost the battle most times .

[Paolo F Cantoni]

Hi All,

Thanks for the responses! I can confirm that using Visio diagram elements from actual templates and stencils makes the import much more useful. Visio "User" elements come in as <<user>> stereotypes, Server nodes as <<node>> types, etc. so there is some promise. It's not perfect, but certainly better than having everything import as <<rectangle>>, <<circle>>, etc.

So now that the technical problem is somewhat taken care of, we'll need to start working on the social problem i.e. either use Visio to create meaningful diagrams, or use EA, and if you 'just want something quick' then use the Whiteboard/Hand-Drawn mode for those drawings.

Thanks again!
Casey

One approach to the social problem is to determine if the users are trying to create models or just pictures or drawings.  Often, we find they are just trying to draw pictures - i.e modelling is NOT their "day job" and the overhead gets in the way of getting the work package completed.  Consequently, Sparx appears to have TOO much friction.  If they are trying to draw pictures instead of creating models, you need to work on that.  Forget EA for a minute, just work on the implication of a model versus a picture (pixels) or even a drawing (as in Visio).
If they are really trying to create models, then you need to explain why a Visio diagram is NOT a model.  THEN, you need to work on reducing the friction to them creating models in Sparx.
That's why we emphasise creating a good user experience with EA.

As an example, our integration group used to create integration diagrams in Visio and for years we couldn't wean them off.  Then a new Integration Architect Lead came on board who understood the value to him and his team of true models.  We worked with him and the group to create a sub-MDG to handle the Integration Aspect - the kinds of objects one finds in the various Enterprise Service Bus technologies.  New elements and connectors.  Now they are enthusiastic users of EA (and our poster children on why you should switch to a modelling approach).

However, this is an example of one of my aphorisms: "If they're not buying, you can't sell".  (until the new Lead came on board, we couldn't mount a good enough argument)  You need to seize your moment carefully.

HTH,
Paolo

[Rich Anderson]

Learning how to model for the first time using EA is a bit like learning to drive by starting with an 18 wheel truck.  I usually recommend that people get the hang of modeling using the free Archi tool (www.archimatetool.com) and then come over to EA once the basic principles are understood. You can even export your models from Archi and import them into EA when you are ready.  Clearly that works best when using Archimate, but it has really helped me help people get over the mental barrier between diagramming and modeling.   

[lfgcasey]

Thanks everyone for the advice! I'm going to start hosting a series of in-house workshops focused on diagramming and modeling in EA. I have some HOWTO-like documents and some Process Guidance diagrams created for folks new to modeling in general, and EA in particular. Hopefully that will help curtail the F.U.D. - Fear, Uncertainty, and Doubt.

[Richard Freggi]

Learning how to model for the first time using EA is a bit like learning to drive by starting with an 18 wheel truck.  I usually recommend that people get the hang of modeling using the free Archi tool (www.archimatetool.com) and then come over to EA once the basic principles are understood. You can even export your models from Archi and import them into EA when you are ready.  Clearly that works best when using Archimate, but it has really helped me help people get over the mental barrier between diagramming and modeling.

My experience is that if the modeler understands the notation and methodology, using the tool is not a challenge.  Most of the screw-ups are because the modelers try to do something the notation was never designed to do.  My experience is that heavy investment in training for notation (UML, Archimate, BPMN... pick your poison) and in methodology (what an artifact is and how it should be used) pays back in spades.  Then Sparx, Papyrus, Rational... you can spend an afternoon giving modelers the tool overview and then let them look up details in documentation as needed (usually Google works wonders).

[Sunshine]

Learning how to model for the first time using EA is a bit like learning to drive by starting with an 18 wheel truck.  I usually recommend that people get the hang of modeling using the free Archi tool (www.archimatetool.com) and then come over to EA once the basic principles are understood. You can even export your models from Archi and import them into EA when you are ready.  Clearly that works best when using Archimate, but it has really helped me help people get over the mental barrier between diagramming and modeling.

I hear what you are saying but have to disagree with you as introducing another tools such as Archi only confuses them and is like teaching people to drive an automatic then giving them a manual transmission to drive. I found it best to teach them to drive a manual whilst teaching them the road code. Do it in small chunks one lesson at a time so its not overwhelming.

I usually take the approach teach them the modelling notation as I teach how to do various diagrams with various notations. Examples seem to be the best way to get them up the learning curve quickly. For enterprise architecture using archimate I start off with motivations then move through the various domains such as business, application, infrastructure etc. Each time introducing something new that Sparx EA can do.

The fundamental thing to do is to start with 'what in it for them' in using a tool like Sparx EA over visio. Usually its something like working a different way which is less effort and more effective. For instance moving from a document centric waterfall type method to an iterative model driven agile and collaborative approach. As everything is getting called digital this that and the other you could put digital in there somewhere. Something like Digital Iterative Model Driven Agile Collaborative Approach (DIMACA). Now they have some motivation to learn  something new and shiny with an acronym to make them sound smart but  we all know its just re-branded old stuff
 

[Glassboy]

I usually take the approach teach them the modelling notation as I teach how to do various diagrams with various notations. Examples seem to be the best way to get them up the learning curve quickly. For enterprise architecture using archimate I start off with motivations then move through the various domains such as business, application, infrastructure etc. Each time introducing something new that Sparx EA can do.

I get people to start modelling and tell them not to worry about being correct.  Then I read their model back to them and get them to confirm whether what I read is what they intended to convey.  ArchiMate especially should break down into a series of statements, and be able to be read like a story.  Story telling is a fundamentally human activity and we train children to do it in schools so I find that people pick up how to improve their modelling this way.