alphaspirit - Fotolia
To buy or build IT infrastructure focus of ONUG 2017 panel
During ONUG's fall conference, panelists debated whether to buy or build IT infrastructure. Company IT execs say the final decision depends on a company's culture and talent.
NEW YORK -- Among the most vexing questions enterprises face is whether it makes more sense to buy or build IT infrastructure. The not-quite-absolute answer, according to the Great Discussion panel at last week's ONUG conference: It depends.
"It's hard, because as engineers, we follow shiny objects," said Tsvi Gal, CTO at New York-based Morgan Stanley, adding there are times when the financial services firm will build what it needs, rather than being lured by what vendors may be selling.
"If there are certain areas of the industry that have no good solution in the market, and we believe that building something will give us significant value or edge over the competition, then we will build," he said.
This decision holds even if buying the product is cheaper than building IT infrastructure, he said -- especially if the purchased products don't always have the features and functions Morgan Stanley needs.
"I don't mind spending way more money on the development side, if the return for it will be significantly higher than buying would," he said. "We're geeks; we love to build. But at the end of the day, we do it only for the areas where we can make a difference."
A company's decision to buy or build IT infrastructure heavily depends on its size, talent and culture.
For example, Suneet Nandwani, senior director of cloud infrastructure and platform services at eBay, based in San Jose, Calif., said eBay's culture as a technology company creates a definite bias toward building and developing its own IT infrastructure. As with Morgan Stanley, however, Nandwani said eBay stays close to the areas it knows.
"We often stick within our core competencies, especially since eBay competes with companies like Facebook and Netflix," he said.
On the other side of the coin, Swamy Kocherlakota, S&P Global's head of global infrastructure and enterprise transformation, takes a mostly buy approach, especially for supporting functions. It's a choice based on S&P Global's position as a financial company, where technology development remains outside the scope of its main business.
This often means working with vendors after purchase.
"In the process, we've discovered not everything you buy works out of the box, even though we would like it to," Kocherlakota said.
Although he said it's tempting to let S&P Global engineers develop the desired features, the firm prefers to go back to the vendor to build the features. This choice, he said, traces back to the company's culture.
"You have to be part of a company and culture that actually fosters that support and can maintain [the code] in the long term," he said.
The questions of talent, liability and supportability
Panelists agreed building the right team of engineers was an essential factor to succeed in building IT infrastructure.
"If your company doesn't have enough development capacity to [build] it yourself, even when you can make a difference, then don't," Morgan Stanley's Gal said. "It's just realistic."
But for companies with the capacity to build, putting together a capable team is necessary.
"As we build, we want to have the right talent and the right teams," eBay's Nandwani said. "That's so key to having a successful strategy."
To attract the needed engineering talent, he said companies should foster a culture of innovation, acknowledging that mistakes will happen.
For Gal, having the right team means managers should do more than just manage.
"Most of our managers are player-coach, not just coach," Gal said. "They need to be technical; they need to understand what they're doing, and not just [be] generic managers."
But it's not enough to just possess the talent to build IT infrastructure; companies must be able to maintain both the talent and the developed code.
"One of the mistakes people make when building software is they don't staff or resource it adequately for operational support afterward," Nandwani said. "You have to have operational process and the personnel who are responding when those things screw up."
S&P Global's Kocherlakota agreed, citing the fallout that can occur when an employee responsible for developing important code leaves the company. Without proper documentation, the required information to maintain the code would be difficult to follow.
This means having the right support from the beginning, with well-defined processes encompassing software development lifecycle, quality assurance and control and code reviews.
"I would just add that when you build, it doesn't free you from the need to document what you're doing," Gal said.
