Collaboration and Content Strategies Blog

Liferay Social Office, Another Supporter of SharePoint Protocols

Blogger: Larry Cannell

Liferay, the makers of the popular open source portal, will soon be releasing a new product called Social Office. This is collaborative workspace product that consists of newly developed features combined with capabilities that were previously offered as portal add-ons. A Liferay Social Office site provides document libraries, team calendars, activity tracking, instant messaging, blogs, wikis, message boards, and announcements.

However, what I find to be the most interesting new feature of Social Office is its support for Microsoft Office. Liferay Social Office will support (as other open source vendors have called it) "the SharePoint protocol.” Specifically, Social Office will support two protocols used by SharePoint: MS-DWSS (Document Workspace Web Services) and Microsoft’s version of WebDAV. Documentation for these (and other) protocols used by SharePoint and desktop Office applications were released by Microsoft earlier this year. I blogged about this a few weeks ago (“Cloning SharePoint” and “What the heck is a SharePoint Protocol?”). In short, support for these two protocols facilitates the use of the “Shared Workspace” pane in Office applications. This enables management of document workspaces from within desktop applications like Word, Excel, or PowerPoint.

Two new vendors supporting a protocol does not make for a trend, but I will be on the lookout for others to follow. Maybe then the argument could be made that MS-DWSS is the POP3 for collaborative workspaces.

SharePoint: It's Not a Gap, It's Room for An Ecosystem

Blogger: Craig Roth

There's an old coding joke: when presented with a bug in your program you try to pretend it is intentional by saying "It's not a bug, it's a feature!"  I'm reminded of that when told about the rich ecosystem Microsoft has nurtured around SharePoint 2007.  More information is coming out about the parts of SharePoint where a sophisticated enterprise has to look outside of what is in the box, such as our half day of sessions at Catalyst entitled "SharePoint: Fixing a Hole Where the Pain Gets In" or this article today in InternetNews.  And the more that information comes out, the more I think back to that old coding joke, except now it is Microsoft saying "It's not a gap, it's room for an ecosystem!"

Now, I am not saying that all gaps in SharePoint are mistakes.  Honestly, I don't know how many of the gaps filled by the ecosystem are due to intentionally leaving some portions of SharePoint to communities, developers, and vendors and how many simply happened because Microsoft didn't forsee common needs that it should have.  It's probably some of both.  The best way to determine that for yourself is to look at the feature sets from the long and growing list of partners filling gaps in SharePoint (not just integrating, but filling gaps) and determine if those are niche needs that a vendor should correctly leave to the ecosystem or basic needs that should be included to fit the way the vendor advertises its product should be used.

Too many SharePoint implementations wind up causing pain because a promising demo or proof of concept led planners to underestimate the difficulty of the full solution.  The same implementation might have been considered a roaring success if time and resources were understood upfront and did not follow a winding path with multiple failures before completion.  If you're in charge of an enterprise-wide SharePoint plan or a specific SharePoint site, you don't care if a gap in SharePoint is intentional or not. The task for you is to quickly assess what users will need from SharePoint and to set expectations up front that SharePoint out of the box may not get them there.  Determining what combination of built-in SharePoint capabilities, partner products, community-provided bits, and custom in-house coding will be required to deliver the expectations of the users will help paint a realistic picture of the time and resources needed. 

To summarize, perhaps a cartoon (from our Catalyst track) will help:

Is MS-DWSS The POP3 For Collaborative Workspaces?

Blogger: Larry Cannell

This is the last in a series of blog posts where I discuss what Alfresco's support of SharePoint protocols means and what can happen now that Microsoft has released technical documentation of their Office and Windows protocols. The first post is entitled "Cloning SharePoint" and the second post is "What the heck is a SharePoint Protocol?"

Alfresco Labs 3 is a thought provoking example of a type of solution that can be created now that Microsoft has released this protocol information. Whether intended by Microsoft or not, this documentation may have sparked the imaginations of developers. For developers who haven't grokked the opportunities yet, Alfresco Labs 3 could finally wake them up.

Extending existing solutions

Alfresco Labs 3 is a good example of how an existing server-based product can be extended to support functions previously only provided by SharePoint. Office applications, like Word, Excel, or Powerpoint can interact with Alfresco as if it were a SharePoint server. At this time Alfresco is only leveraging a small subset of the SharePoint protocols but there may be many more opportunities to use them to support functions like forms processing and more formal document and records management functions.

Products or services that don't even manage documents stored as files might benefit from adding support for SharePoint protocols. For example, it's not out of the realm of possibility that Google Sites and Google Docs could be manipulated directly from within Office applications using these protocols.

From the client side of the protocol, its in the best interest of Office competitors, like OpenOffice or Adobe Buzzword, to work directly with document workspaces stored on a SharePoint (or SharePoint-compliant) server.

Standardizing the collaborative workspace

But perhaps the most exciting opportunity enabled by the release of these protocols is the standardization of collaborative workspaces. One of the biggest obstacles to widespread adoption of collaborative workspaces is the general lack of familiarity of what these things are. Can SharePoint, along with the publication of its protocols, become the basis of a collaborative workspace standard? In many respects this is similar to the effect standards like IMAP4, POP3, and SMTP have had on e-mail. If this is the case, this might be more than Microsoft bargained for when publishing these protocols.

Let me step back for a minute. By now, just about anyone who uses the Internet is familiar with e-mail. All e-mail users are able to exchange messages and many of them are capable of opening documents that are attached to messages. The same cannot be said about collaborative workspaces. Although the benefits of collaborative workspace are enormous, relatively few people (at least, compared to e-mail) use them on a regular basis. But, this wasn't always the case with e-mail. I remember first having my e-mail address printed on a business card and getting puzzled looks from most who saw it.

My thinking at this point goes like this:

• E-mail is popular because it offers something understandable (an electronic memo) and there are standard protocols (POP3, IMAP4, SMTP) that allows anyone to create an e-mail product. This open, competitive market enabled the development of simple, understandable products and services. The combination of good e-mail products and service providers that understood what it provided allowed e-mail to flourish when Internet connectivity became broadly available.
• Collaborative workspaces have been hindered because it is hard for the novice to understand what they do ("it's like a network drive...no, it's for managing projects...but, we could also use it as our portal....its a floor wax, no wait its a desert topping ?!?!?") and there hasn't been any protocols that allowed anyone to create a  standard collaborative workspace product. Each product on the market today looks different but, more importantly, each product uses different metaphors. For the average corporate worker switching from using an eRoom, to Quickr, or a SharePoint site can be disconcerting. Not only do they use different metaphors but they can be (and are) customized differently too. Compare this to the level of frustration it takes to get someone to try a different webmail product, for example. The e-mail interface is intuitive enough at this point that just about anyone can immediately use it.

One approach to solving this problem is to simply make a collaborative workspace product broadly available. Microsoft is doing this by bundling SharePoint Services with Windows Server. Google is approaching this by giving away Google Sites and Google Docs.

However, the release of specifications that define how a client application communicates with a collaborative workspace server and the availability of a reference implementation (i.e. SharePoint and the Office client applications) represents a de-facto standard for a simple collaborative workspace.

In particular, I am referring to these two standards that were part of the documentation released by Microsoft:

• "Document Workspace Web Service Protocol Specification" (MS-DWSS) - From the specification document: "A Document workspace is a convenient and centralized place for people to collaborate on a project." These workspaces consist of a document library, a calendar, a discussions forum, a list of announcements, a list of tasks, and a list of links.
• "Meetings Web Services Protocol Specification" (MS-MEETS) - From the specification document: "A meeting workspace is a convenient and centralized place for project collaboration and meeting proceedings." These workspaces consist of a document library, a list of objectives, an agenda (a list of agenda items), and a list of attendees.

If I were involved in an open source project that wanted to compete with Microsoft SharePoint or Office I would look to implement these two standards. Although it will be interesting to see how products like Alfresco improve their chances to sell into companies using Microsoft technologies, I am even more interested to see what new innovations the availability of these protocols bring about. Perhaps MS-DWSS (or MS-MEETS) can be the protocol that defines how clients and servers work together to provide standard collaborative workspaces. Imagine having interchangeable clients and servers providing the same, simple workspace function. It might just simplify the collaborative workspace market enough so that most people can actually...you know...collaborate with them!

So my question is: Can MS-DWSS bring to collaborative workspaces what POP3 brought to e-mail?

What the heck is a SharePoint Protocol?

Blogger: Larry Cannell

This is the second in a series of blog posts where I discuss what Alfresco's support of SharePoint protocols means and what can happen now that Microsoft has released technical documentation of their Office and Windows protocols. The first post is entitled "Cloning SharePoint."

Alfresco's press release last week described Alfresco Labs 3 as offering "Microsoft Office SharePoint protocol support requiring no additional client installation." So just what is a "SharePoint Protocol?"  SharePoint is a web application and the only obvious network protocol involved is between a web server and browser, right? True, but SharePoint also integrates with other Microsoft Office products using network protocols that enable Office users to interact with SharePoint without having to leave the application and use a web browser. Some of these include:

• Opening files directly from an Office application like Word, Excel, or PowerPoint. In this case the application works directly with files stored in SharePoint. Many collaborative workspaces will first download a file to local storage before it is opened by an Office application and then sends it back to the server when the Office application closes (or it may require this to be done manually). But, Microsoft Office applications can work with files in SharePoint directly. For example, when Word opens a file stored in SharePoint you may see something like the picture below indicating the application is transferring the file from a web server. Saving a file results in it transferring back over the network to SharePoint (which can be slow if you have a large file and often save changes, so there is a tradeoff):

• Working with "document workspaces" from within an Office application. "Document workspaces" are collaborative sites which you can create from a template in SharePoint or from within an Office application. They contain a document library, a calendar, a discussion forum, a list of tasks, and a list of links. Document workspaces are manipulated in the Shared Workspace panel of Office applications. The example below shows how this panel looks in Word. Just below it is a close-up of the tabs along the top of the panel (from left to right: status, members, tasks, documents, and links).

• Other examples include: creating a "meeting workspace" from the Microsoft Outlook scheduling interface (these are similar to document workspaces), Microsoft Access can link to data stored in SharePoint lists, Outlook can synchronize with calendars stored in SharePoint, Microsoft Excel can publish a worksheet to be shown by Excel Services (a SharePoint feature that renders a spreadsheet in a browser), and several others.

Alfresco and SharePoint

Alfresco Labs 3 supports the SharePoint protocol that enables the use of document workspaces within an Office application (like the Word screenshot above). The protocol is officially called "Document Workspace Web Service Protocol Specification" and is referred to in the Microsoft documentation as MS-DWSS. You can find the document describing this protocol here. I haven't tested all of these scenarios in Alfresco but the protocol specification says it can be used to "create, edit, and delete workspaces and folders for a site configured as a Document Workspace."

To learn more about this I created an Alfresco Share collaboration site using the Alfresco Share Preview. Here is how the site looked in my web browser after I added two documents:

And this is how the same Alfresco Share collaboration site looked from within Word:

Notice that the list of files looks almost identical to the Word/SharePoint example. However, Alfresco does not provide support for lists of tasks or links in a document workspace. These are two additional lists that are included in the document workspace template and are queried by the Office application to show in the Shared Workspace pane, but are not provided by Alfresco Share.

The documents listed in the Shared Workspace pane are opened by clicking on them. This is enabled by Alfresco's support of the WebDAV protocol (MS-DWSS is not involved in opening files). However, this is not a new capability for Alfresco. Many products have been supporting WebDAV for some time. Microsoft first showcased the use of WebDAV when it introduced Web Folders in Windows 98 and Windows 2000. A Web Folder shows a list of files in Windows Explorer as it they were a local folder. You can learn more about WebDAV at webdav.org.

In short, Alfresco Share presents itself as a document workspace to Office applications by supporting the MS-DWSS and WebDAV protocols. Other SharePoint protocols, which enable other Office application integrations with SharePoint (i.e. calendar synchronization, list access, Excel Services, and others), are not available in Alfresco Labs 3.

In my next blog post I will discuss how Alfresco's use of MS-DWSS is an example of the type of opportunities Microsoft has enabled by releasing Office protocol documentation. Some of these opportunities are related to product development but the biggest opportunity may be standardization of the collaborative workspace.

Cloning SharePoint

Blogger: Larry Cannell

This is the first in a series of blog posts where I discuss what Alfresco's support of SharePoint protocols means and what can happen now that Microsoft has released technical documentation of their Office and Windows protocols.

Last week Alfresco Software, the primary sponsor of the Alfresco open source enterprise content management (ECM) project, announced the availability of Alfresco Labs 3, a beta version of their forthcoming product release. Four key points were included in the announcement:

1. Alfresco Labs 3 is a "fully-compatible SharePoint repository" and offers "Microsoft Office SharePoint protocol support requiring no additional client installation."
2. The Alfresco Surf platform. This is based on the Alfresco web scripts framework that provides REST-based web service interfaces into the repository. It also leverages the Yahoo! User Interface Library and Adobe Flash to provide a better file uploading experience.
3. Alfresco Labs 3 includes a preview of the Alfresco Share application. This is a new collaborative website template built on Alfresco. It provides a simple team website with document libraries, blogs, wikis, discussions, a calendar, and a personalized dashboard. It can also be extended with other components.
4. Alfresco Labs 3 also shows off new platform features such as tagging and activities.

You can read more about the announcement from the press release and on John Newton's blog.

Reaction from the IT press was glowing. Although there were a number of good things included in the announcement, the SharePoint capabilities received all of the attention. InfoWorld's headline was "Open source ECM Alfresco now emulates SharePoint" but Network World took it a notch higher saying "Alfresco creates open source SharePoint clone."

What does this mean? Did Alfresco clone SharePoint? Will other vendors be coming out with their own cloned versions of SharePoint?

No, Alfresco did not clone SharePoint. Alfresco's use of the phrase "fully-compatible SharePoint repository" in the press release may have been a little over the top. However, Alfresco Labs 3 is a good example of how an existing server-based product can be extended to support functions previously only provided by SharePoint. Office applications, like Word, Excel, or Powerpoint can interact with Alfresco as if it were a SharePoint server. At this time Alfresco is only leveraging a small subset of the SharePoint protocols. However, it might be possible for Alfresco to use more of these protocols to support other functions like forms processing and more formalized document and record management features in Office.

But even without Microsoft Office support, Alfresco Surf is an intriguing collaborative workspace and is worth a look. It has a simple interface and will be familiar to anyone who have used things like blogs or discussion forums. The addition of Surf workspaces as well as capabilities like tagging and support for activities will probably have a broader impact on productivity of users than SharePoint protocol support, at least initially.

But, taking on SharePoint makes for good headlines. In addition, thinking about how these newly published Microsoft protocols could be used to extend existing products or become the basis of new products is an interesting topic to consider. What if the use of SharePoint protocols becames prevalent enough to become a de-facto standard for interacting with a collaborative workspace server?

In my next blog post I will answer the question: "What the heck is a SharePoint protocol!?"

European Data Points on Collaboration

Blogger: Craig Roth

It's been a while since my last blog post as I've been kept running all over Europe lately doing speaking (Domino Notes User's Group in Bremen) and visiting current and prospective clients in Munich, Copenhagen, Vienna, and London. 

Now that I'm home I'm decompressing and reflecting on what I was hearing from the corporate and government organizations I talked to about collaboration and portals. 

• I found a great deal of interest in social software, but the dozen or so organizations I spoke with seemed a bit further behind the U.S. in terms of awareness and piloting.
• There was quite a bit of SharePoint work going on, but generally in a more controlled fashion than I've seen in the U.S.  SharePoint was frequently being stripped down to fit into the rest of the environment.  To take a few examples, in one case it was being used as just a web file store.  In another case it was just a low-end content management system.  I prefer this approach to the whole-hog implementation that I see too often where Sharepoint steps on the toes of other installed infrastructure.  Just because Sharepoint can do a lot of things doesn't mean it has to in your organization.
• Portals were a hot topic, with most organizations I visited using them, sometimes many of them.  In fact, portal consolidation and governance is as big an issue as it was in my last few visits to Europe.
• Enterprise virtual worlds came up twice, without much prompting from me.  One governmental agency was very interested in its use for rehearsal and disaster preparedness.

Governance Isn't Maintenance

Blogger: Craig Roth

Web governance has been a topic of great interest to me for years now because it's a topic of great interest to my clients.  This is why we gave governance a starring role in our new Microsoft SharePoint Infrastructure Planning and Governance workshop.

I feel that Microsoft has woken up to the importance of addressing governance when it comes to SharePoint, a piece of infrastructure that is notorious for often being deployed (or evolving) in a wildly ungoverned fashion.  But when I look at the actual guidance being published outside of Burton Group, governance often seems to just mean maintenance.  For example, this CodePlex page on Governance and Manageability is 95% about manageability in my definition.  A site recycle bin? Management.  Splitting larger databases into smaller ones? Management. Arguably some of the other items listed here could assist with a governance effort even if they are not governance themselves.  For example, usage and storage metrics reporting could be used to check against a policy that a division shouldn't exceed 10GB of storage. 

For many years now I have been putting forth the view that web governance uses people, policy, and process to resolve ambiguity, manage short- and long-range goals, and mitigate conflict within an organization.  Technology only fits into this insofar as it supports a process that is needed to assist with compliance with the Statement of Governance.  The real value of governance is that it helps to pre-decide who wins in arguments before they come to a head (that's the "mitigate conflict" part of my definition).  Details about how to use the admin console to check for orphaned accounts or apply a template to a series of farms are unlikely to cause frothy arguments and are best left to separate maintenance manuals that can be approved and maintained on a different cycle than the Statement of Governance. 

The reason I get picky about what is governance versus maintenance is that the documents are often created by separate people as part of separate efforts and are on different update cycles.  A governance document may state that it's important that information on the website be kept fresh, therefore all web pages have to be updated every 180 days.  If it then goes on to describe which tools site administrators should use to run an aging tool or how to set site settings to expire documents then that information is likely to get out of date, be harder to find by admins who don't want to sort through all the high level stuff, and make the document too onerous for non-techies.  A second reason is that governance documents tend to be lopsided if they are created by techies that like filling it with topics they know a lot about and ignoring high-level, non-technical concerns.  A third reason is that anyone who asserts that they've written a statement of governance that just sprinkles a few platitudes about scope, goals, and policy into a detailed manual for maintenance and manageability is going to look foolish when the groups that truly understand governance (enterprise architecture teams or other higher level governance teams that have written higher level guidance) see the results.

SharePoint Excitement Mirrors Collaboration Dissatisfaction

Blogger: Craig Roth

At the 2008 SharePoint Conference Bill Gates said that the SharePoint business has now surpassed $1B in sales and 100M licenses sold. While I believe those numbers are overstated (Michael Sampson does a good job of explaining the difference between sold seats and bundled licenses and a platform play), my own ongoing conversations with our clients confirms great interest in SharePoint, even among those who are already dedicated to other platforms.  Why such interest?  Is it, as Mr. Gates says, "the result of the great combination of collaboration and information management capabilities it delivers"?

I've been digging a bit deeper into why people at these clients are so interested in SharePoint.  Mr. Gates is partially right, as many users I talked to like its Office integration and quick improvement over shared drives and emailing files around.  Still, I find it interesting how many of them already have products in house that do what they want Sharepoint to do.  This includes collaboration products like Lotus Notes or eRoom, content management products like EMC Documentum or Interwoven TeamSite, or portal products like IBM WebSphere Portal Server or BEA Aqualogic Interaction.  So why do they still want SharePoint?

The general answer these clients give me is that the products they currently use are overly complex (often limiting the departments that can use them to those with budgets for IT support) or so expensive to license that only users with high levels of need get access and training for them.

To a certain extent, the excitement about SharePoint has really been a reflection of disillusionment with existing collaboration, content management, and portal products.  The people that are interested in SharePoint - despite already having incumbent alternatives - see at first glance a product that may finally provide easy-to-use, inexpensive, web-based collaborative solutions.  But that doesn't guarantee they won't be just as disillusioned with SharePoint once they get into it.  SharePoint is still new and it will take another year or more before we start collecting enough data points on enterprise-class installations to tell if SharePoint is the real deal.  "The grass is always greener on the other side of the fence", and there are often more consultants, developers, support staff, and 3rd party add-on vendors grazing on the SharePoint side of the fence than expected. 

Lotusphere 2008 - Impressions From a Portal Guy

Blogger: Craig Roth

I'm back from Lotusphere and Orlando now and playing reggae to try to trick my brain into forgetting it's -1 degrees here in Chicago.  It's not working.  I posted a set of blow-by-blow notes from the sessions I attended in my personal KnowledgeForward blog (see Day 1, Day 2, and Day 3) but thought I'd post a summary of my impressions here.  My impressions are also based on some good closed door sessions with a number of IBM executives including Larry Bowden and Mike Rhodin.  That picture was then filtered through my portal-tinted lens to result in my view of where I see IBM doing well and neutral (there weren't any big failures in my view) based on the announcements at Lotusphere 2008.

 

I blogged before Lotusphere that I was looking for 2 things.  So how did they do on those?

1. Does IBM have an aggressive compete strategy against Microsoft SharePoint for Quickr and Connections? 

Answer: no.  They have very competitive products, especially in social software (where Microsoft is hobbled without Knowledge Network) and unified communications (where they beat Microsoft to the punch by over a year).  But there isn't an actual compete strategy on collaboration and portal.  I would consider a compete strategy to consist of technology (discovery and migration tools), sales programs (sales training with well-defined messages and materials, competitive package pricing, compensation incentives), and marketing programs (direct messaging to CIOs and architects).  I think SharePoint has huge momentum at the moment and IBM has the capability to compete if it wanted to.  The impression I got from IBM was that while nothing can be ruled out in the future, right now the most winnable areas are in social software and UC.  I agree, but I would like to see Microsoft get more of a fight as I think this kind of competition would benefit users of IBM and Microsoft collaboration products.  But, would IBM have a very good chance of winning the kind of battle I'm proposing at this time?  It's a gamble and the better odds of a payoff are with social software and UC.

 

2. How is WebSphere Portal adapting to the morphing of the portal market into composite applications? 

I like what is being done with WPS to adapt it more to a composite applications mindset and enhance its purpose-built functionality through the accelerators (7 or 8 accelerators depending on how you count them).  I was a bit surprised that the mashup tool was given different branding though, being "Lotus Mashups" rather than "WebSphere Mashups".  After talking to Rob Will about the architecture I am convinced that, given the addition of widget consumption to WPS, it's a smooth architectural fit even though the products are under different branding. 

Here are some other points I came away with:

• Despite the attempts to make big splashy announcements, I still feel this was more of an incremental year.  Last year, with Quickr and Connections, was a quantum leap. 
• There is solid movement into areas the market is looking for, such as mashups, SaaS, and appliances.  But those last two are more of an immediate play to business partners than end users, so there's one level of indirection to resolve before the success of those programs can be judged. 
• The Atlantic project is a good step towards SAP integration that may even nudge out what Microsoft can do with SharePoint since much of Duet is about integration with Office productivity tools and only a little bit is about SharePoint portal-like integration.

Microsoft Buys FAST; Last Year It Was BI, This Year It's Search

Blogger: Guy Creese

Microsoft announced today that it was buying Fast Search & Transfer, the Norwegian enterprise search firm, for approximately $1.2 billion. It looks like pretty much a done deal, in that FAST's Board of Directors is recommending the acquisition and the two largest shareholders are on board (per a ZDNet blog post).

FAST went into an operational meltdown last year (see Forbes article), with writedowns, layoffs, and the exiting of many longtime U.S.-based employees. This probably helped decrease the purchase price, and Microsoft seized the moment. While the operational wheels fell off, the FAST technology is strong at its core.

That FAST would be acquired is not surprising; Bjorn Olstad, the CTO, commented in a meeting I was at last year that the infrastructure players (IBM, Microsoft, Oracle) would increasingly encroach on FAST's space. In short, FAST was well aware of the challenges ahead, and sounded like it was amenable to being acquired. What surprised me was that Microsoft bought FAST; I always thought it would be Oracle, for a variety of reasons.

Last year, we saw the infrastructure players absorb business intelligence (Oracle bought Hyperion, SAP bought Business Objects, IBM bought Cognos); this year it will be search. At this point, Autonomy is the only large best-of-breed player left standing, and it will have a hard time going it alone.

This is a huge coup for Microsoft in the enterprise search space. After futzing around for years, Microsoft finally started to get serious with search in SharePoint 2007. It's not perfect--clients have started to tell me the boundary conditions they're running into--but it's a lot better than search was in SharePoint 2003. If you split the search market into three sectors: (1) cheap and OK, (2) relatively inexpensive and an 80% solution, and (3) expensive and sophisticated, Microsoft is targeting tier two with SharePoint Search. Microsoft Search Server 2008 Express is its answer to tier one (see my previous blog post here), and the FAST acquisition is its answer to tier three.

Strategically, Microsoft now has all the bases covered (and, as a nice side benefit, prevented IBM and Oracle from adding FAST to their arsenal). Now, of course, it has to execute, which is always easier said than done.

If you go down the list of competitors, they're now coming up short:

• Autonomy: Starting to look a bit stranded as the remaining, large, best-of-breed vendor, and strong only in tier three. Great for publishers and specialized niche search, but too expensive for general deployment.
• Oracle: Has a solid tier two offering with Secure Enterprise Search, but nothing for tiers one and three.
• IBM: A lot of strong technology, but oriented more for integrators (think IBM Global Services) than for an off-the-shelf purchase. It doesn't help that there are internal organizational walls to overcome. Search falls within the Information Management division at IBM, while collaboration is controlled by the IBM Lotus division.
• Google: A strong offering for tier one (Google Search Appliance), but nothing for tiers two and three.

To sum up, Microsoft just became a one-stop shop vendor for enterprise search.

Blogger: Guy Creese

Microsoft announced today that it was buying Fast Search & Transfer, the Norwegian enterprise search firm, for approximately $1.2 billion. It looks like pretty much a done deal, in that FAST's Board of Directors is recommending the acquisition and the two largest shareholders are on board (per a ZDNet blog post).

FAST went into an operational meltdown last year (see Forbes article), with writedowns, layoffs, and the exiting of many longtime U.S.-based employees. This probably helped decrease the purchase price, and Microsoft seized the moment. While the operational wheels fell off, the FAST technology is strong at its core.

That FAST would be acquired is not surprising; Bjorn Olstad, the CTO, commented in a meeting I was at last year that the infrastructure players (IBM, Microsoft, Oracle) would increasingly encroach on FAST's space. In short, FAST was well aware of the challenges ahead, and sounded like it was amenable to being acquired. What surprised me was that Microsoft bought FAST; I always thought it would be Oracle, for a variety of reasons.

Last year, we saw the infrastructure players absorb business intelligence (Oracle bought Hyperion, SAP bought Business Objects, IBM bought Cognos); this year it will be search. At this point, Autonomy is the only large best-of-breed player left standing, and it will have a hard time going it alone.

This is a huge coup for Microsoft in the enterprise search space. After futzing around for years, Microsoft finally started to get serious with search in SharePoint 2007. It's not perfect--clients have started to tell me the boundary conditions they're running into--but it's a lot better than search was in SharePoint 2003. If you split the search market into three sectors: (1) cheap and OK, (2) relatively inexpensive and an 80% solution, and (3) expensive and sophisticated, Microsoft is targeting tier two with SharePoint Search. Microsoft Search Server 2008 Express is its answer to tier one (see my previous blog post here), and the FAST acquisition is its answer to tier three.

Strategically, Microsoft now has all the bases covered (and, as a nice side benefit, prevented IBM and Oracle from adding FAST to their arsenal). Now, of course, it has to execute, which is always easier said than done.

If you go down the list of competitors, they're now coming up short:

• Autonomy: Starting to look a bit stranded as the remaining, large, best-of-breed vendor, and strong only in tier three. Great for publishers and specialized niche search, but too expensive for general deployment.
• Oracle: Has a solid tier two offering with Secure Enterprise Search, but nothing for tiers one and three.
• IBM: A lot of strong technology, but oriented more for integrators (think IBM Global Services) than for an off-the-shelf purchase. It doesn't help that there are internal organizational walls to overcome. Search falls within the Information Management division at IBM, while collaboration is controlled by the IBM Lotus division.
• Google: A strong offering for tier one (Google Search Appliance), but nothing for tiers two and three.

To sum up, Microsoft just became a one-stop shop vendor for enterprise search.