Software development is a complicated topic. For years, industry leaders debate regarding which philosophies, practices and processes can be adopted to increase the chances of achieving success.
Out of the multitude, two fairly popular contenders seem to be strong opposites: DevOps and Platform teams. While both take a stance regarding some aspects of team shape and company structure, they seem to recommend incompatible solutions.
A little more about them
Before we continue exploring the topic, let’s take a moment to define what we are discussing.
DevOps
DevOps is a philosophy that recommends a cyclical approach to software development, where a team builds, deploys, and monitors an application, learning from these activities in order to plan their next cycle of changes.
It emphasizes high-autonomy (and responsibility) of teams, with the understanding that all activities that the team engages in drive the learnings required to improve both the application and the health of the team itself.
Platforms
Platforms recommend centralizing knowledge and expertise in specialized teams, then leveraging these centers of excellence to accelerate the activities of other teams.
The centralized nature of platforms serve to remove the burden of decision-making, learning, operating, and monitoring out of the individual teams. It also facilitates standardization across a company.
Two faces of the same problem
Like so many other trends in the industry, these two create problems that the other seemingly solves. As companies apply them, the pendular nature of these practices start swinging from one extreme into the other. And then back again.
However, unlike other similarly pendular trends, the forces that energize this motion are not products of the software craft. They are related to the environment in which software development is practiced, specifically, commercially-driven software development.
Yes. This is yet another one of my articles where economics slither into the conversation.
When the pendulum swings
The things that popularize DevOps and Platforms are different in nature. In very simple terms, DevOps empowers teams to address a problem of quality, while Platforms empower organizations to address a problem of scale.
DevOps is energized when teams:
- Suffer from quality issues, due to the distance between their mistakes and the learnings that can be derived
- Suffer from delays, due to dependencies on saturated centralized teams
- Suffer from sub-optimal solutions, due to a lack of autonomy to choose the best solution for their problem
Platforms, on the other hand, gain traction when companies:
- Suffer to address issues across the company, like security, regulatory or legal risks
- Suffer with wasted efforts, as multiple similar solutions are created for similar problems
- Suffer with sub-optimal staffing, as multiple teams require varied expertise in multiple areas to operate
The fallacy of the assembly line
I should probably dedicate an entire article to this aspect of software development, however, it is essential we touch upon this point before going further.
Software development is not a procedural activity that can be chunked and delegated to the cheapest bidder. It is a highly creative process that requires expertise and strong communication to yield results.
Treating software development like an assembly line does not work. Attempting to replace parts of the process with cookie-cutter solutions or assigning work to specialized teams may work in manufacturing, but it doesn’t work for software.
Despite this being true, the economic incentives are too tempting. While the results of extreme centralization and standardization are often of lower quality, the cost involved is much lower. And due to the risky nature of software, for some companies the cost reduction justifies the drop in quality.
So, what is the right choice?
Platform teams are now being hailed as the best solution by folks who failed to acknowledge the problem. There is no right choice. At least not without considering the multiple facets of your situation. However, because I want this article to be more than just a rant, I propose we evaluate the options along the following axes:
Team size
Smaller teams are likely to outperform their larger counterparts when switching between approaches.
Larger teams may be able to support a split into two small teams: one to tend to the application and one to build or maintain a platform.
Domain complexity
Simpler domains favour DevOps to unlock innovation, while more complex domains may benefit from offloading cognitive load to a platform team.
Expertise
Teams with narrow knowledge struggle when switching approaches. Teams with wide knowledge succeed in either environment.
Teams that work as platform teams tend to specialize, narrowing their knowledge.
Criticality
Highly critical applications are always problematic.
Platform teams compound the criticality of their dependents, which may harm innovation.
If a mature and stable platform is available, choosing based on the domain complexity is a good idea. Otherwise, DevOps approaches lead to better results.
Innovation
Teams that practice DevOps are more likely to innovate, but platforms team might have more impact from their efforts.
Teams that practice DevOps are also more likely to deliver results earlier, and are quicker to uncover unknowns.
Closing thoughts
While I’ve painted a picture of clearly defined archetypes of teams, most teams don’t fall within these extremes. The changes in approach are not only natural, they are probably the only choice that can be made when balancing effectiveness, quality and cost in a reactive manner.
Additionally, there are not only two options when addressing this problem space. For the sake of exemplifying, a “further than platform” approach that only relies on Platforms-as-a-service and Service-as-a-service products may be viable in the right conditions.
This is exactly the success story of some notable startups that prioritized market penetration and validating their business instead of technologically-sound implementation. It goes to show that the right choice may be outlandish, but make sense if you have no idea if your company or application will survive another day.
Finally, companies that failed to fully implement DevOps teams are very likely to be dependent on pseudo-platform teams. This is not inherently bad, as long as they are not being led based on popular opinion. Leadership in this position must not only make a decision, but preserve their reasoning in hopes of withstanding the next cycle of the pendulum if they wish to reap the benefits of either approach.