John McDonald spent 20 years as an executive and leader at IBM, including leading technical sales for IBM’s Rational software brand for North and South America. Over the years he built many of IBM’s technical sales processes and teams, and now is leading CloudOne through it’s startup phase into leadership in our industry. He’s been recognized as an IBM Champion in 2011, 2012 and 2013, and serves on the Industrial Advisory Board for the Department of Computer and Information Technology at Purdue University, and is a member of the steering committee for the Customer Cloud Standards Council. He is a featured blogger for the Global IBM Rational User Group, and serves on the advisory board of IBM DeveloperWorks. He received AS and BS degrees in Computer Information Systems from Purdue University in 1995.
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:
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.