Why Microsoft

A blog about Microsoft's strategic and technical differentiation.

Convenient for Google, Not Good for Business

Convenient for Google, Not Good for Business

  • Comments 4
  • Likes

As we prepare for the launch of Office 365, I wanted to know what practices Google has in place to serve its business customers. What I found was that some of Google’s practices are convenient for their company and not truly customer-centric. A good example is their tools and support lifecycles.

Google has a short lifecycle
Google supports its APIs for up to three years, a lifecycle they describe on the Official Google Code Blog:

“With all of the recent API announcements, our API directory is getting quite long! However, some of our older APIs have been superseded by bigger and better things and others may not be receiving the necessary love. As the web evolves and priorities change, we sometimes deprecate APIs – that is, remove them from active development – to free up resources and concentrate on moving forward. Today we're announcing a spring cleaning for some of our APIs.”
-- Adam Feldman, Google

That post, announcing the retirement of Google APIs, is registering overwhelming concerns, begging questions such as:

“I have a question: why should any developer, any company which wants to build a valuable product for the long term use any of your APIs ever again?”
-- Frank Enzenhofer

“This course of action is an inappropriate and terrifying move to your developer base. I never even used the Translate API, but I've used a dozen others from Google for free educational software, and I cringe at the thought that someone who "makes developers' lives easier" could wipe them off the face of the Internet without taking even a moment to consider the implications of such an action.
-- Anonymous

Business resources are strained and IT administrators become quite irritated by practices like this. Organizations seek to customize and develop applications with a useful life of more than three years. Even upon retiring tools including its Finance API, Google did not announce the end date for seven of them, leaving customers to ask how long individual APIs would be supported.

Not only that, businesses and users will be affected by the fact that Google is discontinuing support for older browsers. (Citing three NetApps figures for browser adoption here), 18.9 % of the market is using a browser that will not be fully supported with Google Apps beginning August 1. Looking back to January 2010, Google lopped off support for the popular IE6 browser, which 10.4% of users run today. Announcing that it will discontinue support for IE7, Firefox 3.5 and Safari 3 on August 1, Google is blocking another 8.5% of users from their choice of browser if they elect Google Apps, providing just 60 days’ notice.

How realistic is it for a mid- or large-sized organization to asses impact, then justify, plan and roll out what could be a combination of PC, operating system, application and browser changes to their workforce within 60 days? Even if the impact is minor and the timeframe is realistic, would you want to be suddenly faced with that challenge in providing uninterrupted support to employees who are depending on accessing the Google Apps features each day to accomplish their work?

Google leaves no planning horizon for software updates
Google’s lack of a product roadmap for the cloud is further evidence that Google doesn’t understand business’ needs. IT teams and businesses use release roadmaps to plan for technology adoption and rollout. This planning is particularly important when a variety of applications are being used, or when the user base is large. For Google Apps customers, the Google Scheduled Release track offers organizations a 1 week delay in adopting the latest changes to Google Apps after announcement. However, one week post-announcement is not realistic for many companies to adopt changes. Administrators need to learn about the features and be ready to answer questions about them. In fact, a strong IT staff will inform users ahead of a release, and may time releases to take effect in relatively quiet business periods.

Microsoft understands businesses’ needs
As businesses grow to include dozens of employees, the range of business needs grows and IT staffers plan actively for hardware, operating system, software, browser, unified communications and cloud service transitions. Balancing business needs and costs, IT creates transition plans which typically do not utilize the latest versions of hardware and applications immediately. While Google is creating limits for businesses, Microsoft has decades of experience in serving businesses, understands their needs, and has practices in place to ease these transitions:

“Google is one of the first online software vendors to drop 2006's IE7 from a support list.
Microsoft, for instance, has committed to supporting IE7 on Windows XP until April 2014, and on Vista for three years longer.”
-- Gregg Keizer, Computerworld

Microsoft provides a 10 year support lifecycle. In fact, understanding the need for long-term use of its technologies, the company first put its support lifecycle policy in place on October 15, 2002: 
“Microsoft will offer a minimum of 10 years of support for Business and Developer products. Mainstream Support for Business and Developer products will be provided for 5 years or for 2 years after the successor product (N+1) is released, whichever is longer.”
-- Microsoft’s Support Lifecycle Policy

Not only does Microsoft have a long support lifecycle for existing products, it assists businesses and individual users in their software rollout phases via a consistent, built-in “compatibility mode”. This mode helps customers assure they can utilize files and content created for previous product versions. For example, an IE9 user can see content built for browsing via IE8. Web page meta elements simply trigger use of the "compatibility mode" in the IE9 browser. In fact, to assist in software transitions, Microsoft provides a full range of compatibility mode capabilities across the other applications which businesses depend on such as Word, Office and SharePoint.

I hope this discussion provided some new considerations as you plan your software as a service migrations. Please take a minute to let us know what is important to your business in transitioning to web-only applications, and in using web applications day-to-day.

Comments
  • <p>So Microsoft has never dropped a popular API / tools / software? </p> <p>Fox Pro?</p> <p>VB 6?</p> <p>Windows Home Server and it&#39;s semi-disk array?</p>

  • <p>I remember when .NET launched and many legacy features of ASP were not simply deprecated, they were summarily dropped. &nbsp;Objections were dismissed in the name of discipline, as I recall. &nbsp;</p> <p>Google is sometimes capricious in the way of an adolescent, but nobody should have to support IE6. &nbsp;That dog never did hunt.</p>

  • <p>In my experience, Microsoft has had such a long support cycle for some products that there ends up being no upgrade path at the end of the term. At this point, Microsoft further charges for support which is only in the form of infrequent bugfixes. I&#39;m not talking about $200 programs here, I mean $20,000 business software packages. This causes businesses to scramble when the support period finally ends in order to completely revamp their systems. At least Google predictably drops old software so that businesses can organize themselves to gradually migrate projects to updated code.</p> <p>Furthermore, as a Web developer, I assure you Internet Explorer 7 is a joke and Internet Explorer compatibility mode rarely works correctly with ancient intranet applications. I&#39;m glad Google drops support for old browsers.</p>

  • <p>While I agree that it&#39;s a scary thought that these APIs can disappear so quickly, criticizing Google for dropping IE6 and 7 support is ridiculous.</p> <p>Microsoft&#39;s never-ending support for these antiquated browsers that decided to ignore web standards is the worst thing to happen to the internet. It would be amazing to see how quickly the web could evolve if developers such as myself weren&#39;t forced to build for the lowest common denominator which is always Internet Explorer.</p>

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment