Tag Archives: application

Lotusphere 2012: IBM Demonstrates the Power of the Platform, Simplified

This entry was cross-posted from Meanders: The Dow Brook Blog.

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.

Advertisements

Telligent Gains Leverage on Its Cloud and Mobile Roadmaps

Telligent Systems, Inc. announced on Monday that it had acquired Leverage Software, a competing provider of enterprise social capabilities used to support communities and customer relationship management efforts (see press release). The deal closed at around 10:00am CST, after about two months of discussions and paperwork, according to Telligent’s Founder and CTO, Rob Howard, and Wendy Gibson, Telligent’s CMO. Leverage’s brand and people will be integrated into Telligent starting immediately, and technology integration will occur some time in 2012.

At first glance, this seemed like a straight-forward acquisition with a clear purpose. That initial impression was validated upon speaking with Howard and Gibson shortly after the news broke. Telligent gains several strategic pieces that will strengthen its offerings through the acquisition of Leverage, including cloud, mobile, and analytics technology; people with .NET and iOS development skills; and some marquee customers.

The single largest impact of the acquisition will be an accelerated delivery of Telligent’s cloud offerings roadmap. Telligent Community is available today in a hosted, single-tenant version only. Leverage Software’s platform was built on a multi-tenant SaaS architecture in 2003, so they have extensive experience in the cloud. Both vendor’s products and services are built on .NET and other Microsoft technologies, which should ease the transformation of Telligent Community (and, most likely, Enterprise) to a multi-tenant architecture. Additionally, the rich API set of Telligent’s Evolution platform should speed the integration of the vendors’ offerings in the near term. When asked, Howard noted that Telligent will continue its existing, early-stage efforts to build and deliver functionality on Microsoft’s Azure infrastructure.

Telligent’s mobile capabilities will also receive a boost from the Leverage Software acquisition. Leverage has developed an iOS-native version of Leverage Community, which is sold through Apple’s iTunes Store. Earlier this year, Telligent introduced tools in its Evolution platform that extend Telligent Community and Telligent Enterprise to Apple’s iPhone, as well as Blackberry and Android devices. However, Telligent does not offer device-specific versions of its products. With their experience, Leverage’s developers should be able to change that fairly quickly, at least for iPhone and iPad. Telligent has previously discussed plans to build HTML5-compliant versions of its community applications as well.

Leverage Software claims to support 250 communities, with 15% of the Fortune 100 as customers. Well-known brands such as The Home Depot, Pearson, and Wells Fargo have demonstrated the scalability and effectiveness of Leverage’s technology. Telligent’s Gibson remarked that they are very pleased to be adding Leverage’s customers to their portfolio and that they would begin on-boarding them soon after the brands have been united.

Unlike some of its more marketing driven competitors, Telligent has grown its business the old-fashioned way, by quietly delivering a platform and applications that have helped customers meet well-defined, community-centric business objectives. The company has a loyal and highly enthusiastic customer base. Now, with the acquired assets of Leverage Software, Telligent is poised to accelerate its growth, as well as the success of its customers and their internal and external communities.

One other thing has been accelerated as a result of this acquisition – the consolidation of the Enterprise Social Software market. It will be interesting to watch Telligent in 2012, as it will likely make other acquisitions in order to offer additional functionality on its platform. Telligent would also be an attractive acquisition for a larger vendor seeking an extensible, Microsoft-centric enterprise social software platform. Either way, next year will be an interesting one for Telligent and its customers.

This entry was cross-posted from Meanders: The Dow Brook Blog. Telligent Systems, Inc. is a Dow Brook Advisory Services client.

TIBCO Launches tibbr and Demonstrates the Difference Between Social Business and Enterprise 2.0

There has been a debate raging for a couple of months now on whether there is a difference between “Enterprise 2.0” and “Social Business” and, if so, what it is. The debate began concurrently with the Enterprise 2.0 Conference, held in Santa Clara, in November 2010. I weighed in then with my take in this post. Since then, the debate has moved over to Quora, where someone asked, “What are the distinctions between Social Business and Enterprise 2.0”.

In spite of all this discussion, it was not until today that the difference between Enterprise 2.0 and Social Business truly became clear to me. The event that triggered my new-found understanding of these terms was the launch of tibbr, TIBCO’s “social computing tool”.

As TIBCO Chairman and CEO Vivek Ranadivé explained during the launch event, tibbr was built to deliver the right information, to the right people, in the right context. A noble goal indeed. tibbr takes advantage of TIBCO’s well-honed expertise in the management of real-time messaging at scale, their extensive library of enterprise system adapters, and a real-time rules engine that creates context for content.

Note the discrepancy between Ranadivé’s statement and the actual focus of the tool. tibbr is all about systems integration and message delivery; people are incidental objects in the system. This is intentional, as stated in TIBCO’s press release on tibbr:

“tibbr breaks business users free from one-dimensional social tools that focus on people…”

Ram Menon, EVP Worldwide Marketing at TIBCO further underscored the notion that tibbr is not about people relationships in two remarks. In the first instance, Menon described tibbr in terms of “process, subjects, applications, and people”, literally in that order. Later, Menon said that within tibbr, one “can follow people, but most importantly [textual emphasis mine, but reflects his vocal inflection]…can follow applications, can follow data.”

Do you see it? tibbr is the poster child for Enterprise 2.0, as it was originally defined by Professor Andrew McAfee. tibbr is literally about applying Web 2.0 technology design principles to enterprise systems. Social Business, on the other hand, puts people first – before applications, processes, and subject entries in the corporate taxonomy. The difference could not be clearer.

Yes, one can follow another individual in tibbr. However, as Jon Scarpelli, VP of CIBER’s Outsourcing Practice recounted during the launch event, his company switched from Yammer to tibbr because CIBER employees were “more interested in following subjects”.

My point? Social Business is about people first. Enterprise 2.0 is primarily about technology that enables business processes (or, more accurately, barely repeatable processes and process exceptions) via human interaction. Both are valid and valuable approaches to structuring and running an organization, but it is critical to know which one your company values most. Does it want to be a social business that emphasizes and connects people, or an entity that uses Web 2.0 technologies to achieve business goals when rigid, transactional systems can’t help? Answer that question first, then choose your technology solution.

Enterprise Social Software and Portals: A Brief Comparison of Deployment Patterns

In my last post, I examined whether or not Enterprise Social Software (ESS) is the functional equivalent of enterprise portal applications as they existed ten years ago. My conclusion was:

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgment, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

In this post, I will focus on the observation that ESS resembles enterprise portals in another regard – how and why it is deployed.

Enterprise v. Smaller Deployments

Portals were initially marketed as a tool for enterprise-wide communication and interaction, with each internal or external user role having its own personalized set of resources available in the user interface. While there were some early enterprise-wide deployments, portal software was deployed far more often at the functional level to support specific business processes (e.g. sales, procurement, and research portals) or at the departmental level to support operations.

Enterprise social software has also been touted as most valuable when deployed across an organization. However, like portal software, ESS has most often been deployed at the functional level in support of activities such as marketing, customer service, and competitive intelligence. As a result, the promised network effects of enterprise-wide deployments have not been realized to-date, just as they were not with most portal deployments.

Internal- v. External-Facing Deployments

Most early portal deployments were internally-focused, as shown in this InformationWeek summary of market research conducted in 2001. Not only was there a smaller number of externally-focused deployments, mixed-audience deployments did not begin to appear until the portal market was extremely mature. ESS deployments have followed this same pattern, and we are just now seeing early efforts to blend inward- and outward-facing business activity in common ESS environments.

Internal Use Cases

Portal software was often deployed in response to a specific business need. Among the most common were:

  • intranet replacement/updgrade
  • self-service HR
  • application aggregation
  • document/content management
  • expertise location
  • knowledge sharing
  • executive dashboards

ESS has been deployed for many of the same reasons, especially intranet replacement, application aggregation, expertise location, and knowledge sharing.

External Use Cases

Portal software was deployed externally to provide self-service access to corporate information. In some cases, access to selected application functionality was also provided to key business partners. Retail and B2B portals enabled customers to purchase goods and services online. Process acceleration, revenue growth, and cost reduction were the key business drivers behind nearly all external portal uses.

ESS doesn’t seem to have the same goals. I have seen some, but little, evidence that external communities are being leveraged to accelerate business processes or reduce costs. Peer support communities are a good example of cost reduction via ESS. The goal of most outward-facing ESS deployments seems to be customer engagement that translates (eventually) into increased innovation and revenue for the deploying organization.

Conclusions

ESS deployments today strongly resemble portal projects that were undertaken ten years ago. Few, if any, ESS deployments have been enterprise-wide. Instead, ESS is deployed to many of the same department and functional groups, to support the same business processes, and to drive many of the same business results as portals were a decade ago (and still are.)

What does this commonality with early portal deployments mean for ESS? I will examine that in my next post. Until then, I would love to hear your reaction to what I have presented here.

Enterprise Social Software: The Second Coming of Enterprise Portals?

Enterprise Social Software (ESS), at first glance, is eerily similar to the portal software that was the hot enterprise toolset 10 years ago. That became very clear to me during the Enterprise 2.0 Conference in Boston last month, even though I was only able to attend the first 2 (of 4) days of the event.

I have noticed and commented on the parallels between the portal software market as it existed a decade ago and today’s enterprise social software category in a previous post. However, the notion of their similarity was reignited by a comment that I overheard as I walked through the exposition space at this year’s E2.0 Conference. One individual said to his companion something to the effect that if the branding was removed from each vendor’s ESS demo, one would be hard pressed to say which offering came from which specific provider. In other words, there was very little differentiation of user interface (UI) layout or functionality. In fact, every screenshot and live demo that I saw looked like a portal, in that the UI was a collection of data and unstructured information aggregated into a single interface and presented through a number of widgets.

Similarities in Functionality

In 1999, Delphi Group published a portal architecture diagram, which depicted the layers of functionality that the firm thought were required of a robust enterprise portal solution.

Examining each layer of the portal architecture model and commenting on its applicability to ESS as it exists today will allow us to determine whether ESS really is just another incarnation of portals or if there is something significantly different being offered.

Presentation: In portals, data, unstructured content, and application functionality were  aggregated from multiple sources and presented in widgets, whose layout on the screen was usually customizable by individual users. ESS strongly mimics this UI design, including, in some cases, the ability to customize which widgets are displayed. Most ESS providers are beginning to offer application stores stocked with widgets that can be run in their offerings, exactly like portal software vendors rolled out portlet libraries for their users a decade ago. Finally, portal access on mobile devices was big deal 10 years ago, as is mobile access to ESS functionality today. So portals and ESS certainly appear to be the same.

Personalization: The primary value-add of portal software, in addition to it aggregation capabilities, was its ability to personalize (and, thus, filter) information based on a user’s unique digital identity and organizational role. ESS needs to improve vastly in this area; currently, most information must be manually filtered. This typically occurs via selection of one or more parameters ( to narrow the organization’s activity stream) or by following an individual, group, space, or tag. ESS should apply more profile information and use heuristics to dynamically effect what information is applied on an individuals dashboard or home page.

Collaboration: Some portal deployments embedded collaboration workspaces or their individual elements (IM or chat, discussion forums, polls) into the UI, but, in general, most deployed portals fell short as full-fledged collaboration tools. ESS is a definite improvement here. The array of available collaboration tools is richer and they are more usable, which results in higher adoption.

Process: There was a lot of ink spilled about process portals, but the promise was never fully realized, although there were some exemplary deployments. Process portals had workflow (BPM) either embedded directly into the portal technology or available though an integration with a stand-alone process engine. Similarly, there has been much talk about the need to process enable ESS. The good news is that we might actually execute on the vision this time around. We are beginning to see process-related notifications generated by applications integrated with ESS appear in activity streams. The next step will be to add lightweight activity and information coordination functionality (not full-blown, rules-based BPM) to ESS.

Publishing & Distribution: Portals were (and are) used to publish links to documents, syndicated content, and web clippings. ESS is also used heavily to publish and distribute content and goes well beyond what was possible in portals 10 years ago by adding additional content sources such as status messages, shared bookmarks, blogs, and wikis.

Search: Despite the push nature of information flow in portals, the ability for individuals to find and pull information was also very important for portal users. Search is equally important in ESS and, generally speaking, has under-performed, as it did in portal implementations. So, unfortunately, the similarity in this aspect between portals and ESS is negative in effect.

Categorization: Taxonomies were widely used in portals deployments to aid information personalization. They are still important in ESS, but their new relative, Tagging, is equally valuable in its ability to aid information personalization, browsing, and recall. We now have more tools at our disposal to apply to the information overload challenge than we did 10 years ago.

Integration: Integration of other enterprise applications and content sources was key to realizing the value that portals offered through their ability to aggregate information into a single interface. Portal integration was accomplished using a combination of hard-coded connectors, XML, and JSR-168/WSRP standards. The ESS value proposition also seems to be closely tied to the integration and aggregation model. However, ESS makes better use of defacto integration standards, including REST, RSS, and OpenSocial.

Conclusions

From a functional perspective, ESS is quite similar to enterprise portal software in the way that it presents information, but that does not tell the whole story. ESS lacks critical personalization capabilities, but provides better collaboration, process, publication and distribution, categorization, and integration functionality than portals. In my judgement, ESS is somewhat similar to portal software, but mainly in appearance. It makes more functionality available than portals did, but needs to add a key missing piece – personalization.

Are there similarities in deployment patterns between ESS and portal software as it existed 10 years ago? If so, what do the functional and deployment affinities between the two software categories mean for the evolution of the ESS market? I will attempt to answer those questions in my next post. Until then, I would would appreciate any comments or questions you have on my analysis of their overall functional likeness and differences.

Have Software Suppliers Become Too Customer-Focused?

Remember the old dictum that says “the customer is always right”? Guess what, they aren’t.

Many times during my career as a management consultant, I have heard clients articulate their business needs and wants in the form of technical solution requirements. Besides completely ignoring the important intermediary step of stating those needs and wants as business requirements, the technical requirements voiced too often reflect only what the client knows to be possible; they do not imagine new and alternative technical solutions to business challenges. In other words, customers are not always a great source for innovative ideas on software functionality, much less on entirely new products.

I mention this because, lately, I have been hearing so many software vendors saying how focused they are on use cases and requirements voiced by their customers. Platform module and individual application development seems to be highly driven by customer feedback these days. Perhaps too highly.

Please do not misunderstand; software suppliers should consult frequently with customers, absorb their feedback, and develop against their use cases and requirements. However, vendors must also proactively imagine and build new functionality that will help customers overcome real and critical business challenges in ways that that they did not realize were possible.

A few software suppliers are mindful of this need. I recently saw a position opening announcement for a Senior Product Manager at a software provider that listed the following as one of the key qualifications for a successful candidate:

A demonstrated ability to get past what customers say they want and deliver what they really need

WOW! How powerful is that? It would be difficult to say it in a more simple, clear fashion.

The point of this post is to encourage software providers to think beyond stated customer technical requirements. Those are an important part of product planning, but cannot be the sole basis on which current product development and long-term roadmap decisions are made. Think and act like a management consultant; help your customers envision previously unimagined possibilities. That is a sustainable source of product innovation and competitive advantage.

Salesforce Chatter Promises to Take Enterprise 2.0 to the Next Level

Salesforce.com today announced “a new secure enterprise collaboration application and social development platform”, called Chatter. While it will not be available until an unspecified date in 2010, Chatter will likely raise the bar for Enterprise 2.0 software, because of the promised ability to embed its functionality into other enterprise applications.

Chatter includes many of the social components that are the core of existing Enterprise 2.0 software offerings: Profiles, Status Updates, Feeds, Groups (Communities), etc. What is different — and significant — about Chatter is that any of those components can be integrated inside any existing enterprise application, including Salesforce CRM and the 135,000 custom applications built on the Force.com platform. In short, Salesforce.com will not make users collaborate through the Chatter interface; they will be able to leverage Chatter’s social functionality in the context of work that they are doing inside a CRM, ERP, or other enterprise system.

The ability to deploy social functionality as a service within an existing (or new) enterprise application is a game changer. To-date, only one other E2.0 software vendor that I am aware of (MindTouch) has been able to make that claim. Salesforce.com is the first proprietary software provider with a very large set of enterprise customers and third-party developers to offer social functionality as building blocks (services) that can be consumed in other, independent applications.

The Enterprise 2.0 crowd has been focused on adoption in 2009 and has recently begun to realize that integration of social functionality into existing and new enterprise applications and platforms will be key to increasing adoption (see my previous posts on this topic: Thought of the Day: September 17, 2009 and The Impending Enterprise 2.0 Software Market Consolidation). Salesforce.com’s announcement of Chatter begins to make that vision a reality, and at scale.

Two other aspects of Chatter demand attention. First, at a time when established Enterprise 2.0 software vendors are touting their ability to integrate with Microsoft SharePoint (see my previous post, Integration of Social Software and Content Management Systems: The Big Picture), Salesforce.com has chosen to provide integration with Google Apps instead. Salesforce.com will use the Google Data APIs to enable data communication between Chatter and Google Apps. This is hardly a surprise, given that cloud computing is core to both companies.

The other striking aspect of Chatter is its embrace of popular consumer social networking applications such as Facebook and Twitter. This occurs at a time when many organizations are blocking employee access to those tools for security, privacy, and productivity reasons. Salesforce.com already features bi-directional communication between its Force.com platform and Facebook, having launched the Force.com for Facebook developer toolkit a year ago. Now Salesforce.com is providing a similar developer toolkit for Twitter.

Chatter is an announced offering, not a shipping product. As such, it is already being compared to Google Wave in the collaboration market. However, Chatter is much more likely to make a significant impact in the E2.0 space, because Salesforce.com has always been focused on enterprise customers, while Google’s offerings started as consumer products and have only recently begun to slowly gain traction within enterprises. Google may bring Wave out of beta before Salesforce.com launches Chatter, but I expect that will make little difference as to which one sees better enterprise adoption in 2010. It is very likely that more organizations will understand Chatter’s value proposition of easily integrated social functionality.