Today I’m going to be “that guy”. I’m going to tell a “back in the day story”. You know, “back in the day we walked uphill in the snow both ways”, etc.

Anyway, back in the day, my first couple of jobs in the tech industry were as a Unix and Linux system administrator. There was initially a smaller shop with only 10 servers that I worked at part-time (and a mainframe shop too!), but I also ended up for 8 years in a shop with 125 servers and several thousand desktop users. The team was only about 6-8 people so we had to figure out how to automate and scale-out. At that time with this team, there was much more of a reliance on scripting than on products. Even things like patching, for the servers. There were package management tools but we still needed to download patches as source and build the binaries.

This is actually where I pivoted my career from pure IT to software development. The team started writing an ecosystem of software tools to manage these servers. A centralized data source of authoritative user management and system baselines, agents on the servers that read the data and self-maintained themselves, web-based applications to provide help desk and power users the ability to manage the data. This is where I learned source code control, sprints, and automated unit testing. And if we needed something (e.g. how to manage the primary mail transfer agent, the top-level MTX DNS record, for 15,000 users across multiple mail servers) then we wrote scripts that automated the management of that server from the central database of all the users.

Nowadays, running IT for an enterprise shop is different. Although there are certainly still uses for glue code and automation scripts, there exists an enormous, vast library of products and tools and services in the marketplace. And there is a tendency for IT shops to instead look to these tools or products to perform these management and administration tasks instead.

There are pros and cons to this approach. Certainly, the advantages are that the products (usually) come with documentation, support, and training. There’s less of a reliance on a specific “hero” individual because you can train people on the vendor’s best practices and align your operational process to that model. Then you can easily grow your team, find new team members if people move on, or even just find a consultant or third-party to perform tasks and administration of the tools. And also you don’t have to manage a software development effort to take care of all your tools.

The disadvantages, though, might be harder to see initially. I’ve heard it put best like this, “You can build software that aligns to your business, or you can align your business to your software.” By using purchased tools and services, and aligning to the vendor best practices, you might have to redesign or align your organization’s processes to match. (Sometimes this is fine; things like GAAP accounting principles, information assurance compliance, and the like don’t always have a lot of room for leeway.) And some of the tools require so much customization that it might as well have been a software development effort from the get-go.

So how do you, at a strategic level, decide whether to build or buy?

First, you need to understand what you are trying to do. I know this sounds basic, but I mean you need to do more than just define “I need to manage my account receivables”. You need to take a look at your vendors, customers, and partners, and decide how you want to integrate. You need to look at your legacy systems and data and decide whether to migrate. You need to look at your staff and users and decide how you want to train.

Secondly, you need to think about the capabilities you have, in terms of technical skills. Do you already have a software development team? Or are you going to have to build one? Do you have the people to be good product owners, who can provide user stories and feedback to the development teams on this specialized product? It takes patience and communication skills to be able to work with a software team as a functional expert in some domain, as they build a product for you.

Additionally, you need to understand the options for products that are on the marketplace. The software and services market is so huge, there are likely products available for your use case, but how closely do they meet your requirements? Can they be customized? Do they have good support and training available? Does the vendor keep up with security patches and bug fixes?

I recall a good rule of thumb I heard, you should only outsource tools and processes that are not your organization’s core competencies. So for example, if you are an accounting firm you probably want to seriously consider building your accounting software in-house, but if you are a company that manufactures car parts then you should consider just purchasing the account products. That way you have the flexibility and customization available where it most matters, and you can spend your strategic energy and effort on the most important thing…focusing on your products and services that you sell and delivering value to your customers.