Mongoose named “Cool Vendor” by Gartner

Published April 18, 2012 Business , Healthcare , Market perspective Leave a Comment
Tags: , , , ,

Mongoose is named in Gartner’s Cool Vendors in Healthcare Providers Report 2012 for its Medical Search Engine for Patient Data – HealthView.

“Healthcare organizations generate terabytes of data per year. Many have spent millions in an effort to digitize their records, only to find that it is still very difficult to find necessary information and, specifically, to ensure that critical information is not missed or overlooked. Mongoose’s HealthView product is an intelligent medical search engine that can help transform the way patient data can be accessed and used.” (Source: Gartner Cool Vendors in Healthcare Providers 2012)

“The decision to use our specialist expertise to solve major information retrieval issues for customers in the Healthcare sector by developing a new medical search engine for patient data is core to our strategy. Inclusion in the Cool Vendors Report for Healthcare Providers 2012 by Gartner adds strength to this direction,” says Matthew Gittoes, Managing Director of Mongoose. “We will continue to work closely with our clients to improve HealthView and widen our client base beyond the UK as the clinical, cost and research benefits become widely recognised and demand increases.”

Finding relevant patient data

Published April 13, 2012 Healthcare Leave a Comment
Tags: , , ,

Welcome back Ms Jones

Deborah Jones is back to the emergency department of the hospital after being discharged just about a week ago. She has great difficulties  breathing, her face is badly swollen and her eyes are very red. Her sister, Emma, is letting the consultant know that she came last week as she was suffering from severe back pain. After being sent home with a treatment and instructions to rest, she developed a rash which was followed by more and more difficulties in breathing.

To the consultant, this looks like an allergy to the treatment. Emma can’t remember that her sister ever suffered from severe allergies and has always been in good health.

The consultant starts looking at Deborah’s medical notes held in the hospital’s Electronic Document Management System (EDMS), browsing one page at a time in the tests and results section, nothing there. He opens another system which contains patient results relating to operations, nothing there either. He finally resorts to opening Deborah’s paper file that has been fetched from the offsite storage warehouse for  him (partially why Deborah had to wait an extra 30 minutes before being seen by the consultant) and starts browsing the pages. Eventually, after much browsing,  he comes across a test report showing that Deborah was tested for allergies to various agents before a knee operation. She was, at the time, found to be allergic to ibuprofen, one of the components of the tablets she was given as part of the treatment for her back pain.

Why was this piece of information not in the EDMS? As it turns out, this information was in the system but put in the “misc.” category buried amongst other piles of non-categorised or improperly categorised patient information, virtually unavailable to a consultant in the time of a normal consultation.

With very limited search capabilities and incomplete integration of the various systems holding patient data in the hospital, the portal is an inadequate tool for clinical staff to quickly and precisely find patient information. Unfortunately, unlike in most businesses, in healthcare, every little nugget of information, even a simple line on a report, can be critical for a treatment.

The cost of not finding information

Re-admissions cost an enormous amount of money to healthcare providers and the situation has been particularly stressed in the UK by recent inquiries. Cases like Deborah’s that could be easily avoided come to inflate an already high number of readmissions.

Deborah’s readmission would probably have not happened if the clinician who gave her the initial treatment could have found all the relevant information about the patient. But the problem of information findability that lead to Deborah’s readmission causes a stream other issues in healthcare organisations. The correct information not being quickly available at the clinicians fingertips leads to:

- Longer preparation time before consultations

It is very common for healthcare organisations to have staff preparing medical notes for consultants ahead of consultations. The purpose of this work is to fetch the patient file and organise the notes and/or highlight any useful or unusual information ahead of time. Medical notes preparation can sometime take 25 minutes or more and is designed purely to make information available quicker to the consultant.

- Less time spent consulting and more time spent looking for information

If you have been to a consultation at a hospital or at a clinic, you have probably noticed that your clinician typically spends a fair amount of time clicking around clunky interfaces of various systems when they need to find extra information about you. All this time could instead be dedicated to the other task part of the consultation, be cumulated to allow for more consultations per day or simply enable health professionals to have a less hectic schedule.

- Repetition of tests and treatments

Accident and emergency departments are particularly impacted by this aspect of the problem. When a person comes for a emergency, staff has typically very little time to browse around the various systems of the hospital (or worse, wait for the patient’s paper file to be fetched from the warehouse) to start caring for the patient. They often redo tests (blood tests are a common example) and repeat procedures.

- Conflicting treatments & readmissions

Although conflicting treatments are a less frequent occurrence, several trusts we had the chance to meet about the topic, admit that the issue could be reduced if information was consistently available and easy to find. Readmissions, especially within 30 days of being discharged are a problem. Poor information access at the time of discharge is one of the many causes but can certainly not be neglected.

- High training costs and dissatisfaction of younger staff

Staff training rooms at hospitals are busy with new employees learning how to use the many IT systems in place, most of them very complex, designed around the information that they hold and not at all around the user that they serve. Staff spend days in these rooms getting familiar with how to input and find information in the hospital systems. Some users just accept the cumbersome character of these interfaces but others, especially younger staff are getting increasingly frustrated with the complexity, the lack of integration and the lengthy manuals especially as they compare these systems with the websites and applications that use on their free time (some of these actually enable them to perform very complex tasks but always seem intuitive and easy). Younger staff are less and less inclined in learning how to get around these systems on their free time.

- Low adoption of electronic systems

As hospitals rollout EDMS’s, staff often complain that it is easier to find information in the printed paper file than it is to find it in the electronic system. EDMS’s seldom embed decent information retrieval capabilities frustrating clinicians who end up printing everything and relying on the paper records “because it’s just easier”. In addition, interfaces of EDMS’s are generally complex and structured around the content, making them unusable on mobile devices, a support increasingly requested by medical staff (geographically mobile within the hospital and also brining their own devices with them at work). For healthcare organisations, managing paper is a huge cost and a security/confidentiality headache.

When listing these issues, it becomes clear that healthcare organisations need to tackle information findability. However, as the problems are surfacing in multiple areas, it is common for these organisations to focus on the wrong problem and not see the common source of all of this. Some invest in expensive, improved training programmes, some put even more processes in place and others invest great sums of money in trying to make their EDMS or clinical portal mobile friendly…

Going electronic, being electronic

So what has gone wrong? Healthcare organisations have invested significantly in multi-million dollar electronic document management systems to solve issues regarding information access. More often than not, they find out that the holly grail of the EDMS does not quite realise the benefits that they were expecting. The problem of accessing information remains, it is slightly less acute but it has just been displaced to another area. The information is now all there, accessible through the screen but navigating the screen and the multiple systems that hide behind it is difficult and time consuming, sometimes much more than paper. Some librarians will sigh and tell you that it is because the information hasn’t been categorised properly. That is true to a certain extent but how does this compare to the systems available in the outside world that enable you to find exactly what you want in a mountain of information just in a couple of keystrokes and clicks. Most of this information isn’t precisely categorised, still we can find it. How do you enable speedy and intuitive access to that nugget of information on a page of blood test results amongst hundreds of other blood test results themselves amongst thousands of individual documents composing the patient file?

In the most dramatic cases, healthcare organisations invest in a multi-million dollar EDMS and put another  set of millions of dollars together to scan parts or all of their medical records. But all they end up with is a pile of  lightly categorised large TIFF images or PDF’s in a CMS with no ability to search for information held in those files. I still remember when a healthcare organisation in the UK showed us their EDMS and how a clinician would have to browse through hundreds sometimes thousands of scanned pages (in PDF) of a patient file to find the anaesthetic record that they wanted.

Add to that the fact that hospitals have more often than not a variety of systems holding data for various specialties which all have their own specific needs. As EDMS are focused around managing content, integration of data from other live systems is very complex and costly. They are not a great candidate to pick when it comes to provide a view on a patient data held and managed elsewhere, resulting in hospital staff having to go to multiple interfaces to find what they want. It also leads certain silos of information being treated as second class citizens. Unfortunately, in healthcare, every single piece of information about the patient’s health is critical. Every piece of information should be treated as a first class citizen.

So, should hospitals stop deploying EDMS’s? Absolutely not! Healthcare organisations should keep aiming for that vision of a single system holding all (or most) of the patient data in a consistent and well managed manner. They should however acknowledge the fact that search and intuitive information access is a critical component of this strategy.

Lightweight approach, heavyweight impact

In addition to engaging some of their resources in these behemoth projects trying to consolidate all of their data in one place with rules that apply across all specialities and roles, with normalisations and processes, healthcare organisations could look at adopting a lightweight approach centred around providing end user with simple and easy access to information on PC and mobile devices without requiring training.

A search based application designed to enhance and complement any existing medical records systems, would allow efficient indexing of all types of scanned content (TIFF, PDF…) as well as other patient information (structured or not) held in multiple hospital systems and across multiple sites.

To ensure adoption amongst all staff members including the ones used to browsing patient files with separators, categories and form types, the application should use a combination of proven methods adapted to patient care to categorise documents. Naturally, it would organise and consolidate all records held on an individual patient for searching and viewing through a single, secure web-based access point, fixed or mobile, integrated in the clinical portal or standalone for other application types.

To help healthcare organisations solving this data access problem, Mongoose Search has designed HealthView, a medical search engine for patient information. HealthView rapidly and easily unlocks a the wealth of valuable information currently held in healthcare organisations making it searchable and viewable in a way never before achieved.

“The true value of HealthView is its ability to unlock hard to find data, add richness to the clinical record and thus realise the full potential of electronic records.”

Paul Curley / Clinical Director of Information Technology and Consultant Surgeon / Mid Yorkshire NHS Trust

–

Find more about HealthView: http://www.mongoosesearch.com/healthview

–

By Aurélien Dubot – Aurelien.Dubot@mongoosesearch.com

Good search can save lives… and money

Published February 10, 2012 Healthcare 1 Comment
Tags: , , , ,

The following post is inspired from a real event, a situation that I experienced in December 2011. Disclaimer: having been working in search / information retrieval for several years, it may very well be that I am seeing areas of improvement where it’s not necessary.

Staring with the story

In December 2011, a lady called our office as she was trying to get in touch with the NHS service. Despite being told by my colleagues that she had dialled the wrong number, she persisted. I decided to take a different approach as she would not stop calling the office. She was an elderly lady (by the sound of her voice) feeling vulnerable, isolated and obviously very confused. She seemed to have significant problems though. Her memory wasn’t too good as it took her a lot of time to remember her address (but no post code). She could only remember a part of her phone number. She could however clearly remember that she had recently been to the local hospital for an operation on her right leg and hip. She could not remember the hospital name. She now felt paralysed from the left leg and could not move from her bed. With her name and those details in hand I reassured her that I would get some assistance sent at her home as soon as possible.

I then called the local emergency service and started a process that, I think, can do with a great deal of improvement. After going through the long list of questions about me (even though I repeatedly mentioned that the help wasn’t for me), we got to Mrs Walters’ case.

I first gave the name of the patient: Alice Walters, easy. But things started getting wrong when we came to Mrs Walters’ address.

Beginning with the town. I told the operator that she lived in “Chesington”. The operator had the regret to inform me that there was no “Chesington” in the UK and asked me if I was sure of the spelling. Obviously I wasn’t, I thought that I heard “Chesington” but I could be spelt somewhat differently from what I imagined. This was a big hurdle for the operator who could not do anything without the exact name of the town. So I opened up a web browser, did a web search for “Chesington” and found out immediately that there was no “Chesington” in the UK but there was definitely a “Chessington” (all of that learnt in just a couple of seconds). I then told the operator that it was Chessington with two ‘s’.

We then moved on to rest of the address: street name and number. For the street name, we faced the exact same problem as for the town. “16 Angers Close” I said. There was no “Angers Close” in Chessington in the system according to the operator. I kept thinking: “Computer says no”.  So I immediately searched online and found out that it was “Angus Close”, again, in a matter of seconds.

Then, the operator needed the phone number. I knew I was in trouble. Mrs Walters called us with a hidden number and could only remember 7 digits. Coming from France where the regional prefixes for phone numbers have been introduced when I was a teenager, I remembered that a lot of old people I knew in France never managed to get their heads around the prefix and would constantly forget it. I quickly asked my colleagues around me if the UK went through a similar transition. The answer was yes. It was then very likely that Mrs Walters wasn’t able to remember the prefix. So I asked the operator if she could find out what the phone prefix (first 4 digits) for Chessington were. That was totally out of scope for the tools she was using. It sounded like it would have been easier to ask for a unicorn. Again, doing a simple white pages search for people in Chessington I found out that it was almost 100% sure that the prefix was 0208.

Then we moved on to more details about Mrs Walters, specifically medical details. I had only superficial information (how she currently felt, how I thought she was) but when the operator asked me about her known allergies and current treatments I had absolutely no answer. This was not an issue but obviously would have made life easier for the staff going to Mrs Walters’ house. This is partially my fault indeed, I should have asked, I wasn’t in GP mode when handling Mrs Walters’ call. To be transparent, I rarely am. But I couldn’t help thinking “How would I know? I’m not her GP! Surely her doctor at the hospital or her GP knows that. It must be in her patient file at her hospital, why can’t the operator find it?”

We finished the call and the operator ensured me that a unit would be on its way shortly. I called the 0208-7 digits number a few minutes later and indeed, the NHS had immediately got in touch with Mrs Walters and a unit was on its way.

I gave Mrs Walters a courtesy call in January. She is now doing better and receives scheduled visits from a nurse.

What could have gone better?

A prompt reader could reach the conclusion that the operator wasn’t too helpful. That wasn’t the case. She was actually being very helpful and supportive. She just was simply ill-equipped. Her tools did not enable her to smoothly handle that particular process and handle partial or approximate information. There was a good amount of knowledge in the systems she was using, helping her to be knowledgeable. But these systems are not geared towards making her knowledge-able.

For the address, she obviously had access to a database of addresses of some sort. But the tool she was accessing did not allow for approximate searches or spelling suggestions. That is typically the case for database or content driven applications. Had she had access to an application using search, she would have found the right address effortlessly. Note that this application could be built on an index of the database of addresses that operators have already access to. There is no need to provide them access to Bing, Google or StreetMap (organisations are sometime reluctant to provide access to Internet services, especially when they do not have control over them).

For the prefix of phone number, this would also have been a straightforward issue to resolve if the operator was able to search for patients in the Chessington area and see their phone number. Unfortunately, the operator’s system is probably very call-centric, handling one action, one call and based on the assumption that the right and complete information will be provided.

For the patient’s conditions and current treatments, this could have been found, in an ideal world, quite effortlessly too. Mrs Walters had been to a hospital, in or near Chessington and her patient file would be there, containing all the useful information. If the operator had access to a system providing federated search across NHS Trusts’ patient information, she could have found what she required. Of course there would be confidentiality considerations and the operators should only be allowed to access a restricted set of information with that set being big enough to be useful. But after all, if we trust certain health professionals with parts of our information, can’t we trust certain staff from the emergency service with some of it too? Note that this is in an ideal world. Most NHS Trusts today have great challenges finding patient information for their own health professionals. A fair number have engaged in buying or building an EPR in the great hope that it would be the silver bullet that would solve their information hell but later realise that it isn’t always delivering what it promised. They still face issues with finding information that is held in legacy or specialised departmental sources, with scanned patient case notes (which end up as large images where the text is not searchable), with incompatible formats… the list goes on. So as NHS trusts are struggling with finding information for their own staff, giving access to that information to other health professionals and NHS services is much too often a distant afterthought. But such information access capabilities would have made the operator’s and the unit’s task a lot easier and more efficient.

What’s the big deal? Mrs Walters is doing fine now.

At the end of the day, Mrs Walters is doing fine, despite the hiccups. And this situation was quite particular. But there is definitely room for improvement.

I reckon that we spent between 5 to 7 minutes on questions that could have been answered instantaneously if the operator had the adequate tools to work with. 7 minutes didn’t mean much in Mrs Walters’ case with her paralysed leg. But had she had something more serious (like a really deep cut and losing a lot of blood for instance), these minutes would have been precious and could have meant the difference between life and death. This is a bit of an extreme case but it is worth considering. Another way to look at it is to consider who was waiting on the line while my operator was taking these extra seven minutes.

If the reader is not too concerned about human lives, another element to take into consideration is cost of handling the call. Let’s take the assumption that the operator handles say 30 calls per day, each call being 12 minutes on average. (I could be completely off so that’s just an assumption). If the operator could save 3 minutes on 10% of the calls, that’s already 9 minutes a day, roughly 36 hours a year. If you have, say, 300 employees handling the calls, 10800 hours of calls or 6 FTE. The 10800 hours of call don’t probably mean much for the NHS emergency service as it doesn’t make money out of the calls (the NHS is more likely to look at the costs or how they could use the 6 FTE somewhere at another position) but for a business that would make money out of these calls (service offers) or use this time to retain customers (commercial customer service), this certainly means a lot more.

So whether you are a philanthropist or not, it is worth looking at these simple improvements to your service centre.

By Aurélien Dubot – Aurelien.Dubot@mongoosesearch.com

What is Santa using?

Published December 22, 2011 Christmas posts Leave a Comment
Tags: , , ,

Here comes Christmas, the most festive season of the year. Everyone is looking forward to sharing happy moments with their friends and families, delicious food and exciting presents.

However, someone is not having such a relaxing time. One person is responsible for delivering billions of presents, all in one night, all of them at midnight and in different time zones, one after the other. This sounds like a daunting task. In modern times, one would think that Santa is leveraging technology, especially software, to be able to complete it.

The core of Santa’s job is to match presents with people. One might then think that this would heavily involve search. But if Santa was using technology, what would he be looking at?

Wishes gathering and pre-processing

First comes gathering the wish lists. Long gone are the days when Santa was only receiving hand written letters. Now wish lists come through letters, emails, text messages and phone calls. To gain efficiency, the first step is turning all of this information into an electronic format that can be exploited.

For letters, it would be ICR and OCR but not only that. Some letters will contain images and for these it will be necessary to try to match those images with Santa’s catalogue to find exactly what object the image refers to. So Santa’s platform must be able to do excellent image matching.

For phone calls, there is a need to be able to do speech-to-text. Although Santa takes the time to talk to every child, it is unlikely that he has the time to type as well considering the volume of calls. This speech to text capability has to be very good and in multiple languages (well, all languages really).

For text messages, at first it would seem that this is an easy source to process but not quite. The system will need to be able to decrypt the shorthand language of text messaging. Imagine receiving the following wish list:

“dEr *<|:o)>, 4 xmas, Id lk d car of Batman n a P-( suit. Thank u.”

You would probably be able to make out that a batmobile is desired but without text message processing, you would certainly miss the pirate suit!

Wishes processing and normalisation

Once all this data is ready and stored, Santa needs to be able to able to (duplicate) process it and that’s a non-negligible task. Normalisation and spell checking would be the first steps. There will also be cases slightly on the edge where spell checking after normalisation will still not enable Santa to identify the gifts for sure. He will need to use fuzzy matching and techniques like N-GRAM whilst processing incoming wishes.

The work however does not stop there. Santa receives wish lists through multiple channels. It is likely that overzealous children issue their wish lists through multiple channels just in case one was to fail. It is also likely that parents and grandparents who don’t coordinate their efforts too well will end up duplicating demands. Santa needs to be able to do exact and near duplicate detection in order to make sure that gifts are not issued twice or more.

Data relationships

Issuing a list to Santa isn’t a guarantee that you will receive the presents that you wish for. One of the key elements to take into consideration is: have you been nice or naughty this year? Do you deserve this present?

To achieve that, one would assume that Santa has a repository of all the things that we have done during the calendar year. That data would have to be indexed and analysed using advanced linguistics with sentiment weight in order to detect and score naughty or nice actions. The scores would then be aggregated for each individual and weighted against the person’s wish list with a pass or fail threshold.

Once matched against inventory, normalised and validated, the lists will have to be joined with the person’s location at midnight on the 25th. Santa’s platform will have to be able to do cross referencing of data sources at indexing time and support geo location.

In addition to the above, Santa’s platform needs to be able to constantly support wish list updates up until the 24/12 at 23:59:59.

Delivery

The big night. Santa has to do billions of deliveries within the space of 24 hours all over the globe. No room for error, it has to be quick and efficient. The easiest way would certainly be to proceed per location.  A simple query like “Berowra Australia” should provide Santa with not only the list of children in this area but also their exact (x,y) location, the easiest way to get through their chimney and related local information relevant to the delivery such as territorial wallabies in the garden and deadly spiders hiding in chimneys. Delivery information has to be up to date and accurate but without compromising on performance. This information needs to be aggregated and presented in a way that enables Santa to make a decision without having to scroll through long lists of results.

In addition, Santa would benefit from having the ability to bucket deliveries according to similarities of delivery method (find similar).

A lot of presents to deliver in a short period of time.

After the big day

The work, unfortunately, does not stop on Christmas day. Santa’s customer service remains extremely busy for the two to three following weeks due to parents not always channelling the right request or simply because the delivered item is not exactly what it looked like on paper.

This requires Santa to have a very efficient call centre capable of handling huge volumes of calls. Using speech to text, sentiment analysis (how upset is the caller) and good matching techniques, the caller’s data can be retrieved quickly and efficiently and his/her request processed in the best possible way.

In addition, Santa is likely to be running analytics on his operations once everything settles. He will be using some of the metrics (structured data) he owns but also some unstructured information coming from social networks to understand the perception and satisfaction on this year’s Christmas and drill down into the specifics of the why. This will require having the capability to analyse the data across multiple dimensions on both structured and unstructured data.

The scale challenge

The above problem seems to be complex enough but if you add to it the immense scale and high performance requirements that come along with taking wishes and delivering billions of items within the space of 24 hours you end up with a serious scaling challenge.

Santa has to deal with what is increasingly referred to as “big data” and he has to do so in a very efficient way. His platform must support billions of items of a different nature (wish lists, demographics information, local information, social networks, blogs…), a high volume of queries and a potentially significant number of updates.

In addition, this scale problem is only a seasonal issue. When it is used, Santa’s platform has to be up 100% of the time (not 99.99% – 100%). But most of the year, Santa’s platform is absolutely unused. The rate of growth also means that this particular solution would have to be able to scale automatically and generates new nodes as stress on the platform increases.

As a result it would be ideal for Santa to benefit from just in time capacity and infrastructure instead of having to invest immensely in hardware  and software capacity upfront. A cloud based solution would be ideal.  And a public cloud as opposed to a private cloud would certainly make sense in this case. This consideration then adds a constraint on Santa’s core platform which would have to be able to run on a public cloud type of infrastructure.

Technology for Christmas

So, if we just focus on the search aspects (which by the way would only be one of the many technologies used), Santa’s search platform would need to be able to do the following:

OCR and ICR, speech to text, text message linguistics processing, fuzzy matching, N-GRAM matching, exact duplicate and near duplicate detection, sentiment analysis, preserve data relationships in the index, geo search,  provide decision support, find similar, related content, search based BI…

And it would need to be designed for the cloud or at least be able to run smoothly in the cloud to provide just in time capacity to Santa and minimise infrastructure costs.

Although all of these features are currently in use at various companies, the combination of all of them plus the need for 100% precision and 100% recall combined with dire performance and uptime requirements (100% & 100%) make it magical.

Those who don’t believe in magic will tell you that Santa is not actually using technology but  the most advanced and large form of human computing on this planet involving hundreds of millions of adults to operate and deliver. Even that, in itself is magical.

So, not matter how you look at it, Santa is using magic and that’s exactly how Christmas should be.

Merry Christmas.

By Aurélien Dubot – Aurelien.Dubot@mongoosesearch.com

Acquisition – the elephant in the meeting room

Published November 9, 2011 Business , Market perspective 3 Comments
Tags: , , , , , ,

** Any views, opinions or recommendations expressed in this Weblog are the author’s and do not necessarily represent those of Mongoose IT Ltd or any of its subsidiaries. **

The past 3 years have seen significant consolidation in the enterprise search market. Traditionally led by smaller players, the top of this space is likely to be led from January 2012 by very large software and services companies.

These acquisitions have had a major impact on the market, to the point where certain analyst firms stopped releasing absolute ranking of search vendors. These have also created uncertainties for customers and prospects who naturally feel vulnerable to those changes.

Souvenirs

This is not the first time the enterprise search market has seen acquisitions. In 2006, Autonomy acquired Verity (at the time the largest player in the market) and in 2007, FAST Search acquired Convera RetrievalWare. But unlike these 2 acquisitions, the purchase of FAST, Exalead, Autonomy and soon Endeca are likely to have a much better outcome for customers, for prospects and for the technology.

The Verity and RetrievalWare acquisitions were nothing more than purchase of market share. In both cases the technology became extinct, customers were politely told to adopt a completely different product and the staff were let go or had their lives made so uninteresting that they went on their own.

The glass is half full

The FAST, Exalead, Autonomy and Endeca acquisitions are the result of genuine interest from much bigger software or services houses who  have in some cases been trying to go after this market unsuccessfully for years.

In this instance, the buyer is very likely to seek guidance from – and listen to – their new colleagues, as well as invest in the technology. Obviously, it will not prevent them from keeping their own agenda, but at least this agenda will incorporate points defined by the company acquired.

The Autonomy case is too recent, the Endeca deal is not sealed yet but in the cases of both Dassault/Exalead and Microsoft/FAST, the parent has been increasing investment in R&D and making significant efforts to stabilise the products to the delight of the customers.

FAST has initially been made one of the core workloads of Microsoft’s key business product – SharePoint – and if existing customers and partners listen to their trustful contacts, they will learn that the next version of Microsoft search will go beyond SharePoint, also exist as a standalone offering and make it to other Microsoft products.

Within Dassault, Exalead has kept on innovating, acquiring new customers with an ever stronger technology stack, covering brilliantly unexpected use cases. With its customers, Exalead focuses now on high value search applications, away from the traditional “I want a search box” project.

Autonomy IDOL is likely to benefit even more from its acquisition by HP. Recognised for a long time as the poor man of R&D investment by both analysts and existing customers (LinkedIn & analyst blogs), IDOL will probably finally see R&D investment and may get some of the management interfaces and front-end frameworks that the other 3 have had for years now.

And finally, Endeca is likely to be a cornerstone in Oracle’s strategy. Unlike the previous 3, it is easy even for the untrained eye to see the alignment of Endeca and Oracle. For Internet business, Oracle has over the years invested in acquiring top of the league web CMSs and e-Commerce technologies which Endeca complements very well, possessing not only a search platform but also a key set of tools used at some of the top media and most top e-commerce companies.
Oracle has, for as long as I can remember, been into “big data” but more in the business of storing big data and less so in retrieving it efficiently and intuitively. Endeca on the other hand has been showing promising investments in retrieval and analysis of big data.

Noise has a loudspeaker

The reader might ask “if everything is so positive, why is the feeling on the blogs and in professional communities so negative?” There are multiple reasons for that.

The first one is that other vendors, as well as consultancies working on other technologies, will profusely spread FUD to sell their own software / services / skills. A little bit of research typically separates the truth from the myth.

I have seen analysts saying that the Endeca acquisition would push customers to Open Source. I would love to see someone used to Endeca InFront’s ETL tools, Business console, SEO kit and front-end framework switch to Solr. They would probably end up at the psychiatric hospital after 2 weeks. A simple investigation highlights the gap.

The second one is that acquisitions do not happen overnight and tend to significantly slow the acquired companies in their plans. For customers it creates an uncomfortable period where everything seems to be up in the air. It is down to the acquiring companies to make sure that the message is communicated clearly, that despite a vision for technology alignment, innovation keeps going and that the legal hoops are not also felt by customers and partners. Companies have, so far, done a very average job at this.

Finally, the acquisition of an agile, leading company by a software or services giant has some drawbacks and those feeling it the most are typically the customers and the employees of the company being acquired (I exclude here any in-house legal teams who certainly do not have a good time either). Typically, bigger players come to a market with a very different perspective from the company they acquired. As a result, they often come with an agenda that is different and alignment is required and sometimes painful.
First and foremost, bigger players have other bigger players on their radar and not necessarily the smaller, top of the league ones. This hampers innovation as bigger players aim at stabilising their products to target large scale sales to their existing prospect / customer base. Moreover, the idea of losing a couple of sales because you are not top of the league is less important when your pipeline in 100 times the size of a smaller but more innovative competitor.

In addition, bigger companies typically come with process. And usually one that employees of that small agile company will not welcome kindly. Add to this the usual rationalisation of staff and immediately talent retention becomes an issue. All the more acute when that talent tends to escape to the competition. This on its own can have a huge impact. As an example Microsoft/FAST has had a hard time against Google/Endeca/Exalead/Attivio, not because the technology was poor but because the Microsoft sales people were facing armies of ex-FAST employees who knew the product inside out, including its weaknesses.
The retention of the sales staff is only a minor part of the issue. What customers are really concerned with is the retention of R&D staff (who can be a bit religious sometimes). This inevitably leads to gaps in the technology and roadmap.

Keep calm and carry on (intelligently)

Should companies be concerned about acquisitions?

The answer is slightly different depending on whether you are an existing or prospective customer.

For prospects, the task is a lot easier. Most of the work consists of evaluating your alignment with both the company acquiring the vendor and the technology itself. For instance, in most cases if a company is a Microsoft shop, it makes sense (particularly commercially) to leverage the FAST platform (there are exceptions of course).

Do not believe all the beautiful messages from marketing, as recent history has been showing that is it not uncommon to promise one thing and do another. Thoroughly assess your commitment to companies’ software and services, as well as the risks associated with a potential technology revamp aligned with the acquirer’s vision.

If you don’t feel comfortable, do this exercise yourself – don’t just rely on analysts’ reports. Leverage those of course but hire a consultancy firm which you are confident with to do the work for you. A few thousands of dollars now could save you hundreds of thousands in the very near future.

For existing customers, the problem statement is slightly different.

Customers with a light commitment (small installation) would be in the same position as a prospect but with a lot more insider information. Drastic changes to the technology in big companies don’t happen overnight and as a result any customer probably has 2 years of breathing time. By then, the internal teams would have had time to go through a process of re-evaluation and to summarise the expected costs of change, should this happen.

Customers with a heavy commitment to the technology will be in a very different situation. And those are typically the most unhappy ones if it turns out that the alignment is not there. Large installations mean significant costs of change and re-training which far outweigh the cost of purchasing and installing new software. These customers will however benefit from additional attention from the acquiring company which will try to keep them under its wing for as long as possible even if there is an evident gap. Customers should be aware of that and not sit comfortably waiting for a resolution that will in all evidence never come. It is better to be alone than in bad company. For these highly-committed customers, I would advise to leverage your contacts deep with the organisation that has been acquired to get some accurate insider information and evaluate early with some assistance if necessary if they are likely to be winners or have to change direction.

Autonomy, Endeca, next

The natural question that these acquisitions have left behind is: Who is next?

The technology giants’ interest and investment in the market leaves most (not all) smaller companies struggling for their space in a highly disputed market. Larger companies have a tendency to drive the prices down. As an example, for the public sector, FAST is now about 5% or less of the price it was before the Microsoft acquisition. Add to that the pressure brought by the Google Search Appliance (cheap prices, minimal setup, simplicity) and that leaves little room for manoeuvre for less advanced vendors. From then on, the idea of being acquired will sound interesting to the execs (a lot less so to the staff).

On the other hand, technology giants who are not in this market (I would also include here those who are, but are struggling to get anywhere) are starting to look at it with intensity. Some because they recognise that search is a key workload to have under your wing, others simply because they are growing wary that other big giants have it and they don’t. It wouldn’t be too surprising to see Adobe or SAP complementing their suites. It would also make sense for IBM to do something in that space considering that they have been struggling with search for a while, but they have much bigger fish to fry for the moment on the software front.

The real question is “who is left to be acquired?” considering that the top ones have already been purchased. Attivio and Vivisimo are top choices but whether they would want to be acquired is a totally different matter.

So, in short

Should you be wary of acquisitions?

Not as much as you might read in the blogs and professional communities.

  1. Have a strong roadmap and a firm vision of where YOU want to take your platform.
  2. Separate the marketing advertisements and the FUD from the real information then thoroughly evaluate the directions of both the acquired and the acquirer.
  3. Assess your commitment to the technology stack of the acquiring company.
  4. Start creating your plan B early if you are an existing customer and see that there may be a mismatch. Don’t wait until your version of the product becomes legacy.
  5. Get highly involved with the vendor if you foresee great potential benefits in the acquisition (both existing and prospective customers).
  6. Stay away when there is doubt (prospective customers) – other technologies with less uncertainties attached are a better option.

By Aurélien Dubot – Aurelien.Dubot@mongoosesearch.com

Follow

Get every new post delivered to your Inbox.