Why application developers are now strategic ‘gold’
Continuous Delivery is helping to solidify the role of developer operations at the heart of the modern company’s business strategy.
It has become one of the common caricatures of application developers that they are disheveled, bearded and be-sandled individuals usually found locked in the basement of companies, where they are tended by trained handlers throwing in pizzas and cans of cola at regular intervals and extracting finished code every now and then.
The truth is developers are moving centre stage as a core part of business strategy for a growing number of companies. What is driving this change, where developers are key instruments in business success? And the culprit is called… Continuous Delivery.
Continuous Delivery (CD) is a natural evolution from continuous integration and agile software development practices, extended to the complete application lifecycle. IT groups are usually structured around well-defined functional silos: development, QA, IT operations, etc. Continuous Delivery breaks those barriers and is instead structured around the notion of “business projects” with the team responsible for all aspects of the project: from feature definitions, objectives, implementation, delivery to production, support, monitoring, etc. There is no “us vs. them” anymore, there is a unified team aiming for the success of the project.
Furthermore, a key tenant of Continuous Delivery is for software to always be in a release-ready stage: software gets implemented in increments, pushed to production in an automated fashion (the decision to push must not be automated, just the delivery process itself) and the result measured against planned objectives. Based on the learning, the feedback loop restarts by increments. Continuous Delivery reduces the time it takes for a feature to hit the front stage, reduce risk and increase quality. It is also an incredible motivating factor for teams, feeling they can have a real impact on the business, unlike in their previous silos.
As such, Continuous Delivery is obviously the driver behind the demise of the nine-month to two-year application development release cycles that have been the staple of IT for too many years and that have led to well-publicised, “stranded whale” projects. That is, projects that ballooned out of control and then were shelved and branded as a failure, months or years later.
The timing of the strong growth of Continuous Delivery in IT shops is no coincidence. This practice fits well with the boom in mobile device usage, along with the increasing penetration of Software as a Service (SaaS) applications. In both cases, teams have the possibility to push new versions of their software in a continuous fashion, without having to wait for their customer to install it. The benefit is the same for the application users: they reap the full rewards of Continuous Delivery by always using the very latest versions of applications, delivered as soon as the developer releases them for delivery. That being said, Continuous Delivery also works well in on-premise installations or even with embedded systems: everybody benefits from reduced release cycles, shorter feedback loops, reduced risk and increased quality.
Faster and more frequent release cycles mean that every developer can make a real difference to the business and its top line. In an environment where markets and trends are in a state of continual change and development, companies now face a world where an application that worked well last week may be lacking some competitive edge this week, and hopelessly out of date next week.
SEE ALSO: The biggest challenges facing DevOps
At the heart of this now lies both a challenge and opportunity for business managers. The opportunity is the advantage Continuous Delivery can bring to the business in helping it to deliver the best possible applications to customers at all times, not just every one to two years of a traditional development cycle. It is, in fact, a very simple, circular equation – businesses need the best application NOW: they will turn to IT to provide it and IT can’t afford to release a year from now, the software that was needed a year ago. With marketplaces changing so fast these days, every day is a new NOW for customers, and IT needs to understand this in order to respond effectively.
The challenge is that business managers must learn to “appreciate” the need to integrate developers into the mainstream of business management and start involving them in operations discussions and processes. Developers are now the key component in quickly implementing the important business strategy of keeping users up to speed with the latest developments, as they are defined.
A core issue of this is that the structure and culture of the organisation – including between both developers and business managers – will need to change to encourage each to reach out to and understand the other. And yes, developers will have to learn that ‘cool technology’ for its own sake does not always grow the top line of a business.
Reorganising a cultural change
There does now need to be a reorganisation of legacy development and LOB management teams in order to execute on a Continuous Development-based business strategy.
Such cultural change also brings with it a variety of new operational possibilities. For example, is there now a place for the development team to be in more direct contact with customers? A lot of the time the contact will come from the staff whose job includes being out in the field, in regular contact with the customers. But there is a possibility that having developers in direct customer contact, for example during the beta testing of a new application, could reap real benefits.
While enterprises will have to solve their organisational and cultural issues in their own specific ways, CloudBees, thanks to its Jenkins-based product portfolio, is focused on making sure you get the right tools for the job and for putting Continuous Delivery in its right place: at the heart of your business strategy.