Tag Archives: suite

Software analysts and buyers have historically favored platforms over application suites and stand-alone applications. Why? Because platforms offer both a rich set of pre-integrated functionality and the ability to add or build new features and applications, some of which may be extensively customized for an organization.

IBM has long been considered a platform provider of enterprise software, particularly in the infrastructure and middleware categories. More recently, IBM has evolved from being a vendor of a collaboration suite (Quickr) to a provider of multiple integrated, extensible offerings for enterprise collaboration, social networking, messaging, content sharing and management, and customer- and employee-facing web experience management. IBM’s vision for for this confederation of offerings, codenamed ‘Project Vulcan’, was first articulated at Lotusphere 2010. Last year’s Lotusphere presented initial, limited evidence that the vision was becoming reality.

Lotusphere 2012, held last week, showcased IBM’s latest efforts at unifying its interaction platform. IBM previewed the upcoming releases of its Connections, Notes/Domino, and Customer and Intranet Web Experience offerings. As one would expect from a platform software provider, each of these products works with the others out of the box. However, IBM, has gone beyond merely providing integration between the separate offerings by embedding functionality from each into the others. For example, IBM customers who have licensed both Connections and Notes will soon be able to send and receive email from within Connections, and, conversely, consumers will be able to view and interact with the Connections activity stream from within Notes.

The increasing power of the IBM interaction platform was further underscored by demonstrations of related, integrated and embedded functional services from its Quickr collaboration, Content Manager and FileNet enterprise content management, and Cognos analytics offerings. This extended scope of the Project Vulcan vision is what sets IBM apart from other platform software vendors, and it was good to see IBM articulating and demonstrating that differentiation at Lotusphere.

Death of a Tradeoff

We, as an industry, have assumed the existence of a tradeoff between rich functionality and simple, intuitive user experiences. Conventional wisdom says that as more features are added, the resulting complexity degrades the user experience, forcing software architects and designers to find an optimal balance between functionality and usability. The tradeoff has traditionally been managed in one of two ways: 1) by creating simple, single-purpose applications that are not overloaded with functionality, or 2) by partitioning functionality into multiple, related applications in a suite. Platforms have largely not attempted to manage this tradeoff at all for developers/designers, administrators, or consumers. Not only is the platform’s complexity on full display; it is generally promoted as a benefit.

IBM’s implementation of its Project Vulcan vision has, for perhaps the first time, obviated the long-held tradeoff between functionality and ease-of-use at the platform level. The versions of Connections, Notes/Domino, and the Web Experience offerings that where announced and demonstrated at Lotusphere 2012 (and will be released over the course of this year) are both feature-rich and highly usable. Each offering has had its user interface redesigned, yielding a cleaner look that is more consistent across the interaction platform. Additionally, the new user interface designs are simpler than their predecessors and, in effect, minimize the complexity created by IBM’s extended integration and embedding of functionality from related software offerings.

This harmonious co-existence of broad, advanced functionality and a consumer-friendly computing experience is what makes IBM’s interaction platform really different and powerful. The first public glimpse of this next-generation enterprise software came during the Lotusphere 2012 Opening General Session, when Connections Next was demonstrated by its Lead Project Manager, Suzanne Livingston. My reaction, a tweet that was later displayed before the beginning of the Closing General Session, sums up the impact of IBM’s work on its interaction platform over the last year:

Dow Brook’s Point-Of-View

While there is more work to be done, IBM should be proud of the next-generation interaction platform it is bringing to market. Lotusphere 2012 demonstrated that IBM is in good position to be a provider of choice for social business software. The work that they’ve done over the last year strongly differentiates their interaction platform and should positively affect its adoption by customers. IBM’s refusal to acknowledge the old, limiting tradeoff between platform complexity and user experience should accelerate the consolidation of the Enterprise Social Software market in the second half of 2012. It may also more firmly establish IBM as a leader in the Web Experience software category and spark renewed interest in its Notes/Domino messaging and Sametime unified communications offerings.

Disclosure: IBM is a client of Dow Brook’s Insight OnDemand subscription advisory service and paid the author’s registration and hotel expenses related to Lotusphere 2012 attendance.

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

“is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?”

And, later, he asked a complementary question:
“is there a risk of Microblogging becoming “too complicated”?”

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is “yes”, because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

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?