Distributed team deployment and EA LITE Best confi

[RobinB]

Hi All, I guess I am going to be a regular here from now on

I would like view points on best way to utilise EA Lite, I want to set up the distributed team configuration
so
each user has a local copy of checked out packages relevant to there workload, would EA Lite need to export the data and hold a local copy as well? is that even possible?

second option I suppose would be to set up a server/machine to act as a shared model repository that ealite users can access

anyone know of any better options

[qwerty]

If possible and WAN speed is ok, then go for the central repository for sure.

q.

[Glassboy]

Have you read this white paper www.sparxsystems.com/downloads/whitepapers/EA_Deployment.pdf ?

[RobinB]

thanks qwerty, that is my feeling, the users will be located remotely(customers) and the engineers will be working on a thick client on laptops. so an additional server that holds an instance of the latest baseline looks like the best way forward

Hi Glassboy, yes I have, but there is no mention of EA Lite in it.

what I am looking for is the easiest way for the customer to view the information, I don't know if EA LITE can 'get latest' from the source control repository, but even if it can, I am not sure that is the easiest method for the customer to use.

any thoughts appreciated

Thanks

[Geert Bellekens]

Hi Robin,

Welcome to the forum.

I'm pretty sure you can't use EA Lite to do a getlatest, but that might not even be the best way forward.

If I were you I would use some kind of "controlled" releases of the model, where you decide what goes into the model and what not.
You can distribute these released models as .eap files for your EA Lite users.

If you need the lite users to always have a view on the current model I would definitely use a DBMS repository.
Most major DBMS's have some kind of replication feature to maintain a remote "live" copy of the database in another location.
That would be feasable since your EA Lite users don't need write access anyway.

Geert

[Uffe]

Hi Robin,


I tend to recommend against using EA Lite at all, since it's very limited in its abilities. I'm pretty sure it can't access version-controlled models, nor can it do baselines. I also believe it won't run Add-Ins, which might be a factor in your case.

Another option for your deployment scenario is to use EA's cloud facilities. This does not mean you store your models on a Sparx server, but that you upload them to, and retrieve them from, a server of your own. Again, I don't know whether EA Lite can do this but I think not.

One reason not to use EA's integrated version control is that EA's set of permissions does not differentiate checking in from checking out. In other words, if you have permission to check packages out of the version control system, you also have permission to check them back in -- not what you want if you have any concerns about data integrity and the EA skills of your customers.

With the cloud storage model, you can specify read and write access separately.

Version control, which I wouldn't recommend for your scenario, requires the Desktop edition (the cheapest). Baselines and cloud connections require the Corporate edition (two steps up).

If you want to squeeze every cent, you can set it up so that only one user requires the Corporate license by making it their job to retrieve the models into a shared repository, to which the other users connect with their cheaper licenses. But you should also take into consideration the costs involved with managing different types of license and/or different types of client (if you do use EA Lite).

I'd say a DBMS repository for the development team, and for the customer either a replicated repository as Geert suggested or a cloud server. I wouldn't bother with version control at all, but use baselines instead.


/Uffe

[RobinB]

Thanks GEERT and Uffe

the scenario - disprate working teams, we will be purchasing approx 20 corporate floating, areas of development are segregated, and checked out to stop two projects working on the same elements at the same time as this would be a contractual issue, I am after LITE to allow the customer to view the current baseline... they will do no development which from my perspective is a good way for them to gain access to 'there' information.

due to the configuration constraints, cloud is not an option at this time.

but baselines are a requirment.

thanks for comments

[Glassboy]

Robin have you thought about just rendering your customers a standard document or HTML report of the baseline?

If you create your package structure right the HTML report is a navigable web site based on the project.  It can be dumped into a folder on a web server or added to a SharePoint document library.

[RobinB]

Thanks Glassboy

I admit that I not seen the output of the HTML reporting capability of Sparx EA, but from a lengthy duration of working in IBM System Architect, I am not inclined to use the HTML output, especially within a sharepoint environment, however that said I will look into the possibility.

Robin

[Uffe]

Hi again,


An HTML dump is definitely worth looking at, if the intended recipient only needs to look at models, not update them.

The HTML version of a model is easier for an EA novice to navigate, but it obviously can't be used for things like document generation or other stuff you need the EA client for.

The default HTML template is OK, but of course it dumps everything. You can tweak it and remove some of the stuff you're not using. Note that what comes out is all JavaScript, so that needs to be enabled in the browser. It does not need a web server, it's a self-contained file package. How nicely it plays with SharePoint I couldn't say.

the scenario - disprate working teams, we will be purchasing approx 20 corporate floating, areas of development are segregated, and checked out to stop two projects working on the same elements at the same time as this would be a contractual issue, I am after LITE to allow the customer to view the current baseline...

In a DBMS setup (with security enabled) you lock the packages you're working on, so they are protected from concurrent editing. However, if a diagram in team A's model contains an element from team B's model, and team B changes that element, the changes will be reflected in team A's diagram. This is true if you use file-based repositories and version control too, but in that scenario team A decides when to "get latest" version of team B's model.


/Uffe

[RobinB]

thanks Uffe

I am only looking at a DBMS for EALITE to Access, the HTML may be suitable for what I am after, my experience with modelling tools and HTML outputs may be a little tarnished, so am going to re-review, the 'modellers' will lock out items that they are working on from the version control repository.

Cheers

Robin

[Glassboy]

In my last gig we found that publishing HTML reports was far easier and more useful than EALite.

Here's a handy example online http://motivationmodel.com/ebmm/

[bockfu]

I've found those not familiar with EA are happy to have a web site to view the model.

Be aware links from the project browser will change from export to export, there is no search and nearly all elements are clickable. So having descriptions for all elements and a very clear landing page with links to key parts of the model will be helpful.

Btw, does anyone have a way to automate the html report in a silent/unattended fashion suitable for a continuous integration type activity?

[qwerty]

Btw, does anyone have a way to automate the html report in a silent/unattended fashion suitable for a continuous integration type activity?

I remember having read a couple of threads about this. Good luck with the forum seach

q.