Enabling and supporting a large biopharmaceutical R&D organization is never easy and probably never will be. You’re doing specialized research across many domains with people who are intensely curious and intelligent — and sometimes demanding.
Fielding the platforms that researchers want to use has never been easy, but now there’s a new urgency: improved IP protection. Not surprisingly, a researcher who can’t find what they need in one place will go to another, usually outside the company firewall. This creates an easily discernible trail that can help competitors determine what you’re working on.
The issue appears to be getting some attention — and some funding. If you happen to be involved in making IT decisions for a decent-sized pharma R&D organization, you might find this interesting.
Many R&D organizations have focused on surfacing specialized platforms that cover different aspects of R&D research requirements: valuable resources like external public documents (publications, patents, etc), alongside internal documents like historical clinical trial documents.
It’s fair to say that this multi-platform approach often foisted complexity on researchers. It’s also fair to say that people adapt and learn to work with what they have. But now there’s a new, urgent priority: lessening the incentive for external searches over the open internet.
It is now quite easy to sniff originating search traffic and discover intent. I’m a marketing guy, and I’ve done this repeatedly. It is not hard to learn that person X who works for Y has an IP address Z searching on specific topics, and I can easily learn what they’re interested in. It’s a bit harder if you’re behind a corporate firewall, but not all that much harder.
The search providers see this as a source of revenue, as one would expect.
This has created a wonderful R&D incentive to bring as much data as possible behind the firewall, and thus won’t reveal search intent externally. Frequently, there are external funds that can be made available for this purpose, which is always helpful.
As we’re solving that immediate concern, there is also an opportunity to modernize and be more effective. Integrated search and discovery will always win over puddles of knowledge.
As long as we’re being honest with each other, those backend legacy systems you’ve been using might have been the right answer at the time, but they’re looking awfully dated now, especially through modern eyes. It’d be nice to get rid of a bunch of those as well, freeing resources for what the business needs now. Call it application modernization.
Here’s what I like about this — it reminds me of the Y2K scenario in some regards: a new, external threat forces modernization of an application landscape that really needed it anyway.
Well, let’s start with the obvious: you’re going to want a unified platform of some kind. Trying to integrate a bunch of stuff is what got you here in the first place, so let’s not do that again.
That platform will have to ingest data from any source and make it immediately usable to all. You should be able to apply just about any dictionary, ontology, model, etc. to whatever data is there and do so at the time you need it. It should be easy — and safe — for researchers to model their search and discovery any way they see fit.
At the same time, there’s a long list of non-negotiables: security, provenance, audit, compliance, etc. so it’d be great if there were good answers for all of that.
The right platform can solve a lot of problems at the same time, which makes the initiative more achievable.
Let’s use a “top ten” Pharma R&D function as an illustrative example. The details may vary, but I’d offer the pattern looks the same.
Not surprisingly, they had drug candidate information in six different repositories, organized loosely around the pipeline stage. The data itself was inherently complex: XML docs, JSON docs, RDF triples to connect it, and so on.
Again, not surprisingly, things were represented differently depending on which part of the landscape we happened to be visiting: codes, names — each was its own semantic world. The internal situation was already complex for the researchers, and now the mission was to ingest a lot of external sources.
The topic of a new platform came up.
As MarkLogic, we recognized the complex data integration problem that was unique to Pharma R&D, and showed them what we had done elsewhere. As MarkLogic is built on a metadata-centric engine, we have a different way of addressing the problem as compared to other approaches.
Their initial goal was to help the researchers. This took the form of a unified metadata layer that abstracts and interprets what’s in the underlying systems. The idea was to help researchers decide quickly whether something was relevant (or not) prior to entering the source system domain.
At the same time, the platform is fully capable of being the system of record vs. the system of advice, so — over time — legacy platforms can be retired, and fully integrated into the new platform — with or without changing the underlying semantics.
Agility becomes very important here.
The first implementation was one internal source combined with one external source to prove the concept. The researchers liked what they saw, and started coming up with all sorts of other things they’d like to see, and — voila — it wasn’t long before they saw the results — and now had a bunch of new ideas.
And there were other researchers with ideas as well. The crowd grew. The system of advisement quickly became the system of engagement. Very transformative, when you look at it that way.
The benefit of this platform approach could be quantified any number of ways: reduced IP leakage, better researcher productivity and engagement, reduced costs associated with legacy systems, less knowledge worker turnover, faster ramps for new talent, and so on. Choose your favorite.
Something I learned a while back was to never allow a good crisis to go to waste. A decent, non-life-threatening crisis can force change where it’s needed, and usually for the good. It tends to focus people’s attention — and resources.
If you’d like to learn more, please get in touch.
Chuck joined the MarkLogic team in 2021, coming from Oracle as SVP Portfolio Management. Prior to Oracle, he was at VMware working on virtual storage. Chuck came to VMware after almost 20 years at EMC, working in a variety of field, product, and alliance leadership roles.
Chuck lives in Vero Beach, Florida with his wife and three dogs. He enjoys discussing the big ideas that are shaping the IT industry.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites