Going Cloud Native - From Silos to DevOps

In the Cloud industry the concept of the 'Cloud Native' enterprise has emerged to encapsulate the new innovation-driven software practices like Microservices and Continuous Deployment.


The Pivotal-sponsored ebook 'Migrating to Cloud Native Application Architectures' is notable not just for the fact it proposes shifting to a Microservices architecture as part of 'going cloud native', but that also the shift requires a significant organizational change too.

Business Capability Teams

They characterize this as the shift from 'Silos to DevOps', a new organizational model underpinned by a concept of 'Business Capability Teams', a pattern that guru Martin Fowler describes as breaking up a monolith software approach instead into product-centric, self-organizing teams.

Although the conversation about DevOps typically focuses mostly on the tool sets and platforms - Puppet, Docker, Microservices et al, the more profoundly challenging aspects for most large organizations will be in the organizational transformation that is proposed to be part of the 'Cloud Native' mix.

DevOps Team Roles

In this Medium article Pivotal expand on the detail of the Roles that a DevOps team should feature:

  • Developer/Engineer
  • Operations
  • Product Owner/Product Manager
  • Designer

These are roles that are not always needed and sometimes be fulfilled partially by shared, but designated to the team staff:

  • Tester
  • Architect
  • Data scientist
Scott Prugh - CSG - DevOps and Lean in Legacy Environments
Scott Prugh - CSG - DevOps and Lean in Legacy Environments

The Inverse Conway Maneuver

DevOps sets out to break down the artificial boundaries that develop profusely in large, hierarchical organizations, and instead self-organize around a 'delivery pipeline' of the work required to deploy code faster and with fewer errors.

In short a 'Lean' system, one with zero process waste.

They reference the intriguing 'Inverse Conway Manever' to describe this transformation from a silo-based organization to one optimized for DevOps.

Scott Prugh of AMC explores this transformation in this Slidedeck.

Organized around Business Capability Teams

This is a common sentiment among the industry experts.

As Martin Fowler describes monolith software systems tend to have their teams built around only the technologies they manage, whereas microservices encourages teams to be end-to-end responsible for the products they deliver.

Both call this an effect of 'Organizing around Business Capability Teams'.

On page 21 in the Pivotal paper they describe these organizational units, within the context of Conway's Law:

"The theory behind this reorganization is the famous observation known as Conway’s Law. Our solution is to create a team combining staff with many disciplines around each long-term product, instead of segregating staff that have a single discipline in each own team, such as testing. "

Dave Syer of Pivotal explores the transformation to BCTs in this online presentation.


IPUs - Integrated Practice Units

What is particularly exciting about this approach is that it reflects the same design goals as Michael Porter's 'IPUs' - Integrated Practice Units, and discussed in detail in this presentation.

Although this dynamic team model has been focused almost exclusively on the Healthcare sector to date, it is by no means an industry-centric approach, rather an entirely generalized organizational unit design, in the same fashion as the DevOps Business Capability Teams.