Andrej Koelewijn

The cloud is enabling smaller teams to do more. IAAS enabled DevOps. Self-service infrastructure enables developers to take on operations. Developers can create and manage complete virtual-datacenters as required for their applications, without interacting with operations. This significantly increases productivity and speeds up time-to-market.

PAAS is now a big boost for NoOps. Operations is handled automatically by the platform. Developers no longer have to manage infrastructure. They can just deploy their applications. You just build, deploy and run. The result is even more productivity, and faster time-to-market.

These are all great developments. The biggest risk to project success, delivering requested functionality on time and within budget, is coordination and collaboration of large team effort. The bigger your project, the higher the risk of going over budget and over time, without actually delivering what users need.

Collaboration with operations used to be like this. Me: “i need a continuous-build server.” Them: “Why do you need to introduce something new? How big does it need to be? What software does it need to run? Does this software comply with our standards? We don’t have anybody available to manage this software right now. We first need to send somebody on a training to be able to manage this. We can have the hardware in three weeks, and it’ll take two weeks to install all your required software.” That’s a long time for something I could have installed in half a day.

Removing project dependencies, collaboration and coordination should be main priority for architects. Don’t try to design the whole system. Try to specify modules that can be created independently. The goal should be to get rid of large projects, by replacing everything with small projects, that don’t need to coordinate their efforts.

On most large agile projects you see a lot of upfront design and coordination, followed by small agile teams doing implementation. At the end of the project all the separate components are integrated, and tested.

The following image shows what I mostly encounter in larger projects working with multiple agile teams. In this example, four agile teams are working in small iterations, within a waterfall project.

Before IAAS and PAAS one (or more) of those blue teams would have been operations working on ordering and installing the infrastructure needed for your project. If one of the four agile teams has problems and delays this impacts the whole project, as testing and deployment is delayed.

When you remove dependencies and the need for coordination between teams, you may get the following. Four teams delivering value for the users independently. No need to create an overall spec, overall design or do overall testing afterwards.

This was one of the points i tried to make in my presentation for LAC2011: Scrum under Architecture. To do large scale Agile and Scrum you need to define teams and projects that can operate largely independently from each other. Every team should be able to have its own product owner, managing an independent product backlog and release calendar.

Turns out, Jan Bosch did a keynote at LAC 2011 on this type of architecture: Speed and Innovation through Architecture. He calls it composition oriented software engineering or Architectural Compositionality.

Speed and innovation is triggered by having an ecosystem of independent components. Every component team is self-directed. The product owner of each team has to determine the backlog of the project based on what he thinks the users of that component need. User can be internal or external. Big projects should not try to coordinate efforts from multiple teams. Instead they should just focus on adding a little extra on top of existing results from other teams.

In the illustration above, the blue team does three iterations to build something using the results of the other, gray, teams. The blue team could be a team implementing a mobile store application. It uses already delivered results of the product catalog team, the order entry team, the shopping-card team and the customer registration team.

By not trying to coordinate effort of all five teams in one project, but just using what has already been delivered, the project can be delivered much faster, and with less risk. At the same time each team can focus on improving their own component.

IAAS and PAAS are proving that small teams can be very productive and fast. The key element here is less coordination through self-service. Even if you’re not considering moving to the cloud with your IT, self-service and composition oriented architecture should be a priority.