I want to discuss what can be the next step in the development of social aspects of PLM tools as well as about what can become a major driver for future social PLM. Last year, we had chance to see multiple examples of how mature PLM vendors and small companies moved towards establishing products in the social domain. Social Innovation, Social Product Development, Social Design… All these buzzwords were used, but I want to dig inside and discuss how I can, practically, these tools can get some level of social acceptance in the enterprise.
Social vs. Siloed?
This is one of the questions that come to my mind when I’m thinking about multiple vendor race toward social tools. The major barrier is user adoption. How many social networks you can be a friend of? How you can track your participation in multiple forums, social groups, forums, etc. If tomorrow’s product will come as social software from multiple vendors? SharePoint communities vs. Salesforce Chatter? How many other social networks and communities can practically exist in the organization? My conclusion is that social experience cannot be siloed – the certain mechanism needs to be to allow people to communicate across business application boundaries.
Social API
How to organize cross application social experience. This problem is not new these days and exist in multiple social networks we have today – facebook, linkedin, myspace, ning etc. The option to integrate communication across these networks can be development of some social API that allows to the communicate in a singular way. An example of such an API can be OpenSocial:
OpenSocial helps these sites share their social data with the web. Applications that use the OpenSocial APIs can be embedded within a social network itself, or access a site’s social data from anywhere on the web.
I’d recommend you to take a look on Open Social for Enterprise white paper. Some interesting concepts are defined there about how API can be used to allow cross application social tool to co-exist and not to be siloed into specific application niches.
OpenSocial Architectural Concepts
Broadly speaking, OpenSocial defines two concepts. The first is gadgets, a component model based upon HTML, Cascading Style Sheets (CSS), and JavaScriptTM, that describes how content gets managed and rendered inside a Web browser. If you use sites like iGoogle, then you are already familiar with gadgets. The second is a set of APIs for accessing and working with social data. These APIs define how you access information about a person, their relationships, and their activities. These APIs are made available for use in gadgets, via a set of JavaScript APIs, as well as programmatically via REST. OpenSocial applications can take the form of gadgets that can be embedded into any container that supports the OpenSocial specification or traditional SOA services for integration. Taken together, the gadget component model, social APIs, and REST interfaces, provide a programming model that enables the creation of standards-based social applications.
You can see adoption of Social APIs and OpenSocial specifically for existing social networks from MySpace, Ning, LinkedIn, Google and some others.. .
What is my conclusion today? PLM is interesting to jump into social bandwagon. However, PLM will be able to do so only by adoption of some “open behaviors” that are considered as must-attributes of the social world. This is will be even more important in enterprise rather than in the consumer world.
Just my thoughts.
Best, Oleg
