Explorys was a healthcare informatics company in Cleveland, Ohio and was founded in October 2009, and was acquired by IBM in April 2015 to become a founding part of IBM's Watson Health division. When Explorys was acquired, it had dozens of healthcare customers, had ingested many hundreds of data sources, and arguably had the largest clinical repository of data in the United States. In a little over three years, the Explorys business case caved and Watson Health imploded in a very public way in May 2018. This astonishing "first to worst" turn of fate, especially considering the scale and speed of events, is why IBM Watson Health makes an acquisition and portfolio management case worth studying.
IBM Watson Health
IBM had been in healthcare for a long time before Watson Health. IBM Research had long been undertaking various healthcare projects, and the consulting arm(s) of IBM had been performing a variety of custom healthcare projects (typically on-premise deployments) utilizing IBM products. But in general, IBM didn't have much in the way of healthcare applications. IBM would sell you a set of tires, an engine, and a steering wheel, and the consulting hours to put them together, but it couldn't sell you a vehicle. That's what Watson Health was going to address. This was a reasonable and admirable ambition.
The challenges started with the formation of Watson Health. Anyone familiar with acquisitions knows that successfully integrating a single company is hard. What IBM tried with Watson Health was well beyond that. On top of creating the entirely new Watson Health division in April 2015, IBM acquired a collection of healthcare software companies…
… to seed this new division, and then also mixed in several IBM Research healthcare assets. At the formation, most of the actual products and most of the actual customers at the formation of the division were from the acquisitions. Typically acquisitions were undertaken to augment an existing business unit, but in the Watson Health case, the acquisitions were effectively the baseline.
There is a process for acquisitions at IBM called "Blue Washing" (the actual term). All acquisitions are requested/strongly encouraged/mandated to convert as many technical frameworks as possible to IBM products, and this list is long. In concept, this does make some sense to foster standard technical environment and processes across groups.
There were a couple of challenges to this process, however. Firstly, as IBM had trailed in the "big data" era, IBM's technical capabilities weren't generally leading-edge, so in a very real way acquisition companies were being requested to go backwards in more than few product categories. The second challenge was determining the conversion priority itself. Any answer on Blue Wash priority depended upon who was asked, and within IBM there are a lot of people with opinions. Just stack-ranking the priorities of internal IBM stakeholders—irrespective of the priorities of paying customers—was an enormous task, and frequently thankless to boot; for example, Explorys went to the sizable effort of converting to IBM's Hadoop Distribution, only to have IBM subsequently terminate that product right after the conversion.
Complicating this already-complex situation was the fact that the primary consumer-facing cloud service at the time was SoftLayer, itself an IBM acquisition from June 2013—acquired less than two years before the formation of Watson Health. From a technical perspective, SoftLayer was a "cloud," but it wasn't the same class of "cloud-native" offering as AWS, Azure, and GCP for supporting programmable infrastructure-as-a-service, at least at the time. While converting acquisition workloads to an "IBM Cloud" did make sense in a broad corporate sense, acquisitions were being asked to pay the same hosting prices the public was paying, so it didn't make a particularly compelling financial case to pay more than their current hosting capabilities for less functionality.
There is benefit for having technical consistency in a product portfolio. Acquisitions, however, could have kept themselves busy for years solely engaged in swapping out non-IBM technologies for IBM ones (e.g., MySQL for Db2, Kafka for MQ), but at what opportunity cost?
Which brings us to Watson, the namesake of Watson Health, and something that Watson Health was intended to highlight. Watson referred to the AI framework behind the Jeopardy challenge in 2011, which itself was a reference to an early leader of IBM named Thomas Watson Jr. Marketing for Watson was ever-present in the media, but it was never clear to the public exactly what Watson actually was. When attending big data conferences during this period, one could hear major tech companies talk about AI and machine learning projects with a fairly standard vocabulary: unsupervised and supervised learning. Clustering algorithms. Classifiers and regression algorithms. But IBM referred to Watson as Cognitive Computing, a marketing-made term. That approach had contrasting effects: technical people didn't take Watson seriously, and business people took Watson too seriously, causing inflated and unrealistic expectations, and ultimately a number of public project failures.
Complicating matters, IBM tried at the time to tie Watson to a variety of other IBM products, such as only running on IBM hardware, or only being available on the IBM Cloud. Watson was not just confusingly described, but its intelligence was artificially limited. Watson was supposed to be the centerpiece of Watson Health, but acquisitions still running on their existing hosting infrastructure couldn't easily take advantage of Watson—whatever it was—even if they wanted to.
Product & Operational Consistency
The strategic vision of Watson Health was to rebuild every acquisition in the "Watson Health Cloud" on SoftLayer. Although a bold strategy, it was not widely recognized or understood that such a vision would take many, many years to pull off, assuming that the existing customer bases would wait. Watson Health's Offering Management team consequently had not put any priority on evolving and expanding the existing acquisition solutions for the existing customer bases ("Offering Management" is IBM's term for what the software industry generally calls "Product Management"). More than anything else, this mindset would prove fatal to the division, and it was astonishing how fast things fell apart.
From Explorys' acquisition in April 2015, contract terminations started in 2017 as customers slowly became disillusioned when they realized the plans presented by Offering Management were never going to happen, and contract terminations went full-boil in 2018. Watson Health leadership only started caring about acquisition customer losses at this point, and it was far too late to recover.
From a market standpoint, the Explorys point of no-return was not May 2018 (the division implosion) but arguably the beginning of 2017. That is roughly when the healthcare market had figured out that the Explorys product vision not only wasn't significantly evolving, but wasn't going to evolve. The business effectively going off the rails in less than two years is a stark example of how fast fortunes can change. When healthcare analysts KLAS wrote a tepid review of Watson Health in the Fall of 2017, it was the final nail in the coffin, but it didn't really come as a surprise as the signals were there all along for anyone willing to look.
IBM Watson Health imploded in a very public way in the May 2018, just over three years from its inception, and the layoffs were particularly hard on the acquisition companies. There were too many competing priorities and the tension between being a showcase for an endless list of IBM technologies, a portfolio of effective and integrated healthcare solutions, and profitable all at once was too great. Watson Health was a good idea, but was an opportunity missed and mismanaged.
To read more about the history of Explorys and IBM Watson Health, see…
History of Explorys (2009 to 2015): https://themeildeal.blogspot.com/2021/01/the-actual-history-of-explorys-part-1.html
History of Explorys/IBM Watson Health (2015 to 2018): https://themeildeal.blogspot.com/2021/02/the-actual-history-of-explorys-part-2.html
Doug Meil is a software architect in healthcare data management and analytics. He also founded the Cleveland Big Data Meetup in 2010. More of his BLOG@CACM posts can be found at https://www.linkedin.com/pulse/publications-doug-meil
No entries found