Developing Software at the Speed of the Cloud

Developing Software at the Speed of the Cloud

          
Title image

Developing Software at the Speed of the Cloud

  • Add To Interests
  • SAVE CONTENT
  • PRINT
  • PDF

  • Ahead of the Curve
    Living Software

    To build cloud software, it’s not enough simply to create new organization structures and roles that facilitate continual development and constant updating. Companies also need a software architecture that allows cloud teams to move quickly and independently.

    A cloud “product,” in fact, often consists of literally hundreds of microservices. Cloud development organizations create small teams—usually, just 10 to 15 members—that are responsible for a specific software module or service. The teams are able to release their software independently. If a service needs a larger team, then it probably has not been broken into small enough component parts. 

    Team Composition

    All software teams are not staffed equally. Teams follow the same principles, but their composition will vary significantly depending on the type of software under development. In our research, we found that software can be grouped into four archetypal categories on the basis of the complexity of customer interactions and who (the company or the customer) controls software deployments.

    A common benchmark of software development teams is the ratio of traditional developers—whom we call “feature engineers”—to other members of the team. As Exhibit 3 illustrates, these ratios can differ greatly depending on the
    category.

    exhibit

    When a software team internally controls an application or a service, such as consumer cloud software, developers can directly write, launch, track, and adjust code without engaging with the customer. This reduces the need for end-to-end quality engineers, as illustrated in the boxes on the right side of the exhibit.

    At the other extreme, when the customer controls and deploys the application or service, as illustrated in the boxes on the left, feature engineers have less ability to modify the software after launch and must address a more fragmented user base. Accordingly, end-to-end quality engineers are necessary to serve as a proxy for customer needs and to monitor deployments.

    This model applies to the individual microservices that compose a product, not to the product itself. A single product will frequently have services that fit within all four categories. For example, the team launching an app on the iPhone will have a very different composition from the team responsible for launching the app’s underlying server infrastructure. 

    Modular Architecture

    To support such decentralized team structures, cloud development organizations build loosely coupled software modules that interact seamlessly with other modules. The loosely coupled modules typically sit on top of stable infrastructure software. This approach allows developers to work flexibly—adding, replacing, and changing individual modules while maintaining high quality and reliability.

    In this environment, teams are no longer forced into large-scale monolithic annual or quarterly release dates. Without the need to manage complex software integration, cloud teams can release features as they become ready. Features not ready for prime time are “toggled” off in order to control what the customer sees while preserving code integrity for easier version control.