Application Cohabitation

Introduction / Problem Statement

Cutting right to the chase-How do you decided if a new application should co-exist with your current applications implemented in  I’m writing this in response to my own inquiry and hoping that as I annotate these thoughts/arguments I can illicit enough feedback from “the community” to either validate it or point me in the right direction.

Background-I was a key contributor of a start-up some years back where we decided to home-grow most of our enterprise applications on a SolarisOracleJ2EE stack.  The benefit of this was that we didn’t require multiple technical teams with varying skills to support the “best of bread” sales, service, employee management, ERP, CRM, XYZ applications.  We could hire(or teach) the skills we needed on the stack and the developers could support all of the applications we put on this bohemoth.

As I “moved on” from this Utopian software environment I realized that big enterprises don’t work that way.  The PeopleSoft HR application needs to feed Microsoft Active Directory and Siebel CRM and tie to the home-grown Sales Compensation System which ties to the blah, blah, blah system.  Meanwhile you’ve got n number of systems that all need to be aware of your users, groups, customers, products, permissions, and so on.  That’s a lot of redudancy.

Enter and the platform.  Now you can have your CRM app co-exist with your time management app and your sales compensation app and your whatever app all in one “org”.  But with great power (I won’t say it)…   With each new app it’s really important to ask if it (the new app) should cohabitate with your existing org.  Here’s my criteria.

My Criteria (and maybe yours)

Here’s an ever-popular bullet point list that will help guide you through the decisions on whether to put that new app in your existing org or to ‘spin of a new org’.

  • Are the users of the new app existing licensed users?
  • Is there overlap in the new app’s data with the existing orgs data?
  • Does the new app “naturally fit” with the existing app?
  • Will you and your team be successful with this application?
  • Are the general features of the new app consistent with your existing app?

The Breakdown

OK, so I’ve thrown down my list of criteria in a simplified single line statement, now it’s time to back each one up.

The Users

This is the big one.  If your new app’s users are going to be “net new” licensed users of then you’ve got yourself a case for a brand new org.  Whether you’re paying X dollars per month for 50 users in one org and 25 users in another org it still comes out to X dollars times 75 per month (see Editions and Pricing).  But there has to be some middle-ground here.  If out of your 75 total users, more than 33% (you need to decide the threshold) will need to use both apps, then you’re probably better off having both apps in one org.  Users bouncing out of one org and into another is a pain, and they’ll share that pain with you.  So consider this “high” as a factor in deciding.

Data Overlap

Data overlap is always going to happen, whether it’s in your picklist values or your default contact information, or whatever.  I’ll bet that my DE org has some data in common with your production org right now.  But I’m talking about serious data overlap.  Like the entire(or most of) your Account records or all (or most) of your Campaigns.  Second only to user overlap this needs to be high on your list when considering multiple orgs.

Brief “me/us” story.  When my development team decided to create our change management app on the platform we considered whether our sprint, backlog item, and requirements custom objects would ever be shared with our sales and service agents data needs.  The obvious “no” led us to create this app in a separate org.  Since then we have realized that release notes would have been a hell-of-a-lot easier had we co-habitated, but that doesn’t out-weigh the fact that we can do whatever we want, whenever we want to our own org without an CR and 3 weeks of “it won’t break any of your stuff, I promise” meetings.

Application Natural Fit

This is one you’re going to have to spend some time thinking about.  Say your call center is using the “Service Cloud 2.0” application and you’re considering a Customer Feedback application.  Natural Fit = true.  A customer feedback button or tab fits because your users are dealing with your customer and to send them out to another application would be absurd.  On the contrary if you’re sales agents are using the “Sales Cloud 2.0” (or 3.0 or ? by now)  and your I.T. department wants to implement an ITIL based service application (like RemedyForce no I don’t work for BMC), then I’d say that’s a rather un-natural fit and the I.T. guys should get their own damn org.

New App needs versus Existing App Policies (reworded from bullet points)

Enterprises and companies are made up of groups of people, and sometimes (as I tell my kids) these people don’t see eye to eye.  So this section of the blog is dedicated to the politics of the decision.  [Switching to really frank mode] Listen closely.  If you’ve got a group inside your organization that is difficult to work with, then implementing their application on the platform will be just as disastrous as the last effort was when they launched their application on Java & Struts.  So let the .Net guys take on this one.  After all you’re competing with those guys for the CIO’s attention and when the thing go awry you can stand proudly and lie “This would have been successful if we had done it in Salesforce!”

General Feature Comparrison

If you’re still reading I’ll make this one fairly simple.  Think like a consultant who’s getting on the plane at 5pm and needs to leave at 3 even though he only got into the office at 10am and had an hour and a half lunch.  Consider whether the new application will required cool new post-2008 Salesforce features like Visualforce, Sites, Batch Apex, and JavaScript Remoting.  Can this new app be done using standard layouts and standard reports?  Is this an assignment for Asok when he returns from ADM-201?  If so then maybe you don’t need to order 16 new Salesforce Unlimited licenses at $250 per user per month.  Perhaps this can be done in a new org with 16 Professional Edition licenses at $65 per user per month.


As anticipated, I’ve educated myself during this blogging exercise and I think that each of my bullet point items which list the pros and cons of application cohabitation become progressively less pertinent.  Meaning?  I should score each of them to make it useful, so I will.

  • User Overlap – 50%
  • Data Overlap – 30%
  • Natural Fit – 10%
  • Politics – 6%
  • General Features Required – 4%

Hopefully this helps others in the community.  I know it will help me tomorrow during my technical recommendation when I quote this blog in the 3rd person to prove my point.



About mdnorton

I'm a software developer by day, martial artist by night. I dig writing code, getting some exercise, then kicking back with my home brewed beer. Nunchuck skills, yeah, I got 'em. @NortonMD
This entry was posted in Uncategorized. Bookmark the permalink.

2 Responses to Application Cohabitation

  1. Wes says:

    Great article this is becoming more of a common topic and time goes on. Other areas that I’ve used when making this decision are:

    – Future projects and their impact
    – Complexity involved in consolidating Orgs vs splitting an Org

    Thanks again, hope to see more of this kind of stuff soon!

  2. mdnorton says:

    Thanks, Wes. I appreciate your feedback. You’ve got a great point on the future considerations. If the applications have a chance of consolidating in the future its quite painful to migrate data between orgs.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s