The problem with enterprise IT consistency (i.e., with implementing a single software stack across the organization that will bring order to chaos) is that enterprise IT isn’t static. Because technology isn’t static. As Google’s Kelsey Hightower put it in an interview with Comcast’s chief software architect Jon Moore, “Most organizations learn over time. So whatever you build today as the [default stack] is going to branch out based on new learnings.” 

So how should an enterprise standardize, thereby reaping cost savings and productivity gains? You don’t, said Hightower. At least, not once and for all: “Standardize where you can, but allow things to grow apart and then re-standardize those things as you go and just follow the path of evolution.”

But how to standardize? That’s the question.

SEE: Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)  

Some things aren’t up for debate

Not that everything needs to be in constant flux, of course. As Moore pointed out, for some areas of IT there are “very well understood capabilities that everybody needs…about the same thing [with plenty] of pretty mature options.” In such areas, there’s really no need for an individual team to “grow apart,” to borrow Hightower’s phrase. Having consistency across the company in such areas means a person can move between teams and keep using the same tooling, like a CI/CD system, that they were using before. 

Some people or teams might still prefer to go their own way, but companies can make it institutionally difficult to diverge. Hightower, referring to Google’s own internal IT practices, explained:

[At Google] there’s a lot of commonality that’s taken us about 20 years to grab….All the things that make something production ready, we have lots of frameworks that are part of that delivery pipeline that are just there. Those are areas that are not much up for debate….We have one main build system called Blaze internally. And more than likely you’re going to use that because the bar is so high now for what it requires to have a build tool internally at Google that maybe someone says, “Yeah, sure do your own thing. But that thing needs to do these 75,000 things, knock yourself out.”

There’s a strong gravitational pull to such things at a place like Google because they’ve centralized many things that make it easier for developers to be productive throughout the organization. (Hightower: “It can run all the unit tests and knows who the owners are. And it knows the right sequence of events to get a change in and make sure that all the integration tests run.”) No, you don’t have to adhere to this standard, but since Google isn’t going to allow you to compromise security elsewhere in the org, you either need to clear those “75,000 things” noted above, or you just need to embrace the borg, as it were.

This doesn’t mean that teams are stuck doing things the same, forever. As Hightower went on to explain, different teams can use custom workflows to stitch together the internal, default tools. Such workflows leave plenty of room for experimentation and innovation. The key for larger organizations isn’t so much to define every bit of software or hardware that can be used, but rather to define the interfaces between systems to ensure interoperability. 

Gravitational pulls

While having a monorepo like Google Three (an internal Google tool the company uses to host code and documentation) may not work for every organization, there’s real value to having centralized systems that make life easier for everyone. Getting there isn’t really about the CIO declaring “Thou shalt use Java.” Instead, said Hightower, a company needs “a real commitment.” That commitment probably doesn’t start with 100 engineers. Instead, it starts smaller–maybe a small handful of engineers building tools that will make others productive. Over time, the gravitational pull for such centralized systems will grow in tandem with how much easier they make it to build in the way the company prescribes. 

To this Moore added that it makes sense for this central team to issue chargebacks for their work, allowing them to fund growth while also keeping them accountable to the teams they serve (“their funding grows in proportion to how much they’re used”). In this way, standards grow within an organization without becoming calcified. 

As Hightower noted, it’s right and proper for standards to evolve as technology/the industry changes. But it also makes sense for that fluidity to flow from a solid core, which can be forged by a company with a small initial investment. Start small, make developers productive internally, and watch that centralized investment grow by virtue of its utility and not some C-level fiat.

Disclosure: I work for AWS, but the views expressed herein are mine.

Developer Essentials Newsletter

From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know.
Weekly

Sign up today

Also see