Blog Platforms as a Product: Turn Your Barriers Into Enablers
By Brad Nelson / 16 Dec 2022 / Topics: Agile DevOps
I was having breakfast this morning with a friend and fellow Agile practitioner when he dropped some profound knowledge on me, as he often does. “The Agile Manifesto should have just stopped at ‘We are continually uncovering better ways of doing things.’ Boom. Full stop,” he said over his oat milk cold brew. He, of course, was paraphrasing the very first line of the Manifesto for Agile Software Development, which states, “We are uncovering better ways of developing software by doing it and helping others do it.” This line is often overlooked for the more popular four values. This is a great place to start the conversation on Platforms as a Product because the concepts of platforms and platforms as a service and products are not new, and yet I see a flurry of angsty and click-bait titles out there stating that “DevOps Is Dead” because of this new concept that is picking up steam. This, however, could not be further from the truth. In fact, Platforms as a Product is just the next evolution of the DevOps movement (which is also under the umbrella of Agile software development) where we are starting to leverage product thinking to uncover better ways of working.
DevOps started as a hashtag.
I love reading up on and sharing the history of things like Lean, Agile and DevOps. None of them just magically materialized out of thin air one day. They all have a history of evolution built on compounding ideas and needs. The word itself, “DevOps,” can be traced back to Patrick Debois and John Allspaw in 2009 as this notion that development and operations engineers needed to cooperate to unlock an organization’s potential to deliver software to production more frequently. This concept of bringing people together from multiple expertise is not new and has previously been referred to as cross-functional teams, T-shaped teams or multidisciplinary teams, which easily dates back a hundred years or more.
Moving on, since the term DevOps has entered our industry vernacular, its subject matter has continued to expand — as demonstrated by the frequent referral to DevSecOps recently (as well as CloudOps, ModOps, InfraOps, ProdOps, DesignOps and so on). The engineers in the DevOps space have come to appreciate three principles, known as The Three Ways, which are flow, feedback and continual learning. By embracing these principles and applying continual learning to increase flow and feedback, the DevOps community has realized that there are more and more concepts, practices and methodologies required to improve our ability to develop these high-performing teams capable of fast, iterative deployment. Or, as I stated earlier, “We are uncovering better ways of developing software by doing it and helping others do it.” Therefore, it is quite natural that DevOps would expand to include product thinking, which is equally reliant on the experimental nature of the iterative process.
What is a platform?
A platform can be hardware and software that is used as a foundation upon which other technologies are developed. Common platforms include infrastructure, middleware, cloud services, search engines and more. Since I started working in corporate IT, these are things that I have frequently had to deal with and often with great frustration. That is because organizations typically have these platforms supported by teams, and even departments, outside of the development teams I am working on. This results in bottlenecks and handoffs that stagnate flow and hinder teams from being able to deploy to production quickly. In Agile, we refer to these teams as component teams. It is not uncommon for organizations to have multiple component teams, such as user interface, services and middleware.
Due to this huge barrier to productivity, many Agile practitioners and DevOps engineers have become strong advocates for organizing teams around products and giving them full access and autonomy to deploy code across a full stack of technology (cross-functional teams). Organizations that have adopted this approach to software development have generally seen value in this approach, and it is a core concept in Continuous Integration and Continuous Deployment (CI/CD) pipelines. However, while this practice is incredibly beneficial, companies tend to experience challenges and complications, especially as the organization scales. Teams can become bloated, productivity slows to a halt due to too many priorities or to supporting too many applications, knowledge is not shared between teams, teams are re-solving the same problems and/or developing the same tools, and organizations are paying for multiple instances of tools or for multiple tools that accomplish the same things.
Applying product thinking to software development
As organizations move from a project and even individual approach to development to more product-oriented and team-focused development, one beneficial exercise is to define the boundaries of their product ecosystem. It is natural to think of a product as the user interface, but when looking at full-stack development, there are multiple components often involved in a working application. This can be a little bit of an art, and I would encourage experimentation, but value stream mapping can be a great start to identify the boundaries of a product. From there, the cognitive load of the team decreases and focus increases by organizing teams around these value streams. These teams are known as stream teams or product teams. These teams must be able to deliver from ideation to production. If they cannot, then they are once again component teams.
What organizations typically find when doing this exercise is that an application within this new structure supports multiple streams, and multiple streams are leveraging similar technologies to accomplish their solution. A great start is to have teams build and maintain sharable libraries to reduce the need for reinventing the wheel. Similarly, enterprise architects might create an Allowlist of accepted and supported tools. However, what soon follows is that entire sets of code require more and more attention. Now the stream teams are spending more time managing these shared resources than solving the problems the business needs them to be solving. At this point, it may be worth considering forming a team that solely supports those components.
Platform teams are not component teams.
I purposefully used the word “component” there because there is a slightly nuanced but very important distinction between the old way of having component teams as barriers and truly embracing platforms as a product. When a circle is drawn around a platform and it is identified as its own product, it needs to be treated as a product. That means that the other teams that use the platform need to be able to self-service that platform. That is not to say that the platform never needs new development for a team, but the internal development teams are the platform’s customers and therefore should not have to wait for development work to be able to use the platform. If every request to use the platform results in a support ticket or a spot on a roadmap, it is a component, not a product. It is up to the platform product team to understand how its users, the stream teams, are using their product and what needs their customers have in the future will feed into their own product backlog. This is no different than when a team uses a third-party Platform as a Service (PaaS), Software as a Service (SaaS), or Infrastructure as a Service (IaaS). The difference is that the service has been internalized instead of paying another company. This is what it means to have a Platform as a Product.
Organizations have had great success by applying product thinking internally and embracing the Platform as a Product mindset. Companies that adopt this approach realize decreased Time to Market (TTM), lower overall costs due to FinOps, fewer production defects and reduced developer burnout. I made the argument for a platform team for a services layer that supported native apps, websites and point-of-sale systems at a Fortune 500 grocer, and likewise, I worked with a platform team that supported the base architecture that a Fortune 500 health, beauty, and home care company used in its Research & Development department to support multiple Internet of Things (IoT) mobile apps. In both instances, the teams that used their platform product were able to incorporate and build off those platforms without requiring any work from the platform teams that supported them. Then, as new feature development emerged that required the platform to introduce new functionality, the Product Owner (PO) of those teams met with the PO of the platform team to make a request. The platform team’s PO would then decide if it was valuable to add that functionality to the platform and compared it against other competing priorities — just like an external supplier would do.
Platform as a Product is the next evolution of DevOps.
With this explanation, hopefully, you as the reader now understand not only the benefit of Platforms as a Product but that there is no competition with DevOps or Agile. In fact, both your platform product teams and your stream product teams will still be using the tenants and tools of DevOps to best serve their customers. It is just as important to focus on flow, feedback and continuous learning to deliver valuable software to your customers and to uncover better ways of developing software. Lastly, if your organization is small, you may not need platform teams, but if your organization is fairly large, it might be valuable to have multiple.
Achieve your digital transformation goals. Explore our capabilities to architect, implement, manage and secure innovative IT solutions.
Brad Nelson
Product Strategy & Agility Manager, Insight
Brad Nelson is a manager of product strategy and agility with Insight Consulting Services. His practice partners with organizations to build effective delivery structures in which people and products thrive. Brad has repeatedly demonstrated his ability to grow high-performing teams across domains and industries. He is the co-creator and steward of Insight's DevOps offerings, host for Insight's Agile Series, and has instructed countless people from kids to seasoned professionals.
