in my view the CIO’s dilemma can be simply stated as such: given 50¢ of resources, generate $1 worth of output. that mostly stems from the fact that many organizations don’t see information technology as being an investment in their long-term growth; they still see it as being an overhead expense to be controlled. in that kind of world, why spend $1200 for a laptop when you can spend $600 instead? [even though macs are actually less expensive than PCs.]

with fast, cheap, and good being your options, and knowing that only two are possible, it can lead many leaders to make compromises. give and take is the nature of life, and perhaps no more so than in business.

then how do you navigate the landscape?

do what only you can do

build versus buy is a critically important question everyone has to consider for every solution. each organization must factor in the following noninclusive list on a case-by-case basis: available budget, current business performance, time-to-value, available in-house skills & resources, opportunity cost, and industry trends.

that being said, the closest thing to a universal truth i’ve found is this: it’s about identifying those things that only you can do.

you wouldn’t build out your own phone system—running miles of underground cable and developing your own proprietary protocols or codecs simply so that your sales reps can call on customers. yet i see folks all the time wanting to develop home-grown project management software. it makes you wonder why that’s so. is it because it seems easier?

if what you’re considering building is something you can claim as ip that only your company has—you should go for it with relentless tenacity. more simply put, consider it this way: would google, amazon, or microsoft want to acquire your company just to get their hands on the thing you built or the people who built it? if the answer to that question—however—is ‘no’, it may not be the most sensible investment for you to make.

the long-tail of maintenance

but still, perhaps you’re like me. you like to tinker. you have a burning desire to build something. your can-do, do-it-yourself attitude makes you consider taking things in-house to avoid perpetual OpEx costs from licensing. when viewed from this lens, it certainly looks great at first until you consider the long-tail maintenance requirements for the systems you develop.

when you have to patch and upgrade your servers to the latest os version [you are doing that, right?] and your code stack needs to be upgraded as well to protect against security flaws [you are doing that, too, right?], will all the code libraries you used to build your application still work together? building often seems cheaper because many groups don’t include security monitoring and upgrades into their annual budget or project plans.

consider the situation where you just acquired a new company in europe and it’s your job to integrate the two. the ruby backend you created to handle a few thousand records can no longer handle the hundreds of thousands of records you need to throw at it. do you have the in-house resources to re-platform your systems to take advantage of a different code stack to handle the new requirements? [and don’t forget about multi-language or multi-currency support.]

are you positioned to react when new compliance regulations come about like GDPR or the california consumer privacy act?

what kind of disaster recovery plan do you have in place for each system? if something terrible happens to that core enterprise application you built, do you have the capacity to react to and fix that issue? what’s an acceptable level of risk of downtime to your business?

is this enough to make you not want to be a CIO yet?

best of breed trap

it’s tempting, then, to look at the landscape and decide to purchase point solutions which are best-of-breed. the challenge now becomes a proliferation of dozens of separate systems, wholly disconnected, delivered by dozens of different vendors with all types of legal agreements and contract stipulations. integrating your ERP with your HCM system could violate the TOS of one or the other, or maybe even both. your city planning tool is amazing—but is it built on an open framework allowing you to integrate with your social media and marketing automation tools? [city services are only great if people are aware of them.]

having too many systems can also increase your overall support costs. with specialists needed to handle each system, efficiencies of scale are lost, personnel demands outpace what the organization can afford, and the market may not have the available talent to solve for that skills gap.

how to go beyond

the world of information technology is difficult. demands will continue to rise with ever declining resources. new innovations will lead to challenges we never foresaw. an increasingly competitive world economy will amplify the outcomes of our choices—for good or bad.

how does one go beyond the challenges of today and meet those new struggles head-on?

  1. the best thing you can do for your organization is worry about building your own ip. do what only you can do; delegate the rest
  2. change the conversation around cost and show the others in your organization the hidden downstream expense of going it alone
  3. partner with the right organizations that can help you not only transform your business, but also integrate it more closely with your partners and customers

we can create a more connected enterprise where business runs on free-flowing data on demand. one that’s more cost-effective in the long term. it all starts with knowing who we are, and looking outside the organization for the expertise and partnerships to help us reach our goals, together.