For all the razzle-dazzle surrounding Google, the company must still work through common business problems such as reporting revenue and tracking projects. But it sometimes addresses those needs in unconventional—yet highly efficient—ways. Other

Google, the Enterprise

In the filing for its 2004 IPO, Google included a letter from Page and Brin that declared, "Google is not a conventional company. We do not intend to become one." Maybe so, but Google still has to satisfy conventional corporate requirements for managing money and complying with laws.

In 2001, Page and Brin hired a more seasoned technology executive to be Google's official corporate leader—Eric Schmidt, formerly chief technology officer of Sun Microsystems and then CEO of Novell.

As recounted in The Google Story, one of the first battles Schmidt had to fight was to bring in Oracle Financials to control the company's finances. Page and Brin had been using Quicken, a financial management system for individuals and small businesses. But by this time, Google had 200 employees and $20 million in revenue.

The book quotes Schmidt as saying, "That was a huge fight. They couldn't imagine why it made sense to pay all that money to Oracle when Quicken was available."

So, Google does employ conventional enterprise technology—sometimes. But if you want to understand how the kind of proprietary technology Google possesses can be employed within an enterprise, look at how it's used within Google.

In public presentations, Merrill tries to put Google's technology in the context of how he is using it to address basic business processes like interviewing and hiring the best people, tracking their performance and coordinating projects. "We say our mission is to organize information and make it universally accessible and useful," Merrill says. "We had to figure out how to apply that internally as well."

Consider how Google handles project management. Every week, every Google technologist receives an automatically generated e-mail message asking, essentially, what did you do this week and what do you plan to do next week? This homegrown project management system parses the answer it gets back and extracts information to be used for follow-up. So, next week, Merrill explains, the system will ask, "Last week, you said you would do these six things. Did you get them done?"

A more traditional project tracking application would use a form to make users plug the data into different fields and checkboxes, giving the computer more structured data to process. But instead of making things easier for the computer, Google's approach is to make things easier for the user and make the computer work harder. Employees submit their reports as an unstructured e-mail, and the project tracking software works to "understand" the content of those e-mail notes in the same way that Google's search engine extracts context and meaning from Web pages.

If Google employees found the project tracking system to be a hassle to work with, they probably wouldn't use it, regardless of whether it was supposed to be mandatory, Merrill says. But because it's as easy as reading and responding to an e-mail, "We get pretty high compliance."

Those project tracking reports go into a repository—searchable, of course—so that managers can dip in at any time for an overview on the progress of various efforts. Other Google employees can troll around in there as well and register their interest in a project they want to track, regardless of whether they have any official connection to that project.

"What we're looking for here is lots of accidental cross-pollination," Merrill explains, so that employees in different offices, perhaps in different countries, can find out about other projects that might be relevant to their own work. Despite Google's reputation for secrecy toward outsiders, internally the watchword is "living out loud," Merrill says. "Everything we do is a 360-degree public discussion."

The company takes a more traditional approach with recording financial transactions, however. "Hey, I want those revenues, I really do," he says. That means running financial management software on servers with more conventional virtues like "disks that don't fail very often," he says.

On the other hand, Google runs internally developed human-resources systems on the clustered server architecture, and that's been working fine, according to Merrill: "In general, because of the price-performance trade-off, under current market conditions I can get about a 1,000-fold computer power increase at about 33 times lower cost if I go to the failure-prone infrastructure. So, if I can do that, I will."

Numbers like those ought to catch the attention of any technology manager. Of course, it's true that most corporate enterprises don't run the same applications at the same scale that Google does, and few would find it worthwhile to invest in tinkering with file systems and other systems engineering fundamentals.

But as much as it has poured effort into perfecting its use of those technologies, Google did not invent distributed computing. Companies willing to experiment with commercially available and open-source products for grid computing, distributed file systems and distributed processing may be able to find their own route to Google-like results.

David F. Carr is the Technology Editor for Baseline Magazine, a Ziff Davis publication focused on information technology and its management, with an emphasis on measurable, bottom-line results. He wrote two of Baseline's cover stories focused on the role of technology in disaster recovery, one focused on the response to the tsunami in Indonesia and another on the City of New Orleans after Hurricane Katrina.David has been the author or co-author of many Baseline Case Dissections on corporate technology successes and failures (such as the role of Kmart's inept supply chain implementation in its decline versus Wal-Mart or the successful use of technology to create new market opportunities for office furniture maker Herman Miller). He has also written about the FAA's halting attempts to modernize air traffic control, and in 2003 he traveled to Sierra Leone and Liberia to report on the role of technology in United Nations peacekeeping.David joined Baseline prior to the launch of the magazine in 2001 and helped define popular elements of the magazine such as Gotcha!, which offers cautionary tales about technology pitfalls and how to avoid them.