Over the past few years, roughly, the discussion of software development has been stuck on the back-bench in favor of the swirl of virtualization, cloud computing, and then iStuff. As I pointed out in my presentation on Agile development and cloud computing to the Agile Austin meeting last week, cloud computing is largely an operations story. Public and private cloud technologies and practices have tended to focus themselves on optimizing data centers, not so much software development. And with virtualization, the story is all about operations, long ago having left the “virtual labs management” angle in the comfortable dust of past year’s portfolio positioning.
(There’s a notable exception here by a cluster of startups who’re focusing on the tools needed to do cloud application delivery, folks like Reductive Labs, dto solutions, OpsCode, and others.)
Just recently, I’ve noticed more attention to how application delivery is effected by cloud computing. Much of it is simply getting back to the job of delivering SaaS instead of only on-premise offerings. This cheers me up to no end as I think much of the cloud (and mobile) focus has distracted from moving the business software vendors to SaaS-models, an evolution that should widely benefit the customers and users of that software.
Questions to start asking
How do you start to think about software development in a cloud-y world?
- What are the new features delivering across the cloud enables? What does it mean to: deliver a new feature whenever you like (whether your customer likes it or not); deliver different features to different groups of users and test which one is “best”; open up APIs that anyone can integrate with; give your customers “unlimited” processing and storage; allow your users to aggregate configuration and usage patterns and “learn” from each other rather than reinvent the wheel; etc.
- How does your software development process change to match your new delivery platform? How do you manage: delivering 52 features piece-mail, one a week, instead of in one big “release” a year; feed that user tracking into your product management and UX decisions; treat operations staff as part of your team (or take on their job in delivering over the cloud); manage the community that hangs off the open (or not so open) APIs that your customers come to rely on; track the usage and value (to you and your customers) of features over the course of years; keep a separate “portfolio” of products when your customer sees them all coming from the same URL; what would it mean if you delivered an “app” that existed for just 4 weeks; etc.
Above even these questions, is a more basic one: are you a software vendor, or a developer working on in-house software? Vendors, whose job is to make money from software, have much different ways of dealing with these questions than in-house developers whose job is to service their organization making money with software.
If you’re charged with software development, which ever side of the fence you’re on, as we start finish hammering out the operations concerns for all this cloud computing hoopla, it’s a good time to start figuring out the new features you can start delivering to customers and how your iteration-to-iteration process has to start changing.
Disclosure: Reductive Labs and dto solutions are clients.
Recent Comments