How can we help?

   
Chris Irwin | 12 Feb 2020

Make or buy? The Economics of In-House Software Development vs. Licensing an Existing Software Platform

The cost and risk of in-house R&D for Building Automation

We have a problem with software. The problem is that we expect it to be free. There’s this public perception that has been ingrained in us. But where did it come from and why does the general public feel that way? There are various factors that got us here. 

In the early days of PC software development it was possible for progressive programmers to develop software applications quickly, and often single-handedly, making the cost of development low. Often, these programmers were motivated by an idealism to share the fruit of their expertise without expecting to make money. Whilst the software development process has become vastly more involved, this open sharing motivation has persisted as the many open source projects today amply demonstrate. Just on Github alone, there were 44M repositories created last year.

Another reason for this persistent public perception is that, as the internet developed, the cost of software distribution declined to almost zero. There were no more CDs or DVDs to worry about, and the market became more global. Because of this, the number of instances of a good application could easily soar to hundreds of thousands if not millions, so it was not necessary to charge much per copy to fund on-going development. The iOS and Google Play app stores represent the epitome of this trend – millions of apps jostle for our attention (Google Play with 2.5M and Apple with 1.8M). Most cost only cents or are “free”  and address a huge range of needs both serious and frivolous. This brings us to another major factor; software is often only “free” because the developer earns their money from advertising. 

Much of the internet's existence is driven by advertising. In fact, in 2018, digital ad revenue in the US surpassed the $100 billion mark. So we pay another way, via the influence on our buying patterns, selecting well promoted products over others we might not know or trust. These observations relate to our experience of software in our personal lives, but it has a profound effect on how businesses make decisions about software procurement as well. Because we know that the software download has no direct cost of production, unlike physical products we buy, we tend to think it is somehow wrong that it could cost many thousands of dollars. 

“How can it possibly cost that much? It’s only software” is an often implied sentiment when procurement of software is discussed. This reflects a lack of knowledge for how complex and expensive it has become to develop modern software.

Consolidation in the market

In the business world, the more complex the software, the more consolidation there is in the market. If you want accounting software, you’ve got hundreds of choices to choose from. But if you want Enterprise Management Software that handles your accounting and a variety of other major services, your selection is smaller. The more complex the software, the fewer the players because of the initial development cost and up-keep.

Another example is in CRM software. Companies like Salesforce and Hubspot offer website services, email automation, data analytics and more -  all features that go beyond the basic CRM needs to be an all-in-one marketing solution. When a software system becomes as complex as Salesforce, it tends to corner the market. There are only a handful of competitors to its full suite of services because the cost of R&D and on-going support is too much for other players to contend with. 

So how does any of this relate to the building automation market and the “make vs buy” decision faced by the management of businesses that need software for their products and systems? The point is that software for automation has become vastly more complex than in previous years, so the cost to both develop and maintain it has become a serious burden which compromises profitability. The perception that software should somehow be “free,” however, pervades the decision-making process, so the cost of licensing software from a specialist supplier is perceived as expensive, whereas in reality it represents excellent value for money, since the R&D cost is effectively spread across all the supplier’s customers.

Why reinvent the wheel?

As you can see from my examples, we’ve come a long way from the days of a lone programmer simply creating software on a PC. Starting from scratch to make your own, unique solution means a lot of up-front capital and risk. This is why a lot of software developers work from existing frameworks where they can. Salesforce is a great example of this kind of framework. If you use Salesforce and want to develop your own app using the existing framework and features, Salesforce allows you to do so using its development platform Force.com. 

The same paradigm can be seen in Building Automation Software. Just like with CRM software, people frequently want more than just a CRM. They want to integrate their social media, digital marketing, employee services and many other functions, as well as integrating with existing products; the same is true for building automation. In the building industry, we now have web services, IoT, and cybersecurity to contend with. Keeping up and adding all these new features the market requires is becoming harder to do for individual suppliers of building automation systems and equipment manufacturers. Fundamentally, they can’t afford the teams of developers now needed to create and maintain an ever-evolving product. This is why frameworks are becoming the best solution for companies who need such software to be competitive and differentiated. 

What is a framework?

“In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software”.https://en.wikipedia.org/wiki/Software_framework 

By way of analogy, if you think of it in terms of constructing a building, a framework is the pre-built structure or frame of the building. It’s much easier to build a building if the foundation is laid and the frame is up. But when you start with open standards like Haystack as your foundation and a framework like FIN Framework already in place, you then have the building blocks to construct a building that meets your exact needs - with all the architectural flourishes you want - without the hassle and cost of starting from scratch. In the case of FIN, in addition to the solid foundation ad framework, there is also a comprehensive suite of pre-built apps to provide the “walls, floors, and roof” of the building too. Equally, if you prefer to develop your own cladding etc. then there are well documented APIs to enable that to be rapidly achieved. 

Buying into a framework will lower upfront costs because 90% of the work is already done. All that’s left for your internal developers is the customization. Your R&D team only has to tailor FIN  to fit the devices you want to control, adapt the IU, or change the graphics to make a unique market proposition. This ultimately means that your product gets to market faster, with less risk and at much lower cost. 

Weighing the costs of in-house R&D

When planning a new generation of automation or IoT software, your timeline will typically extend to several years, and almost inevitably initial specifications get pruned back in order to bring the new software to market to meet increasingly urgent demands from your sales teams. This leads to the release of a Minimal Viable Product (MVP), but then, once the new product is marketed various feature requests lead to numerous upgrades and testing cycles to debug and patch so as to address your users’ feedback. These added features add to the already over-spent development budget. Meanwhile, every year the wider industry changes, and more features are required, which means even more development dollars. And then there is the need to maintain cybersecurity….. All of this equals a lot of risk and costs that are entirely born by your company.

There is another way! With a framework like FIN, the licensing costs cover cyber-security and de-bugging. You’re not bearing all the cost of that because you’re sharing it with the other licensees. Plus, as stated earlier, you’re not starting from scratch. J2 Innovations has already invested many millions of dollars into the FIN Framework and most of the functionality you will require is already there as well as more features you may need in future. It’s way more than the MVP.

Make vs buy dev costs graphs with title

You also have to consider, as a first-time builder of BAS, the learning curve that your competitors have already faced. Your software simply won’t be as good. It just makes sense for BAS, HVAC, and other equipment manufacturers to leverage the power of frameworks like FIN to get to market faster. 

The FIN Framework is designed to be open, supporting all the major protocol standards used in buildings today, to enable integration with multiple building systems and IoT deployments. It delivers huge time saving for all aspects of a project, including points, control logic, graphics, summary, O&M manuals and OEM specific features. It’s cyber-secure, complying with the highest security standards. It’s also faster than ever for OEMs to customize and develop additional features and functionality on top. The API documentation has been enhanced with a new developer UI reference document system to make it easier to find specific info.

Want to Take FIN For A Spin? Contact us today for a free demo of FIN 5, a faster, more open, robust, and extensible framework.

Contact Us    

About the author

Chris Irwin