BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Replacing Orchestration by Autonomy to Speed Up the Software Delivery Cycle

Replacing Orchestration by Autonomy to Speed Up the Software Delivery Cycle

This item in japanese

Software delivery in a modern company requires autonomy to make releasing software easy. Niek Bartholomeus gave the presentation orchestration in meatspace at the DevOps Summit in Amsterdam:

Traditional enterprises typically rely on a lot of orchestration to deploy their software, which makes the whole process slow and error prone. How can we move them to a more autonomous approach, in order to speed up the feedback cycle from idea to production?

Niek started his presentation by exploring the problem space. In traditional organizations decision making is centralized at the top of the hierarchy. For technical decisions this is far away from the teams where the knowledge is in the organization. Also the communication between the layers delays decisions and hence delays development and delivery. Standardizing the work flows and job specialization creates functional silos which further delays delivery. Finally tightly integrated applications pose a risk for chain reactions when an application is changed. Managing dependencies with planning and company wide releases as is done in traditional organizations result in long release cycles with systems that contain many changes and are difficult to deploy.

The personal theory from Niek is:

Automating business processes is complex, creative, and dynamic. Therefore we need a quick feedback cycle from idea to production. Which can only work when releasing software is easy. For this we need autonomy.

Autonomy according to Niek means that development teams that can build new features without relying too much on external dependencies. This means that these teams have to be as self-sufficient as possible for all services or technologies that are needed to do the work. By creating cross functional teams you can make team more autonomous. Teams are able to take decisions. Technical decisions should be made inside the team by creating self empowered teams.

To build a solution for the problem on a scientific foundation Niek referred to publications by Henry Mintzberg on the structuring of organizations. Mintzberg defined 3 mechanism for coordination: mutual adjustment, direct supervision and standardization. Traditional enterprises often rely on the last two, when you want to shorten the feedback cycle between idea and production mutual adjustment can be a better mechanism.

Mintzberg described common configurations of organizations, some of them are the administrative bureaucracy, professional bureaucracy and adhocracy. For work that is complex, creative, and dynamic like automating business processes an adhocracy would be the most suitable configuration, said Niek. Most traditional enterprises however are organized as an administrative bureaucracy.

At the DevOps Summit Niek presented steps that enterprises can take to change from a administrative bureaucracy to an adhocracy:

  • Enhance the existing communication flows by defining a simple and consistent software delivery process and automate that where possible. To orchestrate this a tool is needed to manage development requests, group them for deployment, handle versioning and build releases.
  • Increase the autonomy between the development teams. For instance you can make applications backward compatible to reduce dependencies. Niek presented how you can do this following the expand/contract pattern.
  • Increase the autonomy between components of the application. You can use feature flags to drastically increase the feedback cycle, but to avoid downtime during the deployment the individual components of the application must also be made backward compatible.

Niek concluded his talk by stating:

We have to move from the traditional separation between dev and ops to a separation between creative and automated (or standardized).

Functional and operational evolutions of the app are done in the “creative” side. Repetitive work (i.e. traditional day-to-day ops work) is automated in the “automated” side.

Rate this Article

Adoption
Style

BT