Facets for Everyone: SharePoint and Metadata
December 5, 2009
SharePoint 2010 allows controlled term indexing and user-assigned index terms (uncontrolled indexing). You can find part done of a discussion of SharePoint 2010’s metadata support in “Managed Metadata in SharePoint 2010 – A Key ECM”. The method contains a number of different steps. That’s par for SharePoint, a software system designed to keep Microsoft
Certified Professionals busy billing. The more important points emerging from the write up are:
- The facility to make controlled terms part of SharePoint can be useful. I wonder, however, however nested taxonomies can be imported via comma separated files. In my experience, correctly presenting categories and subcategories can be tricky. The sample taxonomy, according to the Web log post, was entered manually, and I will have to run some tests to determine if the CSV approach preserves relationships in the hierarchy of terms.
- The procedure for supporting metadata strikes me as less sophisticated than what is available in commercial solutions and certainly far less robust than the professional tool available from Access Innovations
- The mixing of user assigned terms and controlled terms selected from a list can lead to an indexing mess. Most people work from a small set of terms. Over time, documents are tagged with the limited selection of terms so that the result set is too broad. User selected terms fall prey to a similar problem. Users become habituated to a particular set of index terms. When working under time pressure, terms may be assigned by rote, not as a result of careful thinking about retrieval.
I am not a fan of mixing controlled vocabularies with user assigned terms. Machine indexing has some problems as well. The Microsoft approach, if I understand this write up correctly, is to make any type of term indexing available. That type of promiscuous indexing creates big problems as the corpus grows. How are old terms replaced with more current terms? Not referenced, and this common problem is a deal breaker for some types of enterprise information access. Could this approach be amateurish?
Stephen Arnold, December 5, 2009
Oyez, oyez, African Development Foundation, I was not paid to point out the flaws of indexing without a plan.
.”
SharePoint 2010 and the Four Gigabyte Gotcha
November 9, 2009
The goslings and I have been trying to figure out some of the implications of migrating from an “old” SharePoint to the whizzy new SharePoint 2010. We ran into a four gigabyte barrier and began the all-too-familiar practice of hunting for explanations, work arounds, and explanations. We found “A Couple of Worrying Changes in SP 2010 Products Compared to the v3 Equivalents” interesting. You will want to read this write up from Mindsharp and then check out the comments to write up.
First, there four gigabyte database size limit is still an issue. Mindsharp point out that “the only slightly bright spot is that it was also confirmed that SPD 2010 and SPD 2007 can be run together on the same client machine. So you don’t need two machines just to be able to work with v3 and v4 sites.”
With regards to this point, Mindsharp reported:
That problem area however fades rapidly into insignificance if you are a WSS 3.0 user using Windows Internal Database. As such you have a free database system which unlike the standard SQL Server 2005 Express it is based on does not have a 4GB database size limit. Well it looks as if people who are running this and have exceeded this figure (non-limit!) or about to do so will have serious problems if they want to upgrade their system to SharePoint Foundation 2010. I don’t have any other explanation that in yesterdays massive batch of over twenty KB articles on the “Pre-Upgrade Checker for WSS 3.0 SP2” two of them are about the Windows Internal Database and both of them are about warnings that you get if you exceed 4GB in the size of a database “The large size of a database can prevent it from being upgraded”.
Second, the comment that caught my attention was:
The second one is not a problem
Within reasonable limits, the second issue is not a problem. Take a look at the following article on Technet: http://technet.microsoft.com/en-us/library/ee663471%28office.14%29.aspx. Databases larger than 4GB (again, within reasonable limits) will be migrated to SQL Server Express with Remote Blob Storage during the upgrade process. BLOBs stored on the file system don’t count against the 4GB limit of SQL Express. Mike’s comment: Setting up Remote Blog Storage is probably beyond the possibilities of many people who today install the Basic Installation version of WSS 3.0. (Anyway Search databases still have a 4GB limit as they can’t use RBS). But my main objection is that having moved to an unlimited database size in one version, MS take it away in the next. Providing a workaround for some cases mitigates that very poor and unfair decision but doesn’t imo justify it.
We downloaded the Microsoft documents. Lots to think about when upgrading SharePoint. Great for billing clients too. Simplicity not. Hard database limits are very 1980 in my opinion.
Stephen Arnold, November 9, 2009
No compensation, not even a wink from a Certified Partner. Too busy billing I assume.
SharePoint and Its Origin
October 25, 2009
One of the articles I set aside to review when I was in Beltway Land last week was “Meet the Father of Microsoft Share Point: Jeff Teper”. I have an interest in SharePoint. The US government finds SharePoint a Swiss Army knife of possibilities. Any information that helps me understand where this product’s roots are anchored is of interest to me. The first thing I noticed about the article was the eyes. You can click here and draw your own conclusion. I see in these eyes a certain intensity. Remarkable. The second impact on me hit me when I read:
Bringing the idea for SharePoint to Gates and Ballmer resulted in two different takes from two different high-level Microsoft managers, Teper reminisced. He said Gates asked a lot of questions about the long-term architecture (SQL Server, .Net, etc.) behind what evolved into SharePoint. Gates also asked a lot of usability questions, Teper said. Ballmer, on the other hand, used his classic “I don’t get this” line of questioning to bring SharePoint’s charter into focus. “Ballmer said we need to make it simple, simple, simple,” Teper said. “He wanted to keep the message very simple.” So how did all this talk about simplicity yield a product that even Teper himself acknowledges is quite ambitious and complex? (He called it this week the “ultimate Swiss Army Knife.”)
SharePoint was to be simple. SharePoint consists of six servers and is, in my opinion, more complex that most enterprise applications. I think the story of SharePoint’s origins provides some insight into how large companies permit products to evolve. The focus is not upon better; the focus is upon more. The idea that problems can be ameliorated by adding additional features and functions is the DNA of SharePoint.
The subhead “A Great Success Born from a Great Failure” struck me as ironic. The ZDNet article stated:
With SharePoint 2003, Microsoft replaced the Exchange data store with a SQL one. Microsoft also purchased NCompass Labs during this period, and integrated its web-content-management technology with SharePoint. In 2007, Microsoft morphed SharePoint yet again, this time developing and realigning it to be more of an intranet and Internet focused tool. Microsoft launched the SharePoint Server 2007 release shortly before it made yet another related acquisition: enterprise search vendor FAST Search & Transfer. The upgrade process between the 2003 and 2007 versions was anything but smooth, the Softies acknowledged this week.
I am not sure what the meaning of “success” is. Perhaps it is the revenue, estimated at more than $1 billion out of Microsoft $65 billion in revenue. Okay. Perhaps it is the large number of alleged SharePoint licenses that are in the use. There are, I have heard, 100 million licenses. How many are in use? How many are freebies, bundled with other Microsoft products? Perhaps it is the legions of certified Microsoft professionals who earn a living making SharePoint work? I have heard that SharePoint consulting is a very solid business for some companies.
After reading the article, I think I know more about the zig zag path of SharePoint from its inception to the present day. With CFOs worrying about costs, I wonder if the costs of customizing and scaling SharePoint are a consequence of its DNA or of the nurturing Microsoft has given the product.
And search? What about search? A work in progress because of the complexities perhaps?
Stephen Arnold, October 25, 2009
No, no, another essay for no dough.
Reflections on SharePoint and Search
October 19, 2009
I had an interesting conversation with a librarian at the international library conference in Hammersmith on December 15, 2009. This professional from a central European country asked my views about SharePoint. As I understood her comments, she was in a SharePoint centric environment and found that making small changes to improve information access was difficult, if not impossible.
One reason was her organization’s bureaucratic set up. Her unit was in the same building at the information technology group, but IT reported to one senior manager and her library to another. Another reason was the reluctance of the IT team to make too many changes to SharePoint and its indifference to her legacy library systems. Her challenge was even more difficult because there were multiple legacy systems in the information center. One of these system offered search, and she wanted to have SharePoint make use of the content in that legacy system’s repository. She was not sure which vendors’ search system was in the legacy system, but she thought it was from the “old” Fast Search & Transfer outfit.
The motto of IT and another unit’s management.
Okay, I thought. Fast Search & Transfer, the company Microsoft bought in 2008 and had spent the last 18 months converting into the world class search system for SharePoint. Fast ESP would break through the 50 million document ceiling in SharePoint search and add user experience plus a nifty range of functions.
To make a long story short, she wanted to know, “Will Microsoft and SharePoint support the “old” versions of Fast ESP?” I told her that I recalled reading that Microsoft would stand behind the Fast ESP technology for a decade. She replied, “Really?” Frankly, I do not know if that guarantee extends to OEM instances of the “old” Fast ESP. My hunch is that the problem will fall upon the vendor licensing the Fast ESP engine. But I have learned and suffered from the fact that it is very easy to write marketing collateral and somewhat more difficult to support a system—any system—for a decade. I know mainframe systems that have been around for 30 years, possibly more. But the Linux centric search systems built to index the Web content are a different kettle of Norwegian herring.
My understanding of the trajectory of Fast ESP is that the company took the core of its high speed Web indexing system and reworked it to handle enterprise content. The “old” Fast ESP abandoned the Web search market when the company’s top brass realized that Google’s technology was powering past the Fast technology. Enterprise search became the focus of the company. Over the years, the core of Fast’s Web search system has been “wrapped” and “tweaked” to handle the rigors and quite different requirements of enterprise search. The problem with the approach as I pointed out in the three editions of the Enterprise Search Report I wrote between 2003 and 2006 were:
- Lots of moving parts. My research revealed that a change in a Fast script “here” could produce an unexpected result elsewhere in the system “there”. Not even my wizard son could deal with these discomforting technical killer bees. Chasing down these understandable behaviors took time. With time converted to money, I concluded that lots of moving parts was not a net positive in my enterprise search engagements. Once a system is working, the attitude of the librarian’s IT department is my reaction. Just leave something working alone.
- Performance. Web search required in the late 1990s a certain type of spidering. Today, indexing has become more tricky. Updates are often larger than in the past, so the content processing subsystem has to do more work. Once the index has been updated, other processes can take longer because indexes are bigger or broken into chunks. Speeding up a system is not a simple matter of throwing hardware at the problem. In fact, adding more hardware may not improve performance because the bottleneck may be a consequence of poor engineering decisions made a long time ago or because the hardware was added on but to the wrong subsystem; for example, the production server, not the indexing subsystem.
- Ignorance. Old systems were built by individuals who may no longer be at the company. Today, the loss of the engineers with implicit knowledge of a subsystem make it very difficult—maybe even impossible– to resolve certain functions such as inefficient use of scratch space for index updates. I recall one job we did at a major telco several years ago. The legacy search system was what it was. My team froze it in place and worked with data the legacy system wrote to a file on a more modern server on a fixed schedule. Not perfect, but it was economical and it worked. No one at the company knew how the legacy search system worked. The client did not want to pay my team to figure out the mystery. And I did not want to make assumptions about how long gone engineers cooked their code. Companies that buy some vendors’ search systems may discover that there is a knowledge problem. Engineers often document code in ways that another engineer cannot figure out. So the new owner has to work through the code line by line to find out what is going on. Executives who buy companies make some interesting but often uninformed assumptions; for example, the software we just bought works, is documented, and assembled in a textbook manner. Reality is less tidy than the fantasies of a spreadsheet jockey.
SharePoint and User Adoption
October 11, 2009
I have been working through the SharePoint search related items that Overflight generates. One article “Ideas to Increase End Use Adoption” did not interest me when I first read it. I went back this morning and reviewed the article in SharePoint Buzz because it connected with a remark I heard in a meeting in Arlington, Virginia, last week. The article is straightforward. Some SharePoint features don’t get a quick uptake by users. In order to boost use of a SharePoint system, the author presents a number of ideas. These range from in person training to creating FAQs and other textual information to help users understand the features and functions of a SharePoint system. The article identifies multimedia content as a useful idea. A community-based support service is another good idea.
Now the question, “Why did I return to what is a common sense article about a software system?”
The answer is, “Users resist systems that create more hassles than solved problems.”
The SharePoint blog post underscored three points:
- User ignored systems are a problem, not problem solvers. Maybe training will help resolve this problem, but if users don’t use a system, there’s a deeper issue to resolve. It may be interface. It may be performance. It may be the functions are unrelated to the work task. I don’t know but I know there is a problem.
- Vendors are trying to resolve marketing issues by pushing users in certain directions. When I looked at the list of ways to boost adoption and usage of SharePoint functions, I thought about how some of my grade school teachers approached subjects.
- Microsoft’s new emphasis on UX or the user experience may be a lower cost way to solve deeper issues of a system’s design. The system itself may not deliver a solution, so the easier route is to put some lipstick on the beast and call it a day.
In my opinion, the discussion of user acceptance of certain SharePoint-based applications may point to a deeper and more troubling set of issues within the architecture of SharePoint itself. A developer may like what he or she has built. But users who ignore the service are making clear that something is off base. I am not sure training or an interface can do much if the problem resides within the deeper core of the SharePoint suite.
Stephen Arnold, October 11, 2009
Hiding SharePoint Sins
April 5, 2009
Satan may be in the room, but I just learned I can make him invisible with plumbing. Read Robert Bogue’s “Using Infrastructure to Hide All Sins” here and learn how yourself. The core of the idea is that SharePoint will misbehave; that is, sin. To absolve the software of its misdeeds, the savvy SharePoint wizard will use hardware to hide the problem. Mr. Bogue wrote:
You see, I architected the system to account for a fairly high probability that the developer code would randomly and inexplicitly cause a server to crash, run out of memory, blue screen, or just generally go dark from time-to-time. With that in mind, we put two servers in that should be able to cope with the load from everyone. The third server in the farm was just there to be the token server that was in the process of crashing and coming back. Load balancing can hide almost any server stability sin that you can come up with. Simple Network Load Balancing (NLB) included in Microsoft Windows Server operating systems can hide problems. Tools like F5‘s BigIP can hide them better.
If this approach makes sense to you, then Mr. Bogue’s write up is just what the witch doctor ordered. For my money, I prefer appropriate infrastructure (low cost, reliable, scalable) and solid code. Call me old fashioned but I think at Judgment Day throwing hardware at a SharePoint problem won’t gain admission to digital heaven.
Stephen Arnold, April 5, 2009
Can the Vista Disease Spread to SharePoint
December 1, 2008
Computer World in the UK ran an interesting story “The Outlook for Vista Gets Even Worse” on November 28, 2008. You can read the Glyn Moody’s story here: This is not another bash Vista write up. For me the most important comment is the one below:
…the myth of upgrade inevitability has been destroyed. Companies have realised that they do have a choice – that they can simply say “no”. From there, it’s but a small step to realising that they can also walk away from Windows completely, provided the alternatives offer sufficient data compatibility to make that move realistic.
If Windows Vista changes the rules, what happens when the 100 million SharePoint customers learn about the costs, the performance issues, and the lack of compatibility with other Microsoft products ranging from analytics to CRM? What happens when the push to move SharePoint customers to Fast Search’s Enterprise Search Platform spills a bucket of red ink? If the Computer World story is on track, the same push back could afflict SharePoint. The companies who benefit from this situation will be the search vendors with snap in solutions to information access problems. No happy face painted on the SharePoint system will be easily resolved if the Vista “disease” spreads.
Stephen Arnold, December 1, 2008
SharePoint and Azure
November 1, 2008
The Microsoft cloud computing initiative is underway and it is early days. My principal concern with cloud computing is that it sounds so compelling. Imagine. Reduce your information technology staff. Get out of the hardware business to some extent. Let someone else worry about upgrading software and stamping out bugs.
According to Arpan Shah’s Web log here, Microsoft SharePoint Services will be part of the Azure Services Platform. You can get more information from Microsoft here. Many details are fuzzy. In the weeks and months ahead, more information will be forthcoming. I have heard that sample code, downloadable executables, and documentation will be provided. Microsoft does a good job of providing information. The challenge for me is finding it.
Before leaving the subject of the link up between Azure and SharePoint, let me capture for my own use the issues that I have with cloud computing in general. (I am an addled goose and this Web log is primarily for me, a digital notepad if you will.)
First, it is expensive to build, deploy, scale, and upgrade cloud infrastructure. I am not sure I can quantify the costs any more clearly than I have in my monographs and studies. CFOs and beancounters don’t understand the non linearity of the costs. I suppose this knowledge will become more widely available after a few of the new entrants in cloud computing explain why their balance sheets are awash in red ink.
Second, the problems of bottlenecking, unexpected faults, and the time required to chase down and figure out problems few or maybe no one has seen before increase over time. Cloud infrastructures are tough to lock down. Every time I turn around a vendor was pushing a firmware update, a point upgrade, or some other piece of software at the data centers in which I was involved. When one of these “fixes” is problematic, I had trouble. What few understand is that the longer the cloud infrastructure operates the more likely there will be unexpected dependencies. These data centers are not workstations, yet many people view them as giant iPods. Crazy.
Third, the client experience is gated by bandwidth and latency. The hottest cloud infrastructure is worthless if the user is trying to access email or some other information via a sluggish network. How stable are network connections in Kentucky? Not too stable. Connectivity is much better in the major European cities. Tokyo is outstanding. But when I have had to work from cities with now vowels in their name, life gets tough. Joburg was okay. Djuma was not. Xian featured great connectivity. Other places in China weren’t so hot, so I used Internet cafes and faced with dial up modem speeds. My guide assured me that the cafe was a broadband hook up. Yeah, right.
What to these three points have to do with Azure and SharePoint. Not much because so far Azure strikes me as a suggestive demo. Down the road, Microsoft will have to deal with SharePoint’s own performance and stability plus the three points I just mentioned.
That is going to be a big, costly job for the folks at Microsoft. The goose issues a gentle quack of support.
Stephen Arnold, November 1, 2008
SharePoint: Anyone Not Baffled, Please, Stand Up
August 5, 2008
For years–even before I wrote the first three editions of CMSWatch’s Enterprise Search Report–I have been pointing out that enterprise search in general is not so useful and Microsoft enterprise search in particular is in the bottom quartile of the 300 or so “enterprise search” offerings available.
In a sense, it’s gratifying that youngsters are starting to look at the reality of information in an organizational setting and asking, “What’s wrong with these vendors and their systems?” You can get a dose of the youth movement in what I call search realism here. Shawn Shell, embracing knowledge about enterprise search, identifies some of the wackiness that Microsoft employees routinely offer about enterprise search or what I call “behind the firewall” search. I am pleased with the well-crafted article and its pointing out that Microsoft has a bit of work to do. I find it amazing that four years after the first edition of Enterprise Search Report, that old information is rediscovered and made “new” again.
Even more astounding is the Microsoft news release about the Fast Search & Transfer acquisition, which became official, on August 4, 2008. You can read the full text of this news release, as reported in AMEinfo here. Quoting Patrick Beeharry, Server and Product Marketing Manager for SharePoint in the Middle East and Africa, AMEinfo reported Mr. Beeharry as saying:
‘With our companies combined, we are uniquely positioned to offer customers what they have been telling us they want most – a strategy for meeting everything from their basic to most complex enterprise search needs. We are pleased to have the talented team from FAST joining us here in the Middle East. Together we aim to deliver better technologies that will make enterprise search a ubiquitous tool that is central to how people find and use information.
Okay, Microsoft is offering a strategy. I don’t know if a strategy will address the problems of information access in an organization. Vivisimo’s white paper takes this angle, and I think that the cost issues I raised are fundamental to a strategy, but I may be wrong. Maybe a strategy is going to tame the search monster and the 50 to 75 percent of the users who are annoyed with their existing search and retrieval system.
I suppose I was not surprised to read in To the SharePoint: The SharePoint IT Pro Documentation Team Blog the essay, “Which Microsoft Search Product Is for You?” You must read this stellar essay here. For me, the key point was this table:
You can see the original here if this representation is too small. The point is not to read the table. My point is look at the cells. The table has 35 cells with the symbol Ö and seven cells with no data. In the table’s 54 cells only seven have data. For me, the table is useless, but you may have a mind meld with the SharePoint team and intuitively understand that High availability and load balancing is NULL for Search Server Express and Ö for Search Server 2008 and Office SharePoint Server 2007. How about a key to the NULL cells and the Ö thingy? (For more careless Microsoft Web log antics, click here. The basics of presenting information in tables seems to be a skill that some Microsoft professionals lack.)
Er, what about Fast Search & Transfer? The day this Web log posting appeared, Microsoft officially owned Fast Search, but it seems to me that either the author was not aware of this $1.2 billion deal, had not read the news story referenced above, or conveniently overlooked how Fast Search fits into the Microsoft search solution constellation. I can think of other reasons for the omission, but you don’t need me to tell you that communication seems to be a challenge for some large organizations.
The net net is that Microsoft has many search technologies; for example:
- Powerset
- Fast Search & Transfer (Web indexing and behind the firewall indexing)
- Vista search
- Live.com search
- The SharePoint “flavors”
- SQLServer “search”
- Microsoft Dynamics “search”
- Legacy search in Windows XP, Outlook Express (my heavens), and good old Outlook 2000 to 2007.
The word confusion does not capture the Microsoft search products. Microsoft has moved search into a manifestation of chaos. If I’m correct, licensees need to consider the boundary conditions of these many search systems. Hooking these together and making them stable may be fractal, not a good thing for a licensee wanting to make information accessible to employees. The cost of moving some of these search systems’ functions to the cloud may be resource intensive. I wanted to write impossible, but maybe Microsoft and its earnest Web log writers can achieve this goal? I hope so. Failure only amps the Google electro magnet to pull more customers from Microsoft and into the maw of Googzilla.
I am delighted to be over the hill. When senility finally hits me, I won’t have to struggle through today’s ankle biters making the old new again or describing symptoms, not diagnosing the disease. Don’t agree? Set me straight. Agree? You are too old to be reading Web logs, my friend.
Stephen Arnold, August 5, 2008
SharePoint Placemat
June 28, 2008
Microsoft SharePoint got to know one another several years ago. Via referral, a Microsoft Gold Certified Partner wanted my team and me to run some tests on a SharePoint application. We got everything running, wrote our report, and the Gold Certified Partner was a quick pay.
After the project, one of my colleagues remarked, “SharePoint is really complex.” We put the idea aside until someone emailed us a SharePoint placement. A copy of this remarkable diagram is available if you want to look at it. You can find it in SharePointSearch.com here.
Here is a thumbnail of the full diagram, but I strongly urge you to download the diagram. Do you think it is a joke of some type? My colleagues and I saw something similar from a Microsoft partner in New Zealand a year ago, but this placemat is a triumph of sorts. The company preparing the diagram is Impac Systems Engineering.
The complexity of search in general and SharePoint in particular is an interesting topic. Search can be quite a challenge. One recent example is the inability of Internet Explorer to open a SharePoint document. You can read more here and download a fix here. Embedding search into a content and collaboration system with data management features may push the boundaries of software to their limits.
CleverWorkArounds.com has an essay called “Why Do SharePoint Projects Fail”. You can look at Part 5 here. I was unable to locate the other portions of this discussion, however. (Part 3 is here.) For me, there are three main points that address the issue of the almost-funny placemat diagram:
- The skills required to implement SharePoint include “IIS, Windows Server, TCP/IP & networks, SQL Server 2005 Advanced Administration, Firewalls, Proxies, Active Directory, Authentication, Security, IT Infrastructure Design, Hardware, Performance Monitoring, Capacity Planning, Workflow, IE, Firefox, Office Client tools, ASP.NET, HTML, JavaScript, AJAX, XSL, XSLT, Exchange/SMTP, Clustering, NLB, SANs, Backup Solutions, Single Sign on, Monitoring & Troubleshooting, Global Deployments, Dev, Test, Staging, Production – Staged deployments, ITIL, Vitalization.”
- “SharePoint is complex and the products it relies on are also complex. In the wrong infrastructure/architect hands, this can cause costly problems.”
- “… if there is not a certain degree of discipline around change management, configuration management, procedures, standards and guidelines to administrators, users, site owners and developers, bad things will happen.”
These points underscore the problem with “boil the ocean” systems. The fire needed to get water sufficiently hot to cook eggs can consume the pot, leading to a big mess.
Observations
I took another look at the placemat diagram and re read Part 3 and Part 5 of the essay “Why Do SharePoint Projects Fail?” Let me offer several observations from my dirt floor cabin in the hills of rural Kentucky:
First, SharePoint is a beast. Enterprise search is a monster. What will the progeny of these two behemoths be like? My opinion is that it will be tough to see through the red ink flooding some SharePoint projects. Toss in a hugely complex system such as Fast Search & Transfer’s Enterprise Search Platform, and you have a very interesting challenge to resolve.
Second, complexity is a Miracle Grow for consultants. SharePoint is complex, and it will probably only get more complicated. In my experience, Microsoft software becomes efflorescent quickly.
Finally, SharePoint attempts to deliver what may be a system that will be out of step with cloud-based services. SharePoint as a hosted or cloud-based service is generating some buzz. However, will the latency present in most on-premises installations be an issue when delivered as a service? My view is that latency, more than issues of security or data confidentiality, will bog down the SaaS implementation of SharePoint.
SharePoint is hugely successful. I heard that there are more than 65,000 licenses in North America alone. The SharePoint market is a tempting one for companies like Google to consider as one ripe for an alternative.
Stephen Arnold, June 27, 2008
-
- Subscribe to Beyond Search
Feature archive
News archive
-
