Talk about a trip down memory lane… Another excellent blog post yesterday by my friend and fellow Babson College alum, Sameer Patel, snapped me back a few years and gave me that spine tingling sense of deja vu.
Sameer wrote about how the market for Enterprise 2.0 software may evolve much the same way the enterprise portal software market did nearly a decade ago. I remember the consolidation of the portal market very well, having actively shaped and tracked it daily as an analyst and consultant. I would be thrilled if the E2.0 software market followed a similar, but somewhat different direction that the portal market took. Allow me to explain.
When the portal market consolidated in 2002-2003, some cash-starved vendors simply went out of business. However, many others were acquired for their technology, which was then integrated into other enterprise software offerings. Portal code became the UI layer of many enterprise software applications and was also used as a data and information aggregation and personalization method in those applications.
I believe that much of the functionality we see in Enterprise 2.0 software today will eventually be integrated into other enterprise applications. In fact, I would not be surprised to see that beginning to happen in 2010, as the effects of the recession continue to gnaw at the business climate, making it more difficult for many vendors of stand-alone E2.0 software tools and applications to survive, much less grow.
I hope that the difference between the historical integration of portal technology and the coming integration of E2.0 functionality is one of method. Portal functionality was embedded directly into the code of existing enterprise applications. Enterprise 2.0 functionality should be integrated into other applications as services (see my previous post on this subject.) Service-based functionality offers the advantage of writing once and using many times. For example, creating service-based enterprise micro-messaging functionality (e.g. Yammer, Socialcast, Socialtext Signals, etc.) would allow it to be integrated into multiple, existing enterprise applications, rather than being confined to an Enterprise 2.0 software application or suite.
The primary goals of writing and deploying social software functionality as services are: 1) to allow enterprise software users to interact with one another without leaving the context in which they are already working, and 2) to preserve the organization’s investment in existing enterprise applications. The first is important from a user productivity and satisfaction standpoint, the second because of its financial benefit.
When the Enterprise 2.0 software market does consolidate, the remaining vendors will be there because they were able to create and sell:
- a platform that could be extended by developers creating custom solutions for large organizations,
- a suite that provided a robust, fixed set of functionality that met the common needs of many customers, or
- a single piece or multiple types of service-based functionality that could be integrated into either other enterprise application vendors’ offerings or deploying organizations’ existing applications and new mashups
What do you think? Will history repeat itself or will the list of Enterprise 2.0 software vendors that survived the impending, inevitable market consolidation consist primarily of those that embraced the service-based functionality model?