* The Business of Software

A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

We're closed, folks!


» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)


Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Enterprise mISV: Deployment Environments and Support

Hi Guys

I'm getting close to finish my application. It basically does what it needs to do, very basic. It's purely back end, no GUI. Takes a bunch of data and does calculations and spits a bit less data out.

Aside from the data transformation and interfaces, will enterprise customers expect the code to be packaged to work 100% with their environment out of the box?

It's in Java, so it's write once debug everywhere!

I'm not sure how much environment work they will expect. Or if I give them a package and say 'welp it ran on environment config #1023X' and then work with them to deploy it.

hcw Send private email
Tuesday, October 22, 2013
Sorry forgot to add that we dont have a web front end but we will have a web service.

I guess what I am trying to say is the application is quite simple, has minimal touchpoints and from my point of view the customer will have a lot more business impact to deal with than technical.

Just wondering what the seperation of duties are
hcw Send private email
Tuesday, October 22, 2013
Off the top of my head -- make sure you specify which JVM versions you support (6, 7)?  Whether your application will work with OpenJDK (the default on many linux distros) or require the OracleJDK. 

If this is a webservice, which containers (and versions) have you tested it in (Jetty, Tomcat, JBoss, etc)?

What dependencies does it have?  Does it use a database, which ones are supported?  Does it require certain ports to be open?  I'd definitely provide some sort of installation and setup guide, even if it's not specifically requested.
James A. Send private email
Tuesday, October 22, 2013
Besides the above, I'd start thinking about how you're going to market it. I personally would be more likely to look into something like that if there was a live demo running somewhere that I could test against before making a purchasing decision.

Remember the barrier is quite high... just provisioning a server is quite hard in some organisations. You need to make sure you can demonstrate the value first.
Jonathan Matthews Send private email
Tuesday, October 22, 2013
Thanks guys.

@James: We're still developing it locally using Jetty, and using JVM 6. I'm not too clear on how to test the other configurations, is there a kit or automation which can test the portability of the code? It's on my to do list.

As the application is quite simple, and will not be handing a large amount of web users etc I think we're in a position to make something which is simple to deploy. But you know what they say about assumptions..!

I have not develop the database yet, as we're still using memory due to our small data set. Not ideal, but hoping to move to a database imminently. I'll look into what is the most vanilla, generic database I can build with. So we dont get stuck using some unique functionality of teradata 13 and get a rude shock when the customer wont provision it.

@Jonathan: Thanks and noted. The sales pitch itself is quite mature, and we have some introductions into a few potential clients. That side of it concerns me less, as it's easier to talk yourself out of a hole ;) Missing functionality cant be fixed with a silver tongue!
hcw Send private email
Tuesday, October 22, 2013
@hcw: I work in a small Enterprise and we use each day Java-based tools such as Rundeck, Artifactory, Jenkins. We also used to have in-house Jira and Confluence instances, we moved to hosted Atlassian tools when the maintenance burden became too high.

What I like in a Java tool:

- deployable as a WAR file in a commonly used, free container such as Tomcat (my preference) or Jetty
- the tool configuration should be external to the WAR file: you can require a particular system property indicating a properties or xml file where your application will read the configuration
- the tool should also let me change the logging configuration, so it should be able to read from a log4j.properties/logback.xml/whatever external file
- it should be database-agnostic as much as possible: there's no way I'm deploying a tool which requires MySQL

I would also try to define very well what are the configurations you support (JDK version, container version, OS version if applicable, database, etc.).

Definitely charge for support and offer 2/3 levels of support contract, differentiating on the medium (email, ticketing system, telephone) and on the reactivity.

This is off the top of my mind, if you have further questions just ask.
Sebastiano Pilla Send private email
Wednesday, October 23, 2013

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz