Recently in Software infrastructure Category

Last week I was pleased to have my second paper published here at Gilbane "Content and the Next-Generation PortalExperience" that you can now register for and download (for free) from the Beacon area of our website.

For many organizations, access to back office services is becoming an essential part of the experience they need to provide their website visitors.Their external websites form the front line of customer service and their Intranets play a vital role in employee engagement as the expectations rise for both audiences on what they can do over the web. In the paper I discuss how a portal infrastructure can be a natural fit for providing this blend of relevant services and content and there is an opportunity for organizations to shift their portal infrastructure from internal workhorse to a contemporary services interface.

The downside, as many organizations have discovered is that a portal implementation can come at the cost of the primary fuel of web engagement - good quality, fresh, relevant content. In the paper I look at the reasons for behind that and suggest a possible solution of adding a contemporary web content management system.

Like any enterprise integration, the fusing together of a portal platform and a WCM has it's own risks, principally that the resulting solution does nothing to improve the lot of the content author as it has the potential to expose these business users to multiple interfaces and complex processes. In the paper I go on to take a look at how to avoid and mitigate these risks, with the advice on some key attributes organizations need to look for when selecting the WCM system.

I hope you enjoy the paper and I'd very much like to hear your feedback - either here or you can find me on Twitter (@iantruscott)

The paper is now available from the Beacon area of our website and from e-Spirit, who sponsored the paper. You can also register for a webinar that e-Spirit will be hosting on 10th February 2011 during which I will be talking through the main points of the paper.  

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:

"Can stand alone micro-blogging solutions survive when platform plays introduce the feature?"

I immediately replied:

"Yes, if they innovate faster"

Greg shot back:

"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.

What do you think?

The use of microblogging and activity streams is maturing in the enterprise. This was demonstrated by recent announcements of enhancements to those components in two well-regarded enterprise social software suites.

On February 18th, NewsGator announced a point release to its flagship Enterprise 2.0 offering, Social Sites 3.1. According to NewsGator, this release introduces the ability for individuals using Social Sites to direct specific microblogging posts and status updates to individuals, groups, and communities. Previously, all such messages were distributed to all followers of the individual poster and to the general activity stream of the organization. Social Sites 3.1 also introduced the ability for individuals to filter their activity streams using "standard and custom filters".

Yesterday (March 3rd), Socialtext announced a major new version of its enterprise social software suite, Socialtext 4.0. Both the microblogging component of Socialtext's suite and its stand-along microblogging appliance now allow individuals to broadcast short messages to one or more groups (as well as to the entire organization and self-selected followers.) Socialtext 4.0 also let individuals filter their incoming activity stream to see posts from groups to which they belong (in addition to filtering the flow with the people and event filters that were present in earlier versions of the offering.)

The incorporation of these filters for outbound and incoming micro-messages are an important addition to the offerings of NewsGator and Socialtext, but they are long overdue. Socialcast has offered similar functionality for nearly two years and Yammer has included these capabilities for some time as well (and extended them to community members outside of an organization's firewall, as announced on February 25th.) Of course, both Socialcast and Yammer will need to rapidly add additional filters and features to stay one step ahead of NewsGator and Socialtext, but that represents normal market dynamics and is not the real issue. The important question is this:

What other filters do individuals within organizations need to better direct microblogging posts and status updates to others, and to mine their activity streams?

I can easily imagine use cases for location, time/date, and job title/role filters. What other filters would be useful to you in either targeting the dissemination of a micro-message or winnowing a rushing activity stream?

One other important question that arises as the number of potential micro-messaging filters increases is what should be the default setting for views of outgoing and incoming messages? Should short bits of information be sent to everyone and activity streams show all organizational activity by default, so as to increase ambient awareness? Perhaps a job title/role filter should be the default, in order to maximize the focus and productivity of individuals?

There is no single answer other than "it depends", because each organization is different. What matters is that the decision is taken (and not overlooked) with specific corporate objectives in mind and that individuals are given the means to easily and intuitively change the default target of their social communications and the pre-set lens through which they view those of others.

I just published a new white paper, Social Publishing with Drupal, sponsored by Acquia and also available here. We forget that publishing and blogging (including this post) are stove-piped operations. But what would happen if we could intelligently keep track of all these disparate threads, combining the authoritative content from trusted sources with insights from friends and colleagues, organized contextually around the ways we think about things and make decisions? Social publishing is a new lens for delivering business value.

Here's the executive summary for the white paper. Click the link above if you'd like to learn more. What's the future of social publishing? Let's start a debate. /geoff

EXECUTIVE SUMMARY
Social publishing combines groomed and authoritative content, produced by an organization and emphasizing its core messages, with user-generated content that customers contribute via blogs, wikis, and social media tools. Drupal is an example of a social publishing platform, developed and maintained as an open source project, and delivered at an affordable cost.

Drupal is now deployed in major media companies, high technology firms, universities, magazine publishers, government agencies (including the White House), research groups, and non-profit organizations. Whether it is in a commercial, non-profit, or government setting, organizations rely on Drupal to project their presence over the web and to channel the interactive experiences that foster communities of contributors.

By leveraging Drupal’s capabilities as a social publishing platform, organizations are able to reinforce their branded experiences and deliver relevant content to their customers and stakeholders. By exploiting Drupal as an open source project, developers supporting these organizations can easily enhance and extend Drupal’s capabilities, and introduce innovative modes of interactivity that meet specific business requirements.

Drupal is an attractive investment with substantial business benefits. Organization can keep their license and support costs modest by building on an open source project. Organizations can leverage the collective expertise of Drupal developers to solve immediate publishing problems. By relying on Drupal, organizations can stay abreast of the rapid technology changes when building competitive solutions for the digital age.

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. 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?

Box.net announced today that it has integrated its cloud-based document storage and sharing solution with Salesforce.com. Current Box.net customers that want to integrate with Salesforce CRM can contact Box.net directly to activate the service. Salesforce.com customers may now download Box.net from the Salesforce.com AppExchange.

Box.net services will now be available in the Lead, Account, Contact, and Opportunity tabs of Salesforce CRM. In addition, the Box.net native interface and full range of services will be accessible via a dedicted tab on the Salesforce CRM interface. Users can upload new files to Box.net, edit existing files, digitally sign electronic documents, and e-mail or e-fax files. Large enterprise users will be given unlimited Box.net storage. The Box.net video embedded below briefly demonstrates the new Salesforce CRM integration.

While Box.net started as a consumer focused business, today's announcement marks the first tangible manifestation of its emerging enterprise strategy. Box.net intends to be a cloud-based  document repository that can be accessed through a broad range of enterprise applications.

The content-as-a-service model envisioned by Box.net will gain traction in the coming months. I believe that a centralized content repository, located on-premise or in the cloud, is a key piece of any enterprise's infrastructure. Moreover, content services -- functionality that enables users to create, store, edit, and share content -- should be accessible from any enterprise application, including composite applications such as portals or mashups created for specific roles (e.g. sales and/or marketing employees, channel partners, customers). Users should not be required to interact with content only through dedicated tools such as office productivity suites and Content Management Systems (CMS).

Other content authoring and CMS software vendors are beginning to consider, understand, and (in some cases) embrace this deployment model. Box.net is one of the first proprietary software vendors to instantiate it. Adoption statistics of their new Salesforce CRM integration should eventually provide a good reading as to whether or not enterprise customers are also ready to embrace the content-as-a-service model.

Jive Software's announcement last week of the Jive SharePoint Connector was met with a "so what" reaction by many people. They criticized Jive for not waiting to make the announcement until the SharePoint Connector is actually available later this quarter (even though pre-announcing product is now a fairly common practice in the industry.) Many also viewed this as a late effort by Jive to match existing SharePoint content connectivity found in competitor's offerings, most notably those of NewsGator, Telligent, Tomoye, Atlassian, Socialtext, and Connectbeam.

Those critics missed the historical context of Jive's announcement and, therefore, failed to understand its ramifications. Jive's SharePoint integration announcement is very important because it:

• underscores the dominance of SharePoint in the marketplace, in terms of deployments as a central content store, forcing all competitors to acknowledge that fact and play nice (provide integration)
• reinforces the commonly-held opinion that SharePoint's current social and collaboration tools are too difficult and expensive to deploy, causing organizations to layer third-party solution on top of existing SharePoint deployments
• is the first of several planned connections from Jive Social Business Software (SBS) to third-party content management systems, meaning that SBS users will eventually be able to find and interact with enterprise content without regard for where it is stored
• signals Jive's desire to become the de facto user interface for all knowledge workers in organizations using SBS

The last point is the most important. Jive's ambition is bigger than just out-selling other social software vendors. The company intends to compete with other enterprise software vendors, particularly with platform players (e.g. IBM, Microsoft, Oracle, and SAP), to be the primary productivity system choice of large organizations. Jive wants to position SBS as the knowledge workers' desktop, and their ability to integrate bi-directionally with third-party enterprise applications will be key to attaining that goal.

Jive's corporate strategy was revealed in March, when they decreed a new category of enterprise software -- Social Business Software. Last week's announcement of an ECM connector strategy reaffirms that Jive will not be satisfied by merely increasing its Social Media or Enterprise 2.0 software market share. Instead, Jive will seek to dominate its own category that bleeds customers from other enterprise software market spaces.

As I pointed out in my first post (SharePoint: Without the Headaches - A Discussion of What is Available in the Cloud,) you don't necessarily need to host SharePoint in your own organization.  Although I believe that most businesses should focus on leveraging the front end of SharePoint to its full extent, it is important for non-technical users to have an understanding of what it takes to host SharePoint and why one might want to do so.  Therefore, this post provides a discussion of what it takes to host SharePoint and the driving factors for hosting SharePoint.

Microsoft's original intent was to build a tool that was easy to leverage by non-technical users.  Microsoft thought of this as the natural extension of Office to the web[1].  That being said, the complexities got away from Microsoft, and in order to leverage a number of features one needs access to the back end.

Before delving into the SharePoint back end, let me point out that many businesses hire SharePoint development staff, both permanent and on a consulting basis. I think that developing custom SharePoint code should be done only after thoroughly justifying the expense.  It is often a mistake.  Instead, organizations should clearly define their requirements and then leverage a high quality third party add-on.  I will mention some of these at the end of the post.

SharePoint is a fragile product and therefore custom code for SharePoint is very expensive to develop, test, and deploy. Furthermore, custom code often needs to be rewritten when migrating to the next release of SharePoint.  Finally, SharePoint is a rapidly growing product, and chances are good that custom code may soon become obsolete by new features in the next generation.

In my first post, I pointed out that inexpensive SharePoint hosting options are available in the cloud. These options tend to be limited.  For example, the inexpensive rentals do not provide much security, only provide WSS (not MOSS), and do not allow one to add third party add-ins.  It is possible to lease custom environments that don’t surrender to any of these limitations, but they come at a cost.  (Typically starting at $500 per month[2].)  I believe that robust MOSS offerings with third party add-ons will be available at competitive prices within two years. 

--------------------------------------------------------------------------------

[1] SharePoint is developed by the Office division.

[2] For example, FPWeb offers a SharePoint hosted environment with the CorasWorks Workplace Suite included starting at $495 per month.

Today is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology. For that very reason, Gilbane Group is presenting a panel entitled Google Wave: Collaboration Revolution or Confusion? at the Gilbane Boston conference, on December 3rd.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

To which I replied:

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

I am not a technologist. I seek to understand technology well enough that I can explain it in layman's terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

• XMPP for server-server communication
• HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
• HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
• Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee's question, I would unequivocally state that Google Wave is a "concept car" at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.

My friend Sameer Patel wrote and published a very good blog post last week that examined the relationship of Enterprise Content Management (ECM) and enterprise social software. His analysis was astute (as usual) and noted that there was a role for both types of software, because they offer different value propositions. ECM enables controlled, repeatable content publication processes, whereas social software empowers rapid, collaborative creation and sharing of content. There is a place for both in large enterprises. Sameer's suggestion was that social software be used for authoring, sharing, and collecting feedback on draft documents or content chunks before they are formally published and widely distributed. ECM systems may then be used to publish the final, vetted content and manage it throughout the content lifecycle.

The relationship between ECM and enterprise social software is just one example of an important, higher level interconnection -- the nexus of defined business processes and ad hoc collaboration. This is the sweet spot at which organizations will balance employees' requirements for speed and flexibility with the corporation's need for control. The following (hypothetical, but typical) scenario in a large company demonstrates this intersection.

A customer account manager receives a phone call from a client asking why an issue with their service has not been resolved and when it will be. The account manager can query a workflow-supported issue management system and learn that the issue has been assigned to a specific employee and that it has been assigned an "in-progress" status. However, that system does not tell the account manager what she really needs to know! She must turn to a communication system to ask the other employee what is the hold up and the current estimate of time to issue resolution. She emails, IM's, phones, or maybe even tweets the employee to whom the issue has been assigned to get an answer she can give the customer.

The employee to whom the issue was assigned most likely cannot use the issue management system to actually resolve the problem either. He uses a collaboration system to find documented information and individuals possessing knowledge that can help him deal with the issue. Once the problem is solved, the employee submits the solution to the issue management system, which feeds it to a someone who can make the necessary changes for the customer and inform the customer account manager that the issue is resolved. Case closed.

The above scenario illustrates the need for both process and people-centric systems. Without the cludgy, structured issue management system, the customer account manager would not have known to whom the issue had been assigned and, thus, been unable to contact a specific individual to get better information about its status. Furthermore, middle managers would not have been able to assign the case in a systematic way or see the big picture of all cases being worked on for customers without the workflow and reporting capabilities of the issue management system. On the other hand, ad hoc communication and collaboration systems were the tools that drove actual results. The account manager and the employee to whom the issue was assigned would not have been able to do their work if the issue management system was their only support tool. They needed less structured tools that allowed them to communicate and collaborate quickly to actually resolve the issue.

We should not expect that organizations striving to become more people-centric will abandon their ECM, ERP, or other systems that guide or enforce key business processes. There is a need for both legacy management and Enterprise 2.0 philosophies and systems in large enterprises operating in matrixed organizational structures. Each approach can provide value; one quantifiable in hard currency and the other in terms of softer, but important, business metrics (more on this in a future post.) The enterprises that identify, and operate at, the intersection of structured process and ad hoc communication/collaboration will gain short-term competitive advantage.