It’s one of the most common questions wherever technology is applied in business – do I buy it or build it myself? Machine learning for R&D is no exception. Our latest blog considers some of the questions that might tip the balance.
Maybe you’ve seen how machine learning could help your chemical or materials R&D – perhaps to design and guide experiments or to predict a better formulation. So what do you do next? There’s a lot of AI technology around, much of it now open source or relatively low cost. Why not take some of these tools and get in-house data scientists to build something for you? The alternative is to buy in a commercial tool to do the job. Building it, you might reason, is going to give you more control, be lower cost, make best use of your team, ensure the security of your data, and – best of all – deliver something tailored to your exact needs. Right? Well, maybe. Let’s consider each of these points in turn.
Control. It’s your project, you might think. You’re in charge and you don’t need to bend your requirements or process to fit the pre-defined template of a software vendor. There are two points to consider here. First, maybe it’s worth ceding a little control so that your team doesn’t spend a lot of time reinventing the wheel. Should you dedicate resources to problems someone else has already solved? Second, you might find that you don’t have as much control as you thought. In-house projects often founder because, as requirements or IT standards change, new users arrive, or the original implementation team leaves, it becomes increasingly difficult to maintain and grow the system. It can make more sense for someone else to carry that burden.
Cost. That issue of future-proofing is also a critical one when you come to consider cost. Make sure you’re thinking about the lifetime cost of the project, including future maintenance and adaptation. Of course, developing the system in-house in the first place might also cost more than you think if you truly factor in the opportunity cost of other things your data scientists could be working on.
Making best use of your team. And you shouldn’t just think about the financial cost of using your team in this way, but also whether this is the most effective use of their skills. Are your data scientists best used, for example, building tools or processes to collate, organise, and process data so that it can be fed into a machine model – all tasks that an off-the-shelf solution might take care of? Or would you be better off (and they be more fulfilled) if their time was applied to more value-added activities? And what of the scientists who will actually use any machine learning tools – what will give them a user experience that ensures they are as productive as possible in these tasks, freeing up more time to focus on great chemistry or materials research?
Security. Now this is an issue where you need to consider the use of external tools and partners carefully. Before going outside your organisation, be sure that any partner is experienced in working with organisations that have commercially-sensitive data and can explain to you how that data will be secured if it is exposed to either their IT systems or staff. Such partners should have ISO 27001 certification.
Tailored to your needs. Off-the-shelf solutions won’t necessarily do everything you want to do, especially if you have more advanced requirements. They may not, for example, produce a particular analytic that you value, or be set up to control a particular piece of experimental equipment. But, for all of the reasons discussed above, it will often be the case that buying-in a solution can meet most of your needs for less long-term cost, effort, and distraction. The best approach is usually to analyze your needs carefully, find those that can be met with off-the-shelf solutions, and select solutions that are open and flexible – for example, that have an API which makes it easy to integrate them into with your scripts, tools, and workflows. If you can find a vendor with experience of similar projects to advise you on this process, that’s even better.
Sometimes, the best route is an in-house project. But, in our experience at Intellegens, the tipping point in making this judgement for real R&D teams is rarely positioned such that building it entirely yourself makes sense. Often, buying a well-tested solution is the best approach and, in most other cases, it pays to understand which parts of the process could be serviced in this way and to choose a route that integrates these with in-house capabilities. These are the scenarios that we’ve set ourselves up to support with our consultative Science Team and flexible software architecture.
