It makes good sense to follow Google's lead with technology. Not because what Google does is particularly complex – it isn't always. Companies follow Google for two reasons:

1. Google is operating at an unprecedented scale and every mistake they make related to scale is one we don't have to repeat, while every good decision they make (defined as "decisions that stick") is one we should probably evaluate;
2. Google is as strong an attractor of talent as IBM's labs once were; that much brainpower – even if a large part of it is frittered away on the likes of Wave, Buzz and Aardvark – produces value for all of us.

Using Hadoop is not following Google's lead. It's following Yahoo's lead, or more precisely, venture capitalists who took a simple concept and made an industry of it. MapReduce is behind state-of-the-art to the point that Google discarded it as a cornerstone technology years ago. Hadoop itself has tried to move on.

The problems of scale, speed, persistence and context are the most important design problems we'll have to deal with during the next decade.

We must work through what we mean by “big data”, what we mean by "structured" and "unstructured" and why we do need new technologies to solve some of our data problems. But “new technologies” doesn’t mean reinventing old technologies while ignoring the lessons of the past. There are reasons relational databases survived while hierarchical, document and object databases were market failures, technologies that may be poised to fail again, 20 years later. 

What can following-Google, as a design principle, tell us about scale, speed, persistence and context? Perhaps that workloads are broader than a single application. That synthetic activities downstream from the point where data is recorded are as important as that initial point. Or that declarative and relational models of some sort will be in your future.