We're frequently asked why anyone should care about development in the cloud.  It's a reasonable question: with all the hype and over-reaching going on about the impact of the cloud in all areas of IT, it's natural to wonder if there's anything behind the curtain for software and systems development.

The answer is an emphatic "yes".  In fact, we've identified 3 common issues that tend to drive cloud adoption for development:

  1. You want to save money.  This is often the first motivator behind looking into cloud delivery - the belief that somehow it is going to conserve budgets with the same or better results.  And while it's true there are lots of ways to save money with the cloud, including professionally managed, efficient operations and efficient reuse of software licenses, ultimately this reason alone is somewhat "nutritionally unsatisfying."
  2. You are looking for more flexibility.  This is a huge driver for line-of-business developers who have grown frustrated through the years with the difficulty they experience in getting IT to support the twists and turns of their infrastructure needs.  You see, when IT provisions a workstation, they ususally have a standard set of tools and configurations that are laid down onto the box prior to deployment.  But in the developer's world, that base box is completely in sufficient, and they will often take hours or days to install, configure and rebuild tools just to get back to where they started.  This misalignment between developer needs and IT manifests itself everywhere, and is a primary driver behind lines-of-business seeking their own IT infrastructure from the cloud.
  3. You are looking to globalize your development process.  This is the big one, and though it's most exciting, it's probably the most difficult to achieve.  Here's why.

Since the beginning of computing, software development has been a very localized process.  It was impossible, for instance, to stray very far from the mainframe when the method of software delivery was passing a bundle of punchcards through a window to an operator.  Later, we shifted development to terminals with host-delivered software development tools, and then to workstations with PC software for creating applications both for that platform as well as the mainframe.  But all the while, we usually had the team of developers co-located, using local servers to share code and to perform builds, as the network links and resiliency of the the software development tools themselves didn't permit wide distances between players.

Fast forward to today, and we find a global staffing model for development projects that puts tremendous pressure on this old-school model.  We now have players in the development team scattered all over the world, often mobile, and more often not employees of our organization, but vendors, contractors or outsourced resources.  The challenge is weaving all of these players into one, global, collaborative development team, sharing code, information and metrics about the development process.

But if everyone uses their own workstation with their own tools, how do you maintain consistency across all activities?  How do you make sure you have the best data about the process if everyone's sourcing their own tools?  How do you ensure security when it's so easy to download and leave assets on a remote workstation in the other part of the world?

These questions are hard to solve, but the cloud helps tremendously.  By creating one, single, accessible location for all players in development, no matter where they are, we can now connect anyone, at any hour of the day, and instantly make available all the code, metadata and collaboration anywhere in the world.  With virtual desktop integration (or "desktops from the cloud") we can now deploy a common, templatized workbench of tools to everyone, and leave all the data tucked neatly into the secure cloud instead of loaded into backlevel or incompatible tools on a far-flung workstation.

Very exciting, right?  So why is this so hard?

The answer is that it's not so much about the technology as it is about your own organizational processes.  You see, what has to change is the internal processes for collaboration more than inventing some wild new technology or some revamped network infrastructure.  It's more about the attitude we have toward security, collaboration and desire to share, and less about using some new tool or some new gadget.  That means it's harder to implement, because changing people is much more difficult than changing a network wire.

Would love to hear your thoughts on the topic.