In the WSJ, Christopher Mims wrote,
IT spending that goes into hiring developers and creating software owned and used exclusively by a firm is the key competitive advantage. It’s different from our standard understanding of R&D in that this software is used solely by the company, and isn’t part of products developed for its customers.
Today’s big winners went all in, says James Bessen, an economist who teaches at Boston University School of Law and who recently wrote a new paper on the policy challenges of automation and artificial intelligence. Tech companies such as Google, Facebook, Amazon and Apple—as well as other giants including General Motors and Nissan in the automotive sector, and Pfizer and Roche in pharmaceuticals—built their own software and even their own hardware, inventing and perfecting their own processes instead of aligning their business model with some outside developer’s idea of it.
The research is by James Bessen. Robin Hanson has comments. He wonders why good internal software could not be made available to other companies.
I have not read Bessen’s work, but I worry about two related issues.
1. Survivor bias.
2. Correlation vs. causation.
If you were to ask me what I think of the idea of developing internal software vs. using stuff off the shelf, I would advise most companies not to go for internal software. It’s easy to mess up, and once you mess up, you are at a dire competitive disadvantage. My guess is that developing proprietary software is a very high-risk strategy. Granted, some companies at the top of the outcomes distribution have gone that route. But I also expect to find plenty of firms who tried that approach at the bottom of the outcomes distribution.
As for cause and effect, you can’t build an effective software system around a chaotic business process. My guess is that the companies with the most well-analyzed, logical business processes have the best software systems. But the software system is not the driver.
I agree with you strongly. Anyway, it is not as if commercially-available software is inexpensive to buy or deploy. For instance, SAP is expensive and there are legions of consultants who make big bucks to deploy it. It is invasive, often requires companies to adapt their business processes rather than the other way round, and companies that achieve “success” with it tend to become cookie-cutter in important ways.
Or, you could choose point-products like SalesForce, Zendesk, JIRA, and fit your micro-processes to these. And this leaves you with integration problems – tool and process integration. There really is no easy way.
Small companies are best off buying off-the-shelf, and hoping that they are profitable enough in their niche to afford it, while their small (and enthusiastic/heroic) delivery teams make it all work.
Large companies have to engineer their profitability and scalability, and commit deeply to whatever they select as their solution.
Software is an expression of your business rules and logic. Using software developed by other firms is no different than using business practices developed by others.
Most firms are collections of generic ideas combined with a certain amount of proprietary knowledge. Your software should reflect that mixture. If you lack the skills to develop any custom software in-house, I would highly recommend you look into buying a franchise.
The previous company I worked for built their own software. I was involved directly at different points along the nearly 20 year effort.
I think the bottom line issue was, do you build proprietary software to work in tandem with or overlay your proprietary legacy system or do you scrap your legacy system? I think in the 90s those companies that attempted to do a hard conversion to an off-the-shelf system suffered almost crippling and occasionally insurmountable problems.
I would imagine theres still some of that at play.
First, consider the nature of the firm – is it a commodity firm competing in a local market? (Hair salon, auto mechanic, etc.) Or is it competing in some very broad, or even global market?
What is the scale of the firm? At least one company specific package not sold to customers that I know of, was used entirely due to issues of scale.
Second, what is the nature of the IT function itself? Is it some highly commoditized function where it’s all but impossible to do better? (Word processing is a fine example.)
Is it a legally constrained function, where what management is buying from an outside vendor is compliance assurance? (Some number of SAP installations are likely driven by this.)
Is it a forced function – the website that the state requires the firm to use to file its tax report?
Or – is this function by its nature, or by its *scale*, able to confer advantage to the firm’s functioning? One obvious reason that google, amazon, etc., use large farms of open source server software stacks is that paying a server license fee for each of those huge numbers of machines would be prohibitive.
Third, what are the path dependencies? I know of a software stack that was used internally by a large vendor in the ’90s, because it was the only one known that scaled for the vendor’s needs. 25 years later, that same *scale* of function is all but free from various web vendors.
[Source code version control, CAD, and CAM, all have histories like this one place or another.]
DeMeo’s comment about “mostly generic with some special” applies to the firm itself, to software functions across the firm, to the scale of the task, as well as components within the function.
I think Hanson’s entire premise is wrong. Many modern companies open source internal software all the time. A lot of them also make their infrastructure available to other companies.
For infrastructure, Google sells access to Spanner, Amazon has Amazon Web Services, Microsoft has Azure. These companies use the same infrastructure that they sell.
For software:
* Amazon – https://aws.github.io/
* Microsoft – https://opensource.microsoft.com/
* Google – https://opensource.google.com/projects/list/featured
If you search ‘open source’ + company name, you’ll see that most large tech companies do offer a surprisingly large amount of internal software for other people’s uses.
Here’s a real life example. I worked for a large (10x average size) automotive repair shop. We thought that we should build our own management software because “we were different”. Ended up hiring a local (I.E. overpriced) firm to build our bespoke program. Final product looked like a glorified excel spreadsheet. Cost – $20,000 and thousands more for every iterative update. Sunk cost fallacy kicked in; we figured “we’ve already invested so much, we can’t abandon it now”. When outside programs offered better features we reasoned “we don’t need those features”. We’re now at a tipping point where the software is too simplistic for the size/ complexity of the biz. Off the shelf products would work (at the very reasonable price of $100/mo) but we refused to use them, again citing the significant investment in our homemade program. A good way to avoid this is to use Simon Wardley’s value chain mapping. Makes the decision quite simple. With his system it would have been very clear that developing our own program would yield little/ no competitive advantage. It will be interesting to see how this play out in the future for this business. It’s likely that their slow demise will be due to a cacophony of executive level failures, but I’m sure failure will ultimately be blamed on outside factors.
Thanks for the Simon Wardley reference.
You’re welcome!
Many of you seem to be assuming that the software involved is standard business software; it’s probably not. GM and Nissan are interested in modeling cars’ function, car manufacturing, and car crashes to avoid expensive mistakes when they build prototypes (or worse, assembly lines). Pfizer and Roche have models of human physiology to try to predict the effects of various drug candidates; only one drug candidate in thousands makes it to market, and filtering out the less promising molecules early on is a huge cost savings. A company can get meaningful advantages from custom software if it can use software to explore its design space faster and at less cost than would otherwise be possible.
Also, note that often these software packages are developed by startups and then acqui-hired once they prove their usefulness. That limits risk.
Yes you are probably right.
Take something like term life insurance. Its a commodity and everyone uses the same tables for cost. Your only competitive advantages are admin costs and underwriting.
if you can automate your underwriting to cost less, and be more effective at identifying risk, thats where you can find your competitive advantages. And your proprietary underwriting software would be valuable.
Great distinction. Yes, we were essentially developing standard business software.
Wouldn’t the usefulness of this proprietary software still be a barrier to entry and hence reduce competition in that specialized space?
Of course. That’s what I meant by “meaningful advantages”. Aka “competitive advantages”, if you prefer that term.
I think we are agreeing. “Robin Hanson has comments. He wonders why good internal software could not be made available to other companies,” and Kling recommends off the shelf software. But the point of internal, specialized software is that it is both useful internally, and gives the company a competitive advantage over other firms that cannot develop the specialized software (as opposed to generic, off the shelf general business type software which is useful but doesn’t really give a company a special advantage). So basically, the importance of IT tools is business should be a force leading to greater industry concentration in a few businesses, because those businesses have the capital to build useful and specialized tools for their employees that smaller competitors cannot.
Many firms who can afford a large ERP should be able to build their own more quickly and cheaply than an implementation would take and cost. The problem is finding enough qualified developers, analysts, and managers to build it. According to NCES, we seem to annually award only as many CS degrees as in the 80s.
How much would it cost for a company to train the people it needs to build and manage their own ERP system?
I’m more inclined to be on the “build side” of “build versus buy”, particularly if the software is hugely expensive, consultant-heavy software with open-source alternatives or straightforward in-house options.
A classic example of the latter is reporting and “business intelligence” tools, which are hugely expensive, difficult to use, and often not any better or easy to use than simply coding your own reporting infrastructure.
It’s worth noting that many “BI tools” require a level of customization and ongoing maintenance that approaches – and sometimes exceeds – simply coding the reporting world yourself. And since you’re locked into the capabilities of the BI tool, you’re limited in what you can actually do report-wise.
There are expensive enterprise tools that are worth buying, but there are also many fanatically overpriced tools that are quite easy to avoid, either by using open-source alternatives, or spending a few days in-house coding what you actually need from the tool.
In my company (I manage a Dev team) the number one blocker when considering third-party software is security, which no one here even mentioned. Custom software can be held to our fanatically high security standards.
You can learn a great deal about the modern disaster that is software security by considering how many of the fairly smart people in this thread never mentioned it.
Security is rapidly becoming a key competitive differentiator in my industry. Most vendors can’t even come close.