When to build IT capabilities in-house and when to buy? When to leverage tools and when to turn to the creative juices of your talent?
Industry veteran Rahul Subramaniam, CEO of CloudFix, a cloud cost-optimization software company based in Austin, Texas, says these decisions can be made by asking a series of questions. He laid them out in a talk with StrategicCFO360.
What are your thoughts on building software in-house versus using third-party enterprise software?
In general, we try to write and own as little code as possible and only build what is unique and niche to our business. When deciding whether to buy third-party software or build it in-house, we follow a simple decision tree.
If the problem we’re seeking to solve isn’t core to our business’ value proposition, we will purchase it from a third-party expert. For example, we use NetSuite, Salesforce and Zendesk for running important operational functions.
If the problem we’re looking to solve is core to the value our business delivers, we first work to identify the most important value differentiator we can bring to the table. We also try to leverage non-value driving components from other providers. For example, we use AWS services for most utility and commodity functions, rather than trying to build them ourselves.
Why do you make that choice?
AWS makes a conscious tradeoff that favors a rapid pace of innovation. The pace at which they are converting utility code into commodity services far outpaces any other provider.
Anywhere from 90 percent to 95 percent of the code in enterprise software today is utility code, which acts as scaffolding for the little bit of core business logic that drives all the value. If all of that code can be removed and replaced with commodity services that can be called with a simple API, then we have a very powerful case for not owning all of that code.
AWS is the only cloud provider, in my opinion, that is driven by a mission of providing that set of building block services to every developer.
How should CIOs think about building software internally versus using existing third-party software to solve IT and enterprise challenges?
When considering whether to buy external software or build the software internally, it boils down to an honest answer to two simple questions: Is the software the core competency of the business? Is the core competency the reason for the software’s existence?
If the answer is no, your default should be to buy software that is built by someone whose mission it is to build that particular software.
What work should IT executives expect tools to do versus when are people needed?
On one hand, you have to make a tradeoff between using tools versus having people do a task. On the other hand, you have to consider the level of complexity or disruption that the task involves.
The fact is that tools are really good at handling low complexity and low disruption solutions. If you have a complex task that is being solved by a tool, it is most likely to face skepticism from the users within the organization. People, on the other hand, are a scarce resource, but amazing at simplifying complex solutions.
In general, I follow these guiding principles when deciding whether to find a tool or allocate people resources to a project:
Using tools to solve simple and non-disruptive problems is the sweet spot. If there aren’t tools available and you must assign people to work on a simple task, invest in automation and build a tool until a new one is created that does as good or better a job than your homegrown tool.
If a tool is too complex to adopt, use people to simplify the problem and build consensus, and then leverage tools to solve the simpler problems. For example, when we first started using Salesforce, we found that trying to migrate all our different sales workflows into the new platform was turning into an incredibly complex nightmare. Our head of operations did a deep dive and made a decision that we would use Salesforce out-of-the-box without any customization because the out-of-the-box solution Salesforce provided was the simplest and most ideal solution for any sales organization.
Lastly, if your tasks are complex and there is no way to simplify them, put people on it. Invariably over time, technology catches up and/or you start seeing patterns in the work that empower you to simplify the task.
