There are two articles in NetworkWorld today that caught my attention.

The first article talks about Google Apps, and it’s inroads into enterprise environments as a replacement for Microsoft-based environments. And while it is growing – with an IDC survey saying that Google Docs is “widely used” in 20 percent of companies, there are issues with user training, legacy e-mail migration, interoperability, tech support availability, and concerns about security for companies that have to worry about data retention regulations such as SarBox.

There’s plenty of detail in that article if you’re interested in the pros-and-cons of Google Apps rollout, which I’m not going to get into here.

The other article talks about how one of the top data center challenges is now energy cost – with energy prices predicted to rise (though, let’s face it, when in our lifetimes have they ever really fallen?) companies are shifting the cost of running IT equipment from an infrastructure budget to the IT budget. We’ve talked before about how this is a compelling case for virtualization (and server consolidation.)

What is interesting to me is that these two trends combined reinforce the need and the possibility of application consolidation. While it’s not new that similar apps are bundled together, (Outlook, after all, is an e-mail app and a scheduling app,) one of the big things about Google Apps is that it’s one rollout, one setup, and I would imagine, one server. E-mail, scheduling, word-processing with network storage, and video sharing – all one app.

One of the major problems that large companies have is that between legacy systems, new business needs popping up, combined with the idea that virtualization decreases rollout time, and you have a situation where you might have thousands of applications on your network – if not hundreds of thousands. With the complexity comes waste, effort duplication, and as anyone who has played with Lego or C code will tell you, the more complex the system, the more likely something’s going to go wrong.

When one company went into gain a bid on a Navy/Marine Corps Project, which was the biggest government IT contract that had come up in years, part of the scope of the project was to reduce the number of applications on that Navy/Marine Corps network to only 5000 applications.

But when they asked the Navy/Marine Corps how many applications were on that network at the time, they had no idea. The company, along with rival bidders, had to make a guess – and 25,000 sounded like a good number. After all, there was no possible way that there could be more than 25,000 applications on this network, and so, they made that assumption and bid on that basis.

In reality, there were more than 105,000. Every single Navy base, every single ship, every single Marine installation had developed their own suite of applications independently of all the others.

If you’re able to cut down the number of applications by an order of magnitude, it also reasons that you’ll be able to cut down the number of hosts needed for those applications, and cut down the number of hard-servers needed for those hosts.

And this is where SaaS and projects like Google Apps come in. Essentially, anything that runs through the Web becomes one app – the Web app. In this way, it is almost the ultimate in application consolidation. (Well, maybe the pentultimate - there are still browser compatibility issues, extra stuff to download into the browser, etc, that increase complexity on that front. It’s simpler than having multiple apps perhaps, but another source of complexity nonetheless.) More than that, though, even among Web apps, the move is towards multiple applications becoming singular applications – one of the reasons that Google and Yahoo have been so acquisition-happy is because of the idea that these multiple Web applications – chat, voice, collaboration, photo sharing, video hosting, social networking, etc. – becoming more integrated. Today we think of Google Docs, Google Calendar, and Gmail as separate applications; tomorrow, I’m not sure we will.