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 Salesforce.com? 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 Solaris–Oracle–J2EE 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 Salesforce.com and the Force.com 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 Salesforce.com 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?
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.
This is the big one. If your new app’s users are going to be “net new” licensed users of Salesforce.com 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 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 Force.com 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 Force.com 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 Force.com 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
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.