The IT Strategy That Makes Google Work
savio13 writes "InfoWeek published an article on Google's IT Strategy, which can be summarized as: 'Use customized open source where possible, custom build where necessary , and buy if it's not related to something that will give Google a competitive advantage.' The author interviewed several senior IT folks at Google and the article is surprisingly thorough considering how closely Google guards information about their actual IT environment." From the article: "Google managers tend to be reticent on the subject of IT strategy, they're loath to talk about specific vendors or products, and they clam up when asked about their servers and data centers. But a day spent with some of the company's IT leaders reveals there's more to Google's IT operations than a search engine running on a massive server farm. Behind the seeming simplicity is a mash-up of internally developed software, made-to-order hardware, artificial intelligence, obsession with performance, and an unorthodox approach to people management."
One of the things that has consistently impressed me about Google is their willingness to look at old problems in new and innovative ways. Of course this is one of the hallmarks of a successful company, but it is not always successfully implemented. One example is their Google Earth application that made huge waves in certain agencies like NIMA. The interface made more than one NIMA/NRO/CIA analyst/project manager smack their forehead in stunned recognition of a superior way of layering and interacting with diverse types of data.
The other thing that really impresses me about the company is the flat egalitarian structure that at the same time allows for tremendous independent freedom while also making much of the management fairly transparent which does tremendous things for morale. I also respect the encouragement of discourse including criticism. Not many companies can tolerate that sort of structure because they are built upon protectionism of management structures and establishment of castes of a sort. It shows that Google is one of the few companies like Apple that are succeeding because of their inherent talent. Google knows this and I would encourage them to resist the pressure to devolve into management structures that are having negative effects on tech companies as diverse as SGI, HP, Dell and Microsoft.
As an aside, Google has shows a tremendously insightful ability to pick and choose product development talent at all levels over the years. I've been impressed by many of their hires. Whoever is heading up their HR dept. is talking actively with the Google special sauce R&D folks and they know their stuff.....
Visit Jonesblog and say hello.
For those don't know the URL, you can find google here.
Hulk SMASH Celiac Disease
"The IT Strategy That Makes Google Work Today"
Everyone's talking about how bloated and old Microsoft is... give Google 10 or 15 years - rest assured we'll be seeing comments like "Where Did Google Go Wrong?" or "Google Delisted" or something like that.
Want to read about some cool Google "cooked up" technology?, read this white paper on the Google File System (one of the coolest, simplest, most elegant file systems I've seen).
Yes, if only Google had some sort of project devoted to open-source development.
I don't know the structure of Google's "contributions" Maybe you never see code submitted by "Google". But aren't there Google employees who are paid to be full-time open-source developers, some of them contributing regularly on major projects?
Sorry to spoil your paen to Google, but Google did not actually develop Google Earth. That was done by Keyhole, Inc. (in the guise of their Earth Viewer application), who Google acquired.
However, credit can be given to Google in this case for recognizing when someone else is looking at old problems in new and innovative ways, and adapting their approach.
They pay Guido's salary.
Anyone who reads all 5 pages of that article is going to learn more than just one new valuable thing.
A little secret known by some companies is that if they don't use commodity SW they can gain a big advantage over their competitors that do. The trick is in tailoring Free Open Source SW to match their business model instead of the other way around like you do with MS and other commodity SW. This approach does require someone knowledgeable enough to make it work.
Ok this basic approach has been done before. The American Airlines SABRE system which for years was THE strategic advantage of American Airlines. SABRE was a massive project that involved the custom development of an Operating System: TPF which IBM built specifically for extremely high speed transaction processing - much faster than CICS over MVS. SABRE also lead the development of very high performance non relational DB's. IMS and IDMS are direct offshoots from this work, in fact IDMS was probably the fastest general purpose DB ever until Teradata came along. On the hardware side, they squeezed performance out of the IBM TCM mainframe line that no one thought possible. IBM had trouble benchmarking it is was so fast and it was years before they even published their results.
But again, the basic approach was to start from scratch and build the biggest fastest business application system they could design. The problem with SABRE is that change control and management were nightmarish in their complexity.
What I'd be interested in learning is how Google handles patch management, security APARs, change control, health checking and all those mundane process driven chores that catch us all up.
And yes I am old geezer. I did extensive work in high performance CICS systems such as running CICS as a continuous communications task.
The article noted that Google uses a custom tuned Linux kernel. Does anybody know what changes (if any) Google has contributed back? I'd suspect that said tuning includes some kernel changes.
I agree with your point. However, just to nitpick, your concept of NIH is reversed. NIH means to *refuse* to use concepts/tools that were "not invented here." In other words, companies that take the NIH approach would prefer in-house solutions to 3rd-party ones, not the other way around. So your argument is actually in support of NIH, not against it. wiki link