The cliché “reinvent the wheel” gets kicked around a lot in business conversations, but it is the perfect framing metaphor for why not every complex business use case demands a custom application.
Essentially, your team invests all of this time and energy building something that likely already exists in 90% of the form you need it to. While you may need to determine how to approach those 10% edge cases, that sliver alone is almost never worth the costs of development.
In addition to development costs, there are also concerns for support, maintaining source code, integration with other applications, and issues surrounding evolving needs. Issues can also arise when applications are coded in a language that is difficult to support or that few work in – an ongoing problem in application programming.
All of these challenges can quickly overwhelm teams, turning IT and contractor teams into a huge cost center. Resources get diverted from other areas of the organization. At the end of the day, they spend more time worrying about their technology than their main operational goals.
These are all strong reasons why many organizations are moving away from wholly custom-created applications to commercial off-the-shelf (COTS) products, open-source products, or embeddable third party software, such as embedded business intelligence.
This is why some organizations are reassessing their commitment to custom applications. A recent article mentioned one example: Scott Spradley, the new CTO of Tyson Foods told the Wall Street Journal that he wants to move away from custom application development except where it offers the company a competitive advantage. There are several good reasons for moving away from a code it yourself approach.
Over-Specifying Application Requirements
Bureaucracies, especially government ones, do a very good job at being specific. However, sometimes this specificity can bite them in the rear. Case in point, over-specifying application requirements under procurement needs.
Often, overly granular specifications are based in legacy systems. The requirements documentation writer simply describes in vivid detail how the old system worked while adding requests for a few new bells and whistles.
The problem is that requesting “the old system and then some” may neglect to define the exact needs of the organization. Instead, it may be framing overall objectives from an end-user standpoint, as opposed to that of a system’s owner.
Countless COTS software or embedded software products can fulfill the needs of organizations but fail to meet their very specific requirements, thereby missing the big picture. To use a metaphor, instead of building from scratch an identical yet newer version of your ‘82 pickup with a camper shell, you can define your transportation needs and look for a more modern SUV that can meet them.
Thinking No Product Exists for Their Current System Architecture
This mindset may be grounded in reality, but it is also a symptom that the existing architecture is causing more trouble than it is worth. For example, the Department of Defense avoided using any sort of internet or cloud-connected product for years because they had serious concerns about vulnerabilities. Finally, the top brass realized that they could simply build their own version of a public cloud but in a private, controlled setting. “That gives them all the advantages of public cloud technology and the expertise associated with that, while still operating in a constrained environment where the physical and virtual access to resources is restricted for anyone who is not in the community,” explained General Dynamics IT’s Stan Tyliszczak.
Similarly, a company can take an existing product that’s 90% applicable to their needs and request customizations or add-on features to get them the rest of the way there. This approach has steered many organizations in government and healthcare towards open-source architectures that can be mostly shared but with a few modifications that are kept confidential and secure.
With this strategy, an organization can dramatically reduce its procurement and support costs without sacrificing functionality.
Recognizing That Solutions Like Embedded BI Can Replace Custom Tools
Ultimately, organizations should put more effort into exhausting all available options before assuming that custom-built is the right choice.
“Speed to solution, lowest lifetime cost and the best customer experience are optimally delivered by leveraging well-known COTS and open source solutions, and by restricting custom software development to the rarest of cases where there is no viable alternative,” observes former federal CIO Tony Scott.
After all, the wheel works pretty well on its own – your organization just might not have found the one that fits yet.
