As you can probably tell from my posts to this blog, I’m still learning about I’ve dabbled in the trenches (Apex property syntax), poked around in user interface (PDFs and Visualforce), and dabbled with integration (Outbound messages and Ruby). Well, something I haven’t looked at is deployment.

Deployment in Enterprise Java Land

Call me old fashioned, but deployment on is a little foreign to me. I’m used to creating an EAR or a WAR in Enterprise Java land and handing that off to someone who drops it in a special directory. You then hope that all dependencies are resolved, that all necessary libraries are installed, that no weird class shadowing occurs, that your queues are set up correctly and that your beans all deploy. Naturally, this has to happen every time the EAR is deployed.

Deployment in the Cloud (SaaS-style)

Here in world it’s all about packaging (managed or not), and listing those packages on AppExchange so that others can click and install. I’ve just recently reorganized a little of the wiki around packaging, and I believe I’ve learned that:

  • I can take my code and “package” all the relevant bits
  • This package can be managed or unmanaged. If it’s unmanaged, the developer and installer can grab and edit the package at will. Once the installer has it, he has it. You, the developer, are no longer involved. Cool for distribution. I guess it feels like a 1 to many model. Every person who installs it “gets his own copy.”
  • Managed packages are a different beast, and this is where SaaS comes into play. Here, certain components are locked down (no destructive edits allowed by installer). More importantly, they support upgrading. I’m tempted to call this a many to 1 model. Multi-tenancy plays a role too.

This upgrading is marvelous. I guess it’s a bit like using any other app (such as Salesforce) — Every few months you get a seamless upgrade option. It looks like managed packages give me something similar. A customer can install my package, and at some stage I can upgrade that package and they’ll get an option to upgrade to that new code base. I can’t do this in enterprise Java land 🙂

This reminds me of something I heard at Tour de Force recently: Patch Once. SaaS as a driver for lowering software maintenance costs?

License Management App 2.0

So what started me thinking about all of this was an email that caught my eye on the release of “License Management App (LMA) 2.0”. From its blurb on AppExchange: “The LMA facilitates tracking of installation and upgrades of the managed packages created by your organization. Using LMA 2.0, you can apply licensing on managed packages built and owned by you so that you can control how many users in a customer org can access your package and for how long. You can also offer your Managed Package for trial on AppExchange.”

So it seems that not only can I package my code, deploy it to customers, and offer upgrades to that code, but I can also manage individually those customers that have my code deployed, controlling how many of their users have access to the app, let them use the app on a trial basis and “apply licensing.” You can also “manage leads” – and again this is a SaaS thing foreign to a developer type (at least, foreign to me).

The idea is that if someone installs your app (say on a trial basis, or licensed for 1 user), you (the developer/customer) actually get a lead to that installer, so you can (I imagine) approach them and find out what additional features would make them buy it (or buy more of it). So SaaS really appears to bring the customer closer. They’re using a version of your managed code at the end of the day.

Well, I’ve exhausted what little I know. I haven’t yet created a managed package, nor have I installed LMA 2.0, but I’ll let you know when I do.


Here are some resources where you can learn more:

Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

Add to Slack Subscribe to RSS