Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: timoc on June 26, 2019, 08:38:36 pm
-
So there is a team use best practice for sharing a model on a multi-user filesystem that essentially says 'we use a database - turn on user access, and go for it'. This is usually talking about some IT managed volume, but more and more i am having to work on shared models on Onedrive filesystems.
Does/Is anyone using onedrive, dropbox for shared modelling work? If so is there a best practice?
-
Using EA models? No way. Setting up shared team work is a hell of work in any case. There's so much to say on that, it can fill more than a book. And each company has different use cases. It's a modeling task on its own.
q.
-
You can use a shared network drive with .eap(x) files, but I don't think this works for DropBox/OneDrive/GoogleDrive
I think systems like that work locally on such a file, and then upload their version to the shared drive, effectively erasing other users changes. But I've never tried it.
Anyhow, if you want to do anything professionally with EA you should setup a database.
A possible alternative can be to use a version control system (svn, TFS, CSV) as you central repository. In this case you can afford to use .eap file as they are only used locally on the user's computer.
Geert
-
I'm currently looking at the options for ad-hoc team modeling and share-point. I was hoping to avoid the overhead of a Central DB.
What about the Reusable Asset Service? I have not been able to do much with it yet. Is that a viable alternative to a Central Database?
-
I'm currently looking at the options for ad-hoc team modeling and share-point. I was hoping to avoid the overhead of a Central DB.
What about the Reusable Asset Service? I have not been able to do much with it yet. Is that a viable alternative to a Central Database?
No, Reusable Asset Service is a pretty limited method to share/distribute parts of a model with other models. Not really used to collaborate on the same model.
In fact the only real option is to use a database. If you don't want to setup one yourself you might want to look for companies that offer hosted cloud solutions.
I'm not sure if anyone is offering that right now, but it is technically possible.
Geert
-
I'm currently looking at the options for ad-hoc team modeling and share-point. I was hoping to avoid the overhead of a Central DB.
What about the Reusable Asset Service? I have not been able to do much with it yet. Is that a viable alternative to a Central Database?
No, Reusable Asset Service is a pretty limited method to share/distribute parts of a model with other models. Not really used to collaborate on the same model.
What is the use case for it then? model publishing?
In fact the only real option is to use a database. If you don't want to setup one yourself you might want to look for companies that offer hosted cloud solutions.
I'm not sure if anyone is offering that right now, but it is technically possible.
Geert
I need to make an ansible script for it, or its not (re)usable infrastructure. I need to document the workflow and EA usage. As qwerty said this is already a big task, especially when there are no out 'of the box' reference workflows or documentation to base it on.
I can do it, i have some level of automation already for an EA PostgreSQL server, but don't have the time to spend on it at the moment.
-
What is the use case for it then? model publishing?
Some kind of yes. Suppose each project has it's own EA Repository (e.g. an eap file). In that case you can publish the common architecture models in the RAS.
The individual project can then "download" this common part from the RAS.
Technically is it just a store of xmi files.
I need to make an ansible script for it, or its not (re)usable infrastructure. I need to document the workflow and EA usage. As qwerty said this is already a big task, especially when there are no out 'of the box' reference workflows or documentation to base it on.
I can do it, i have some level of automation already for an EA PostgreSQL server, but don't have the time to spend on it at the moment.
Not sure what you need the scripting or automation for. Care to explain?
Geert
-
What is the use case for it then? model publishing?
Some kind of yes. Suppose each project has it's own EA Repository (e.g. an eap file). In that case you can publish the common architecture models in the RAS.
The individual project can then "download" this common part from the RAS.
Technically is it just a store of xmi files.
I need to make an ansible script for it, or its not (re)usable infrastructure. I need to document the workflow and EA usage. As qwerty said this is already a big task, especially when there are no out 'of the box' reference workflows or documentation to base it on.
I can do it, i have some level of automation already for an EA PostgreSQL server, but don't have the time to spend on it at the moment.
Not sure what you need the scripting or automation for. Care to explain?
Geert
Automation is a minimum requirement for our Architect (ok, me) when it comes to any new server based infrastructure or tooling.
Ironically this is connected to the Database rant in another thread. Have you heard of the Cows not Kittens (https://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/) argument for why dev-ops? This argument is especially true for setting up something that feels as dicey yet as critical as an EA database server.
In this case ansible (https://docs.ansible.com/) for spinning up a container/VM, installing postgres (http://ansible/latest/modules/postgresql_db_module.html), setting up the security model, installing the EA datamodel, and/or restoring from a backup. Bonus automation may be running SQL model update/integrity checks, setting up a RAS server. installing some kind of model publish automation. etc.
When you automate the process of server creation, especially for a database server, you change the risk model and speed up its evolution. A mojor portion of the overhead, cost and risks of making changes to your datamodel , database server version, security model, catastrophic recovery etc. evaporate. You can spin up in minutes multiple versions with live data in different test configurations. For database development, you add schema changes to your automation, and you can run schema changes in parallel virtual infrastructure for different development teams until you are happy, shoot that cow, get another with the latest model and apply the changes..... was going to slip into how this would be a game changer for Sparx, but am saving that for the a new thread on state of the EA database i have in mind :)
-
I see. I like the cattle/pet comparison.
Must admit that most of the servers I've worked on where pussies ;D
Geert
-
What is the use case for it then? model publishing?
Some kind of yes. Suppose each project has it's own EA Repository (e.g. an eap file). In that case you can publish the common architecture models in the RAS.
The individual project can then "download" this common part from the RAS.
Technically is it just a store of xmi files.
I need to make an ansible script for it, or its not (re)usable infrastructure. I need to document the workflow and EA usage. As qwerty said this is already a big task, especially when there are no out 'of the box' reference workflows or documentation to base it on.
I can do it, i have some level of automation already for an EA PostgreSQL server, but don't have the time to spend on it at the moment.
Not sure what you need the scripting or automation for. Care to explain?
Geert
Automation is a minimum requirement for our Architect (ok, me) when it comes to any new server based infrastructure or tooling.
Ironically this is connected to the Database rant in another thread. Have you heard of the Cows not Kittens (https://www.theregister.co.uk/2013/03/18/servers_pets_or_cattle_cern/) argument for why dev-ops? This argument is especially true for setting up something that feels as dicey yet as critical as an EA database server.
In this case ansible (https://docs.ansible.com/) for spinning up a container/VM, installing postgres (http://ansible/latest/modules/postgresql_db_module.html), setting up the security model, installing the EA datamodel, and/or restoring from a backup. Bonus automation may be running SQL model update/integrity checks, setting up a RAS server. installing some kind of model publish automation. etc.
When you automate the process of server creation, especially for a database server, you change the risk model and speed up its evolution. A major portion of the overhead, cost and risks of making changes to your datamodel , database server version, security model, catastrophic recovery etc. evaporate. You can spin up in minutes multiple versions with live data in different test configurations. For database development, you add schema changes to your automation, and you can run schema changes in parallel virtual infrastructure for different development teams until you are happy, shoot that cow, get another with the latest model and apply the changes..... was going to slip into how this would be a game changer for Sparx, but am saving that for the a new thread on state of the EA database i have in mind :)
-
I remember years ago in the official documentation, it says that an EAP have to be shared via filesystems and NOT via sharepoint or any other sharing/synchronization tool (as dropbox, drive, etc). So, don't reinvent the wheel: share your model in a database and that's it
-
I were even suspicious if one sets up two "real" databases and have replication turned on right there. One central DB is the thing. Or you need to look into (version) controlled packages. Which has another set of drawbacks.
q.
-
When you automate the process of server creation, especially for a database server, you change the risk model and speed up its evolution. A mojor portion of the overhead, cost and risks of making changes to your datamodel , database server version, security model, catastrophic recovery etc. evaporate. You can spin up in minutes multiple versions with live data in different test configurations. For database development, you add schema changes to your automation, and you can run schema changes in parallel virtual infrastructure for different development teams until you are happy, shoot that cow, get another with the latest model and apply the changes..... was going to slip into how this would be a game changer for Sparx, but am saving that for the a new thread on state of the EA database i have in mind :)
Which shows that your cattle / pet model is flawed. What you're building is a house cow, not data managed at industrial scales.
-
When you automate the process of server creation, especially for a database server, you change the risk model and speed up its evolution. A mojor portion of the overhead, cost and risks of making changes to your datamodel , database server version, security model, catastrophic recovery etc. evaporate. You can spin up in minutes multiple versions with live data in different test configurations. For database development, you add schema changes to your automation, and you can run schema changes in parallel virtual infrastructure for different development teams until you are happy, shoot that cow, get another with the latest model and apply the changes..... was going to slip into how this would be a game changer for Sparx, but am saving that for the a new thread on state of the EA database i have in mind :)
Which shows that your cattle / pet model is flawed. What you're building is a house cow, not data managed at industrial scales.
"The sure sign of that you have a kitten-class application or server? Everyone gets upset when a kitten dies."
Even if i only ever want one EA database server, infrastructure as code (the automation) is a net benefit. If the EA Kobe beef dies, i can get another.
Maintenance is easier. Extensibility, e.g. adding RAS or other automation is easier. Handing responsibility over to someone else, also easier. The cow/kitten argument for infrastructure as code works at any scale. I would argue this is especially true for database schema development and migration, in combination with vagrant or docker.
-
"The sure sign of that you have a kitten-class application or server? Everyone gets upset when a kitten dies."
Even if i only ever want one EA database server, infrastructure as code (the automation) is a net benefit. If the EA Kobe beef dies, i can get another.
Maintenance is easier. Extensibility, e.g. adding RAS or other automation is easier. Handing responsibility over to someone else, also easier. The cow/kitten argument for infrastructure as code works at any scale. I would argue this is especially true for database schema development and migration, in combination with vagrant or docker.
No one disagrees with the benefits of infrastructure as code, but dressing a kitten in cow hide, doesn't turn it into a cow. Real infrastructure as code benefits from properly using underlying data and storage technology.
-
Actually, I'm doing this now and it works really well, as long as your team is relatively small (2 or 3 people). What you do is put a shared replica on a Onedrive/Dropbox that is synched to everyone's PC and then everyone synchs to that replica inside of EA. When you do the synch from with EA, then OneDrive/Dropbox will automatically put that file on everyone's PC. Then, when they synch to their local replica, they get the changes. If you are reasonably careful that others are not all editing the same elements in the model, then it works. (You just need to monitor the replication conflicts) I've probably done this 3 or 4 times, quite successfully, and found it much easier than setting up central server database. In my case, the other members of the team are on different continents and work for different companies, so the alternative is setting up a database on AWS using Cloud services, which I have done as well. The problem with that is performance. When everyone works on a local replica, the performance is much better. This is a very effective way to exchange model data for SMALL teams and takes about 10 minutes to set up.
-
Do you mean you use the Master/Replica system for this?
Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)
Geert
-
Do you mean you use the Master/Replica system for this?
Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)
Geert
Would baselines work to mitigate this?
-
"The sure sign of that you have a kitten-class application or server? Everyone gets upset when a kitten dies."
Even if i only ever want one EA database server, infrastructure as code (the automation) is a net benefit. If the EA Kobe beef dies, i can get another.
Maintenance is easier. Extensibility, e.g. adding RAS or other automation is easier. Handing responsibility over to someone else, also easier. The cow/kitten argument for infrastructure as code works at any scale. I would argue this is especially true for database schema development and migration, in combination with vagrant or docker.
No one disagrees with the benefits of infrastructure as code, but dressing a kitten in cow hide, doesn't turn it into a cow. Real infrastructure as code benefits from properly using underlying data and storage technology.
Is your assertion then that if i don't have more than one cow, it is by default a kitten?
-
Do you mean you use the Master/Replica system for this?
Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)
Geert
Would baselines work to mitigate this?
Replica/Master can corrupt your access files to the point that they are not usable anymore.
Since baselines are internal you won't be able to access them anymore in a corrupt file.
If you externalize these baselines (basically they are just xmi files that are stored in the database) that could be a way to restore broken stuff.
But if you are going that direction anyway, I would rather suggest to use an external version control system (TFS, SVN mainly) to share models across different models.
Geert
-
Do you mean you use the Master/Replica system for this?
Be careful with that however and make sure you have backups.
I've seen a few users with corrupted Master/Replicate models here on the forum. Once it's broken it really is completely broken and you can only go back to your backup (if that exists)
Geert
Would baselines work to mitigate this?
Replica/Master can corrupt your access files to the point that they are not usable anymore.
Since baselines are internal you won't be able to access them anymore in a corrupt file.
If you externalize these baselines (basically they are just xmi files that are stored in the database) that could be a way to restore broken stuff.
But if you are going that direction anyway, I would rather suggest to use an external version control system (TFS, SVN mainly) to share models across different models.
Geert
Some onedrive/dropbox options have version control of a sort, that i have found handy. The ability to revert a model file back to a previous save. The same would be true with an exported XMI.
-
Yes, but that is not the same as connecting EA up to an external version control system.
In that case it works with exclusive locks, allowing only one person at a time to edit a package.
This system prevents accidentally overwriting someone else's changes.
It is sometimes used as a way to collaborate on the same model from different locations without the need to setup a central database, terminal solution, or cloud server.
All you need is a publicly accessible TFS or SVN
If you want to work without a database, but still want to have some robustness in the data, you can use this type of setup. Downside is that you have to check-in before your co-workers can see your changes.
Geert
-
Yes, it is always prudent to have backups, and I do that. I use a free program called Cobian Backup to make these more automatic. The other thing about Access replication is that while it can fail, it's also pretty well established and tested. It's pretty mature. I once had to run a replication across 50 instances with Access back in 2002 (nearly 17 years ago) and it (amazingly) worked much better than I expected.
I just repeat that this can work very well for SMALL teams as long as it's properly managed. If you have no easy way to set up a shared database and your team is small, this is WAY better than manually copying and pasting data between models.