Best practice for small team 'Onedrive' or 'Dropbox' concurrent model usage.

[timoc]

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?

[qwerty]

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.

[Geert Bellekens]

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

[timoc]

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?

[Geert Bellekens]

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

[timoc]

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.

[Geert Bellekens]

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

[timoc]

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 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 for spinning up a container/VM, installing postgres, 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

[Geert Bellekens]

I see. I like the cattle/pet comparison.

Must admit that most of the servers I've worked on where pussies

Geert

[timoc]

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 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 for spinning up a container/VM, installing postgres, 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

[Mauricio Moya (Arquesoft)]

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

[qwerty]

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.

[Glassboy]

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.

[timoc]

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.

[Glassboy]

"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.