Multiple Communities, Multiple Platforms?

Found this interesting comment in a blog post by Tony Byrne from CMS Watch on the social software marketplace and the fact that Intel leverages multiple community software vendors:

What this should tell you? That large companies at the forefront of enterprise social computing — like Intel, Dell, and others — routinely turn to multiple suppliers for different types of internal and external communities. This may have something to do with inter-departmental politics and silos, but I think it actually makes sense: different vendors in this marketplace target different scenarios and will therefore be better suited to different business objectives

While I certainly agree that different vendors target different scenarios, I’m not sure I’d so easily accept the notion that multiple internal and external platforms make sense. He continues:

For example, Telligent sees some internal implementations, but is known mostly for its external-facing community implementations, while Jive’s Clearspace can and does get implemented externally, but is mostly known for its behind-the-firewall implementations. You the buyer should not assume that one size fits all.

Of course there’s no one-size-fits-all approach to community building. But does that necessarily mean the answer is to license multiple competing proprietary platforms for a single enterprise?

How well integrated are an internal implementation of Java-based Clearspace and an external implementation of .NET-based Telligent ever going to be, given that both are proprietary?

  • What happens when Intel’s business needs suggest sharing content from the internal Clearspace community with users in the external Telligent community? How difficult is it to migrate content from one to the other?
  • What happens when the internal community realizes it might benefit from external input, or the external community starts to involve internal users?
  • Do users who have a presence in both maintain separate usernames and passwords? How easily can both be pointed at a shared user repository?
  • How efficient is it from an IT management point of view to have ongoing enterprise license agreements with two vendors? Do users joining both communities essentially increase the license fees for both vendors?

Of course, imposing one monolithic solution may not be possible either. I regularly deal with clients who have not just two core content management systems but as many as five or six: due to the “inter-departmental politics and silos” Tony mentioned above, or due to corporate acquisitions which bring their own legacy systems, or due to serial leadership changes and different IT strategies over time.

How do you enable the right balance of “fit-to-purpose” (which might identify different platforms for different social scenarios) against “fit-to-enterprise” (which would explore the impact of platform proliferation and silos)? What happens when the community you expected to be purely internal suddenly realizes that it would benefit from external input?

Leveraging mature open source platforms- and customizing them to fit the specific scenarios of the community being served- will better preserve long term business agility and ensure that those silos don’t become islands, but can share data and functionality with each other.

See also: CMIS, ECM Interoperability, and Services-Oriented Content Management

2 Comments

  1. I wanted to pass along another few reasons why multiple communities typically develop within organizations (at least from what I’ve seen):

    • True to the spirit of enterprise (which is often obscured, albeit alive and well in most siloed organizations), each division, group or silo sees themselves as unique and important which often drives the desire for something “different”. This is apparent at several of my current clients where corporate standards dictate one direction but group preferences or available skill sets justify a deviation.
    • In many corporate divisions, IT budgets are separated, that is to say, not tied to an umbrella group. This often makes adherence to corporate IT standards financially difficult, if not impossible. For example, one corporate division may have a much larger IT budget and opt for the corporate database standard (e.g., Oracle), while another division doesn’t have the budget to even allow for “piggy-backing” on the enterprise license. In such situations I’ve seen corporate divisions opt for open source solutions to keep costs down. Interestingly, in divisions where open source is chosen because of these types of constraints, it often trickles up through the organization and is considered for larger divisions.
    • To the first point, and one you also mention in your blog post, choice is good. No one making a technology decision ever feels good about being pushed into a particular solution. While multiple communities/technologies is often positioned as a bad thing, it is better for the buyer in many ways. What’s not good for the buyer is the associated switching cost that comes with making a technology decision. I believe that’s why efforts such as CMIS are so important to the technology community, especially the technology *buying* community and that companies primarily on the buying side should be taking a more active interest in standardizations like CMIS.

    I’m curious what your thoughts are.

  2. Hey Kevin – thanks for your comments. I certainly agree there are some structural reasons that lead to community silos, and why the answer can’t just be a mandated one platform for everyone.

    But I think there have to be better options between that and acceptance of everyone using their own favored vendor. I think using Open Source platforms, and customizing the user experience to fit each department’s needs, but getting some shared standard and infrastructure on the back end, is a better path forward.

Comments are closed.