Deploying JMP in an enterprise environment?

[#1]

We use JMP as single install on user PCs. We have developed a JMP add-in that we would like to deploy to a larger group of users. Since the add-in would require each user to be individually setup for ODBC connectivity (for database queries), our IT dept would like an alternative option. 

IT were surprised that JMP don’t have an Enterprise Edition for large deployments and (being unfamiliar with JMP) are concerned around security, scalability, integration with Databases, etc. We have spoken to JMP and they say that we should just setup a server, install a single instance of JMP on same, and enable access to large groups that way.

Our IT Team are still not comfortable with this as they say this would require a terminal server farm, with a broker to manage/direct connections to a server, purchase MS RDS licenses for each user, and that they'd have to manage it all. Their view is that putting it on a server basis is really just trying to make an enterprise managed solution out of something that is not.

So my questions are:

Has anyone out there rolled out JMP to large business groups in a way other than single client install? 

If so, how does the business use it? How is it supported? Any watchouts you'd advise on?

Many thanks for your input.

[#2]

I suggest that you contact your JMP sales team to ask for help. They are trained to help with installations and have experience with all sizes of installations.

[#3]

Thanks Mark. Our IT team have already met with JMP sales & technical people who suggested to simply put a single install on a server, link it to the DB, and allow specified users to access it that way. However, IT are still not comfortable with the suggestion to put it on a server as it would require deployment of a terminal server with a broker in front of it to manage/direct connections, as well as the purchase of MS RDS licenses, etc. IT were hoping for a 'cleaner' option, as opposed to making an enterprise managed solution out of something that is not.

[#4]

I agree with @Mark_Bailey 's advice...when you say you '...spoke to JMP...' was it your sales team as Mark suggests? I'm a former member of one of those sales teams (now blissfully retired) and our team saw all manner of large multi site, international, enterprise wide deployments. Each one is a little different or might have some unique requirements. It's good you are involving your IT team early on. I won't go further than that since I don't want to step on a sales team's toes so to speak. Your JMP sales team, and the bench strength team of JMP technical support people behind them should be able to provide you insight wrt to the optimal deployment options and requirements. 

[#5]

Thanks P_Bartell. You refer to each of the deployments being slightly different, which is interesting to know, and also what I was reaching out to the Community for some insight on. I received one option from JMP, i.e. install it on a server, and when we asked if there were other customers that we could use for a reference call, we were told that this was confidential information that couldn't be shared. So, I'm reaching out to a few known JMP contacts and figured it'd be interesting to hear from further afield via the Community.

[#6 · Accepted solution]

We use Citrix to deploy multiple apps across the enterprise.  Depending on how many users you have you'll need a few Citrix servers.  JMP, Oracle, ODBC drivers and menus are configured once on each server.  The justification to IT was the support for individual PCs was untenable (=more expensive!).

[#7]

Many thanks for your response @pmroz. Deployment via this server route makes most sense to me.

[#8]

Prior to Citrix I was configuring JMP, Oracle, ODBC drivers, application menus, on individual PCs.  Every week someone's hard disk failed, or their PC was reimaged.  It was a maintenance nightmare.

Aside from the benefits of only needing to set up things once, the performance for our overseas users is excellent.  

Good luck!

[#9]

Many thanks all for your discussion points. I think for this add-in, we will go the ODBC route for a number of users initially as part of a UAT, then (assuming feedback is positive) deploy it on a server with one connection to a DB, with multiple user access via such single instance. While this approach always made most sense, all discussion points have been useful in understanding (and supporting same).Thanks all.

[#10]

On Windows it is possible to set up ODBC connections, install JMP, install add-ins, and set preferences all using SCCM.  This is a fair amount of work for IT though, especially if they aren't already using it for this type of thing.