Choosing a systems integration partner

Given the positive feedback I've had on the idea to bring an implementation/systems integrator focus to OSBC Boston 2006, I figured I could start the conversation here by discussing some of my findings about choosing a strong SI partner.



In my experience, different SIs bring different strengths, and it's not clear that one is necessarily better than the other. Some of the different types I've worked with at Novell and Alfresco:

1. Open Source Savvy. Systems integrators with a strong open source background can be a huge benefit in pitching reluctant customers. You don't waste time trying to bring them up to speed on the "Why open source?" question, and they generally have solid customer references to help newbies "cross the chasm." The downside to open source SIs is that they don't always have good depth in a given market (CRM, ERP, ECM, etc.). Worse, because their backgrounds tend to be with "in the wild" open source projects, they sometimes have a hard time pitching commercial open source alternatives.
   
   It's therefore imperative that you work out a clear sales strategy/competitive differentiation with your open source SIs. In Alfresco's case, for example, one of our partners - Cignex - has traditionally been a Plone shop. They found that a number of customers wanted a Java-based ECM offering (Alfresco is J2EE-based), however, and have established clear guidelines for when they pitch Alfresco versus Plone, making us comfortable that they're not undercutting us or underselling us.
   
   
2. Proprietary Solution Savvy. These are SIs who have a long track record in implementing SAP, Documentum, Siebel CRM, etc. These partners are great because they tend to have excellent customer references and have felt their clients' pain acutely, which usually stems from implementing overly expensive, inflexible, and featured products. They tend to see open source offerings as a low-cost alternative to their more costly, proprietary partner offerings.
   
   The downside with these partners is that they tend to lack a sophisticated understanding of open source and therefore don't always pitch this value accurately or emphatically. You need to work with these partners to help them see open source as more about flexibility, choice, and innovation than it is about cost.

I haven't found either type of SI partner to necessarily be generally better than the other. Each has its strengths and weaknesses and should be brought into deals accordingly. I have found, however, a few more things:

1. Size doesn't matter. Some of our best SI partners are 3-5-person shops. They are hungry to work with us and do exceptional work.
   
   
2. They're not in it for the license revenue. Because open source solutions tend to cost less, 10-50% in margin won't mean as much as it will in a bloated, proprietary software deal. But the good news is that there is still plenty of money for them to make in implementation. Open source doesn't obviate the need for customization to an organization's business processes.
   
   
3. SIs are absolutely critical to open source's success. A successful open source business model is one that scales well beyond its own employees. SIs give an open source company leverage and range. Building a robust SI channel is therefore one of the most important things an open source startup can do (in addition to building out a strong inside sales team).
   
   
4. To pay or not to pay? At Alfresco, without exception our best SIs are those that invest the most in Alfresco. They're the proactive partners who get neck-deep in the code and end up understanding it as well as we do. Generally speaking, they're also the ones who invest money upfront in our partner program. I'm not sure whether the commitment is a consequence of having invested actual dollars, or if it's a trailing indicator, but the two invariably go together. Lesson? If someone isn't willing to invest at least $2,000 in your company (in order to make a multiple of that on their first deal alone), are they really that committed to your product? Probably not.

I'd be grateful for any other insights people may have into this. Please share.