Abstractions, Libraries, and Programs
Don't reinvent the wheel is a popular principle in software. Competent developers define abstractions for processes -functions- and real or abstract things -objects- just once, and then invoke them throughout their code. Sometimes, the programmer notices that 2 abstractions actually represent things that are quite similar, and can be merged into a consolidated entity. Other times, modifications to the abstraction need to be made in order to represent certain qualities of processes or things, such as the height of a building or the breed of a dog.
Abstractions that are deemed worthy, are bundled together in a product called a "library": a set of useful abstractions that have an unified theme, or accomplish a certain task, or both. There are libraries that handle connecting to a URL, libraries for data analysis, libraries for computer vision, and almost every other task imaginable. Often, there are multiple libraries for each task one needs to accomplish, as there can be little differences which matter a lot to the end product. Just to add complexity to the matter, libraries often include other libraries. If something the programmer needs is already in a library, he or she does not need to write the code again, that is, to reinvent the wheel.
As many programs need to connect to URLs, many companies need to, for example, analyze data, so they use Microsoft Excel. Alternatives exist, sure, but in the Forbes 500 companies it is hard to find any serviceable substitute for it; it has become the standard. One does not need to create another program with the same function, if the existing solutions are reasonably priced and serve its purpose well, but with software becoming better and cheaper, companies have more solutions to choose from than ever before, and the ability to create their own products.
The article Our IT Is So Good, Let’s Sell It, Firms Say, from the Wall Street Journal, informs that:
Companies outside the technology sector are stepping into the software market, selling digital tools developed by their own information-technology teams to other businesses, with some firms even spinning off technology units.
It then proceeds to name successful IT projects that companies started selling to outside customers, including:
- A law office task automation platform (AI-powered)
- A reservation system for hoteliers (cloud-based)
- A supply-chain system for selling services to manufacturers (cloud-based)
- An smartphone app for meetings and other routine office services (AI-powered)
The trend is growing, facilitated by cloud-computing, and by the new possibilities of machine learning. Big non-technical companies might not be familiar with the intricacies of the software business, but they have 2 big advantages: capital and data, provided they manage their finances and data properly. If innovation depends more on big data, that is another advantage for big players.
Market risk, a persistent problem for startups, is not relevant when massive corporations develop internal software. Employees usually don’t have much of a choice for the kind of software they use, so the product will indeed be used and adopted. It might not be the best solution, or have the most user-friendly interface. It might be slow and expensive to develop, but when completed (if completed) the product will reach its target audience.
No market risk on the software project, saving lots of money on vendors, big player advantage due to big data, professional sales departments, and software infrastructure becoming cheaper. There is another big advantage for these companies: the marginal cost of developing external vs internal software is usually minimal if properly designed, depending on the specific project, which means selling internal IT has 0 incremental development cost. Sometimes, designing software for its external use can even increase its quality since, for example, security standards will increase.
There are a couple of reasons, however, why selling IT solutions might not be such a great idea. First, software projects are risky, so even if you know that a product will have a great client (yourself), first you need to build said product. Second, even if the company that builds it considers that a product is valuable, that doesn’t mean other companies will follow. Marketing requires effort: being in the right market, reaching out to customers, technical support, competition (including software’s biggest players). But there is a bigger reason against this business idea, an strategic one: the greatest client for the product would be the company’s biggest competitor. Then, if your product provides a competitive advantage that makes you more productive, you might want to keep it for yourself.
Finally, even if successful and properly managed, software projects can be expensive, with the biggest cost being people who build it. One cannot help wondering if cheaper alternatives exist for the same software solutions on the market, and lack of research, inertia, or plain vanity is making companies enter the software business to create just another program for the same purpose, just another wheel, with little extra business value.
Large corporations have a propensity to build custom software, but sometimes they end up with solutions far worse than what the market offers. They can save millions from vendors, but lose them in productivity. I have witnessed companies creating the clone of popular open-source (free) programming libraries for no apparent reason (and have I tried to find out).
More risk, more return. Since the business of software is risky, the potential benefit must be considerable. With proper architecture and design, whether the client is internal or external will add little effort to the project. If everything goes well and a fine digital product is created, which also has the peculiarity of having a marginal cost close to 0, it makes a perfect sense to sell it.