When "Agile" becomes "Fragile"

Last week one of my board members, Andrew Nash, shared a conversation with the CTO of one of the ten biggest software companies in the world. The subject of the conversation was agile development. The CTO complained to Andrew that agile development is worthless if you cannot extend the stream of innovation to customers in a timely manner. What does it matter if the application developers deliver code to release engineering and QA on a monthly basis if the subsequent delivery and consumption by the customer takes between 6 months and a year? The valuable concepts of rapid feedback and minimal work in process get blown away because navigating the matrix of pain and distributing innovation to customers is so inefficient. If application providers are to truly gain benefit from agile development, they are going to be forced to embrace appliances, virtual appliances, or SaaS as the delivery model. Without control over the the system software as part of the application delivery and consumption cycle, agile development rapidly deteriorates to fragile development and becomes worthless.

Agile development is a close cousin to the lean manufacturing concepts pioneered by Toyota in the mid-80's and early 90's. The concept is simple – keep work in process to a minimum in order to discover and improve mistakes with a minimal amount of waste and rework. Agile development likewise seeks to keep work in process to a minimum in order to avoid large scale mistakes in architecture and feature design by facilitating rapid feedback throughout the value chain – from the developer, to QA and release, and ultimately to the customer. It has the side benefit that products that rapidly evolve to deliver ever greater value to the customer become “stickier” and less prone to competitive displacement. It often happens that a competitor replaces a product because the upgrade to new features in the incumbent product was more expensive than the switching costs to the competitive product. Just ask the folks that used to work at Baan about this problem. SAP made a killing switching out Baan customers due to extraordinary upgrade costs.

In order to prevent software “work in process” from piling up at the proverbial shipping dock (i.e. release engineering), the complexity of the release engineering matrix must be dramatically simplified. Fortunately, appliances, virtual appliances, and SaaS all provide this goal of simplification, and they are rapidly becoming the de facto delivery model for much of the new software being consumed in the market today. These improved distribution models enable application providers to do something good for their customers and their developers in one fell swoop. Customers get more innovation with fewer hassles, and developers get to work on new features instead of grinding away to solve the problems created by the context of release engineering. If you hope to embrace agile development and avoid fragile development, you better sort out your distribution strategy as well. The legacy approach will not get the job done.

Cloud Computing Casts Shadow on Walled Gardens

As a technology provider that helps application companies embrace cloud computing by virtualizing the applications to run on any cloud, I was a bit disappointed with Google's appengine announcement. It appears that Google is embracing the “walled garden” approach of salesforce.com and Microsoft instead of the cloud approach of Amazon. I believe that walled gardens will ultimately be overshadowed by clouds because you cannot achieve webscale computing if every application has to run on a server owned by Google.

Historically, Google has been very good about providing APIs that enable applications to access its web services independent of the computer on which they run. This is an important concept because it is often the case that an application needs to run on a particular network or network segment in order to preserve some critical aspect of performance or security. It is also important because it provides developers with the broadest choice of system and programming tools when developing or maintaining their applications. If you must program the application in the Python implementation specified by Google and run it on a Google server in order to take advantage of services like BigTable and Sawzall, a huge segment of the application market has just been eliminated from consideration (note that it is unclear to me at this time if Big Table and Sawzall can be accessed independent of appengine).

Why not simply expose a virtual machine API (such as Amazon Machine Image) along with the API for the web services (such as Amazon's S3, SQS, etc.)? Application instances that require minimal latency to Google services are provisioned as virtualized appliances on a Google server. For applications that need to run on a different network, you can provision the same system definition to that network while accessing the web services over the Internet. Write the program in any language you choose. With any set of system components that you choose.

The problem with walled gardens is that they ultimately restrict the growth of the market. While it is true that an attractive and well manicured walled garden will result in asymetrically large economic rent for the owner of the garden (witness Microsoft), the size of the market is nonetheless constrained. It seems to me that Google would reap the greatest benefit from maximizing the market for cloud applications quickly – independent of their ability to collect an asymetrically large portion of the rent from that market. Even their marketing of the current implementation of appengine indicates this hypothesis is correct – it is free. Success with cloud computing will no doubt lead to a decline in the value of the Microsoft system software franchise (the ultimate walled garden). Why not accelerate that decline with broad market capability instead of yet another walled garden (YAWG)?

Let me provide a concrete example. rPath was approached by a SaaS application provider to help them release their on-demand application as an on-premise application – without sacrificing management control of the system software. They want on-premise capability in order to meet the data security requirements of a certain segment of the market which they have been unable to penetrate with their SaaS offering. Their current application runs on Microsoft server technology, but it is written in Java so skipping out of the Microsoft walled garden was pretty trivial. We provided them with a virtualized implementation of their application, and we demonstrated how it could run on a local network atop a hypervisor, or as a variable cost implementation on Amazon's elastic compute cloud (EC2). Their reaction was so positive that they are now planning to gradually migrate their entire infrastructure from Microsoft to virtual infrastructure in order to seamlessly deliver the application via SaaS, variable cost cloud (Amazon), and local network (virtual appliance). Without changing their preference for programming language. Without sacrificing control of the system software layer.

To be fair to Google, appengine is a beta service. I have no doubt that they made compromises in architecture in order to get the service out the door more quickly. I hope they follow Amazon's lead and expose all of their great services as true web services while enabling any application to run close to those services via a simple virtualization spec such as Amazon's AMI. The faster we take the market to cloud computing, the sooner we can kill off the walled gardens through webscale shadows that deprive them of economic sunlight.