Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: Model Trainer on June 09, 2023, 06:38:31 am
-
Hi,
We have an enterprise architecture modelling project. We are going to use Erwin for our data-side modelling, and sparx systems for the other layers. We are in the phase of deciding if it's better to use UML for all the layers , or we go with ArchiMate, and use UML where more details required. Based on the link found on the Erwin site, which I put here: https://bookshelf.erwin.com/bookshelf/public_html/Content/Installation/Implementation/Supported%20Metadata%20Integration%20Bridges.html?Highlight=bridge
It seems that these two tools will be compatible through UML. But I'm not sure, does it mean that we can't use other languages, or as some of them like ArchiMate is compatible with UML, it's ok to have them in our model???
what would be potential challenges in integrating Sparx and Erwin together?
-
We wanted to move our models from Erwin to SPARX EA and found the bridge to be fairly useless. Don't think it takes diagrams across along with other issues.
We used a 3rd party tool for the import into SPARX EA, it wasn't perfect but was good enough
-
Depending on the type of data modelling you are intending to do - i.e., conceptual, logical or physical - you have 4 options:
1) Only use Sparx EA
1 a) If you are only doing conceptual data modelling, use Archimate's Business Object (Business Layer) or Data Object (Application Layer)
1 b) If you are doing conceptual and logical data modelling, use Archimate as above and UML for logical data modelling
1 c) If you are doing the 3 types of data modelling but only need to reverse engineer and don't need to forward engineer, use Archimate, UML, as per 1 b), and Sparx EA very peculiar physical data modelling capabilities for physical data modelling.
2) Use ERWIN only if you have to reverse and forward engineer and need to apply strict relational database (modelling) theory.
-
In my experience, trying to integrate different tools can lead to lots of time and effort spent on getting the integration to work, that should have been spend on doing 'real work' instead. Quite often you will not get the full seamless integration that you hoped for.
I will suggest that you follow Modesto Vegas example and perhaps use naming conventions to link the models between the two tools.
Henrik