The IT industry is abuzz with conversations regarding continuous delivery, DevOps, and cloud development—and with good reason. Advances in agile software development methods, the integration of these practices into both on-premise and public clouds, and the emergence of end-to-end cloud platforms have been shown to cut development cycles by as much as half, greatly improve quality, and reduce costs. Even though this is an unbelievably exciting time, we need to work together on the issue of the “fractured cloud.”
The shift toward agile and cloud methods results in a variety of options that empower developers to choose their specific development processes, platforms, and tools to meet their design objectives. That’s great for project teams, as it enables them to make rapid decisions around team structure, tooling, processes, and technologies all of which contribute to improving delivery speeds. The downside is that there is a proliferation of incompatible tools and processes that sprawl across the modern enterprise as organizations have gone agile, cloud, and global. In addition, development environments are increasingly being optimized around project goals and objectives, with less focus on the improvement of program-wide and cross-organizational application lifecycle management. This results in incompatible databases and data formats, inconsistent processes and tool configurations, and high support costs in the enterprise; achieving a coordinated enterprise delivery and deployment system is difficult at best. I refer to this phenomenon as the “fractured cloud.”
There’s a reason this “fractured cloud” is proliferating in the enterprise. Something is missing in our conversations—that critical piece: “the collective intelligence of the cloud.” That is, “the community architecture” that allows entire organizations to come together and gain enterprise-wide leverage needs to be addressed.
The Collective Intelligence of the Development Cloud
When Brian Behlendorf and I founded CollabNet in 1999, the question we sought to answer was “What was the magic in the burgeoning open source industry that had enabled a very small set of Apache software developers, most of whom never met each other in person, to create a web server that became number one in the market at literally fractions of the cost of commercial alternatives?” Fundamentally, we believed that this open source magic had less to do with the fact that open source software is free. Rather, we believed that the ability to create market pervasive and high quality robust software at a fraction of the time and cost had everything to do with the following guiding principles:
- Transparency: The unrestricted transparency and ability to easily access, collaborate on, and extend a software application “in the cloud” from anywhere on the planet
- Collective Intelligence: The passion and leverage gained by enabling any developer to discover and extend another developer’s applications, resulting in capabilities far greater than what they could achieve by working in isolation
- Process Codification: A platform architecture into which collaborative software development processes, such as continuous integration and delivery, can be codified into repeatable and shareable tool templates that can be instantly provisioned and shared across a global enterprise
- Cloud: A web-based platform that breaks down the barriers of silo’d and loosely integrated tools and development processes that is optimized for distributed and collocated software development teams
- Openness: A flexible and extensible development cloud that drives a culture of collaboration across enterprises utilizing a heterogeneous mix of tools, processes, and technologies, while addressing an array of industry and design team objectives
- Community Architecture: A hierarchical development “forge” into which companies can map their projects and IT assets into business lines and technical architectures using flexible project hierarchies
Extending Cloud Development to the Enterprise
We sought to extend this open source magic by providing a platform which incorporated the above guiding principles to commercial enterprises. We wanted to provide developers and CIOs alike with the development productivity, cost reduction, and governance enabled by the “cloud,” although we didn’t know what to call it back then. There weren’t any analyst magic quadrants or fancy marketing terms for what we were trying to accomplish at the time. We just knew that we needed to improve distributed code development. So we started first by architecting and then releasing Subversion as open source as it improved on the weaknesses of CVS for collaborative software configuration management over the web. But something more was needed: The open source development practices and objectives outlined in the bullets above needed to be codified into a complete a set of agile application lifecycle management (ALM) tools and development processes, which could then be applied to provide commercial benefits to enterprises around the globe. Since launching cloud development in 1999, the global adoption of these principles within enterprises has been impressive; so much so, that I can now knock on the office doors of developers and CIOs alike and simply say “agile development in the cloud” and we commence an immediate, constructive dialogue on needs and vision.