When I was younger, my Dad would tell me, “Johnny, you’re better off laying your chips at the casino than opening a restaurant. They fail more than half the time.” If only he had been part of the software generation.

Whether you put your trust in open source blogs, periodicals like Forbes, the academic literature, or this newsletter, we all concur: about half of all internally developed software projects fail. Yet, in the years we have been providing battery intelligence software to startups, Fortune 40 companies, and the government, we have seen many customers consider the build vs. buy question. There are some valid reasons for both sides of the argument. Let’s look at them.

Why Companies Build

We see companies choose to build for two main reasons, one of which has merit: cost savings and intellectual property concerns. There are other reasons such as control over the source code, and to avoid restrictive licensing, but these are less common.

On the cost savings side, a custom built solution is unlikely to save any money and any such effort should be reserved for the most highly strategic systems in the business. The headcount needed to provide the necessary skill sets are often viewed as a “sunk cost” but in reality it can have a huge impact on the productivity of an organization. If you add up the salaries of the database administrators, data scientists, backend, frontend and quality assurance engineers, designers, devops, security and other subject matter experts, and project managers for a typical six month project, it begins to approximate the internal cost to the business, and represents time that these team members could be supporting other more strategic projects. There is of course management, HR, training, IT support and turnover costs on top of that, not to mention ongoing hosting and maintenance costs. These are not small considerations.

Even if the headcount is available for a larger project, the proper skill sets to build a solution such as a battery intelligence software platform need to also be in place. Companies often embark down the path of building their own solution, only to realize too late that they lack the necessary expertise. Such an effort requires a high level of skill in data architecture, data science, continuous integration / continuous deployment, security, statistical analysis, machine learning, and user interface design. But perhaps more importantly, it also requires cutting edge subject matter expertise.

When companies choose building over buying, internal Subject Matter Experts (SME) sometimes cast the deciding vote. They might point out, for example, that they have proprietary algorithms which should remain as secure intellectual property. I believe the IP concern has some merit. Batteries are an area of technology uniformly expected to have high double digit CAGR for years. Not surprisingly, the exploding demand of EVs, consumer devices, grid connected storage and the slower growing but still vast defense application space, has led to an exciting and varied tapestry of technological innovation, some of which is highly proprietary.

Consider some examples from our own portfolio, which represents about 2.2GWh under management. Technologies as established as zinc are being used with nickel in novel power cell configurations and with bromine in flow AND non-flow topologies, often for the first time. Metal-hydrogen, historically used almost exclusively for space applications, has surfaced in EVs and grid storage.  The humble lead-acid battery (an invention of the ante-bellum world) continues to be an area of innovation in its many flavors and applications. In the Li-Ion space, be it anodes with more than carbon, solid electrolytes, conflict-element free cathodes or non-laminated battery manufacture, one thing is clear: if there is an idea, there is a well-funded startup pursuing it. With such highly specific technological pursuits, it’s understandable why companies might build their own battery management system since it’s core to the business, particularly in industries that are regulated. They might, in turn, come to us for help with battery intelligence using data from the BMS.

Some of the other reasons companies may opt to build their own solution relate to ease of integration and expandability. A battery intelligence solution rarely replaces any existing system, but rather is meant to ingest data from existing sources in the business, whether it’s directly from the manufacturing floor or from core MES or ERP systems, battery cyclers, or remote monitoring systems – not to mention edge devices. The ability to easily transfer large amounts of data from these systems into a third party solution can be challenging if it doesn’t already have the proper hooks and industry standard interfaces. Most packaged solutions will expect that you already have all of your data in one place and easily accessible, which is rarely if ever the case. (See our previous issue with a case study on capturing manufacturing assembly data in real time.)

Source

Some companies considering an outside solution are also concerned that they may be buying more than they need. This is particularly true for newer companies that haven’t yet fully established their own systems and processes, or are still building them. For example, if you simply want a good solution for parsing battery test data, do you really need to invest in a full-fledged battery intelligence platform that may contain many other features you’d never use? Third party solutions are often sold as a single product, and they will try to convince you that you need all of the additional features from the start.

Why Companies Buy

Battery researchers, manufacturers, integrators and operators are increasingly buying vendor supplied solutions such as battery intelligence software. The many reasons for this decision tend to be variants of a simple cost benefit analysis. Companies will arrive at a conclusion such as: “Why risk our own internal project failing, when the professional solution has been proven to work for years?” This conclusion is further supported by the acknowledgement that they simply don’t have the in-house skill sets to build a robust solution (which sometimes requires a bit of humility to admit). Let’s look at some of the considerations in more detail.

In many cases, once a software solution is built and launched internally, the business moves on to new initiatives with fresh funding. The solution typically stops receiving updates (unless it’s considered a core system) or even maintenance, and eventually languishes. We’ve seen this happen many times.

With a purchased solution, software providers regularly update their software since they are financially incentivized to do so, based on a constant stream of feedback and usage data from real users across different companies and even industries.

• Professionally designed and easier to use to incentivize adoption. User interface design is often an afterthought for internally designed software, but can negatively impact adoption rates and speed up obsolescence.
• Professionally secured, so your data is safer, and built to scale. Purchased solutions run on modern and robust architectures, and can quickly expand based on increased usage.
• Used by many customers, so has more comprehensive features and fewer bugs. Vendors have the advantage of working with many different customers, and have a better understanding of the range of requirements in a variety of use cases. It’s the difference between a business creating software it thinks it needs vs. what the actual users really need.
• Professionally supported, so flourishes through employee turnover. Companies are increasingly having a hard time filling key software positions. Working with a vendor, this becomes less of a concern.
• Regularly updated, so is more future-proof. Business requirements evolve and change over time organically. A purchased solution can better keep pace with these changes and remain relevant as the business grows.
• Designed with an industry wide-perspective, so is less likely to be a siloed solution. Many businesses operate, sometimes by necessity, in data silos by default. A professional software product should be built to work around these limitations. Businesses often fail to anticipate this challenge, creating a misalignment between the solution they develop and the requirements of the business.
• It already exists so it’s likely to be ultimately less expensive and certainly faster to implement. If there are tangible financial benefits in using the software solution, these can be realized much more quickly than spending the time and resources building and maintaining the software yourself.

The Hybrid Approach – Best of Both Worlds?

A hybrid approach takes most advantage of a purchased solution, while also offering the flexibility of a custom solution. Wide differences in business models, battery technologies and use cases can prevent a “one-size-fits-all” software stack from succeeding. But there are some key capabilities to look for in evaluating solutions to make sure these risks are mitigated. In this case, it’s truly possible to have the best of both worlds.

The first consideration is to look for a solution where functionality can be added as the business needs change and grow. Ideally, you should be able to start with (and only pay for) just the functionality you need, and have the option of adding additional features as your needs evolve. These features are often organized into modules, and priced separately or in usage tiers.

These modules should be able to seamlessly integrate with existing systems, and share data in a single, continuously updated and normalized data repository, preferably separate from the normal business-critical systems running in the business. This is often the most critical step that involves a level of difficulty and expertise that many businesses fail to predict.

Consider two separate Li-ion manufacturers. Company A plans on bringing atypically shaped solid state batteries to market, for highly customized use-cases, with an additive manufacturing approach. Company B plans to develop new powders and then license them to third party manufacturers. Company A needs to track data streams from incoming starting powders, manufacturing equipment, and battery formation data, among others. Company B needs to track a wider array of quality control techniques for their powders and would likely pursue a wider range of sample batteries. The results and analyses of these characterizations would need to be presented on a portal for internal as well as external use. These two Li-ion companies need different software configurations. They would be only partially served by a vendor selling them a single generic module, that perhaps takes battery cycler data from various formats, normalizes it, centralizes it and presents several views of that data. How does that data relate to Company A’s printing process as it evolves? How does that cycler data correlate with Company B’s chemical formulation of, say doped LFP powders? With a hybrid approach, the proper modules — and the proper configuration of those modules — would reveal these relationships.

For our last example consider two grid-scale operators using Li-ion and an alternative technology, for example lead-acid. Both operators wish to report state of health (SoH) on a regular basis perhaps per a requirement of their long-term service agreement or a warranty term.  In the Li-ion case this information often comes from the battery management system (BMS) directly. The BMS records and reports the ratio of the maximum charge the battery can currently maintain (Qmax) to its rated charge (SoH(t)=100% * (Qmax(t) / Qrated). In the case of lead-acid batteries, particularly those that need to be maintained by occasionally adding electrolyte, the SoH metric needs to consider adherence to a maintenance schedule and is not a simple formula. Still other companies choose to report SoH from consideration of the batteries dispatch history. In these cases, data from the BMS system is always captured, but is streamed through different analysis scripts depending on the use case.

Conclusion

Companies which claim that they are different enough from each other, and therefore need different software configurations for battery life-cycle management have a point. The details matter. Vendors that argue their mature battery intelligence software is preferred over an in-house solution have a point. Their solutions are more economical, tested, supported, secure and featured. The best approach is to work together, using a professional software solution that accounts for the increasing divergence of battery customers’ needs, with module-based software architectured to anticipate efficient customization and growing needs.