What Happens When No One and Everyone Owns a Product?
And how DevOps can help
Your company decides to bring a new digital experience to the market — maybe an application that allows a patient, during a doctor’s visit, to access the prescriptions they are filling at their local pharmacy. Or maybe an app that advises a driver on the parking spaces available in garages within a one-mile radius of the current location.
The idea is just a beginning, and hence fragile.
If your company takes a traditional approach to software development, what will happen next is that the idea will need to be funded, and with the shepherding of a project manager it will move from the shoals of uncertainty through plan, define, design, build, test and run phases. While this waterfall process was expressly designed for software delivery (and taught in university curriculum when I was in school), the cloud has changed the context.
Velocity, or rapid iteration and early-and-often shipping, is the rhythm of product development for a digital business. And what was once state-of-the art is now an ungainly process that cannot meet today’s requirements.
Does this look familiar?
That animation might make you snicker, and some may even cringe a bit, because it tells a typical story of a waterfall process where individuals from a variety of silos jump in and out of a project, generate the artifacts for which they are responsible and hand them off to the participant responsible for the next phase.
This graphic is an oversimplification — the human and team dynamics at play make the process anything but simple! The reality is that things get passed forward, backward, and sideways.
And perhaps the worst part is that the people working in their silos are incentivized to see the trees and not the forest.
They report that they’ve done their part, and in a discrete sense, this can often be at odds with the larger picture of bringing the software product to market. Not surprisingly, more often than not it yields unsatisfactory outcomes.
For example, application developers are usually rewarded for building features within a particular time period. Quality assurance (QA) on the other hand, is most often measured — and rewarded — by the number of bugs they fix.
When development schedules get tight, developer teams start working unsustainable hours. They might spend less time writing automated tests, in order to stay on schedule, so the quality degrades. As a result, QA finds more bugs, for which they are rewarded. The silos are locally optimized, but the global outcome of releasing a feature-rich, robust, and stable application is often more difficult to achieve.
The Gumball Machine Team
I’m betting you’ve heard the concept of product teams. In contrast to the project teams described above, product teams draw together a range of different skills and responsibilities to execute against a goal, where the incentive for the entire team is to reach that goal and deliver customer and business value.
Okay, so all of this makes sense at the high level, but as with anything in execution the devil is in the details. The first question you might ask is “What skills do we need to bake into a product team, and where do I get them?”
The answer to the second part of that question is simple: you already have most of the ingredients. They’re the folks in your current silos, whom you have to regroup in a different (product) context.
For the first part of the question, as with many things the answer is: It depends. You weigh a number of factors, the most important one being that everyone understands the product they are building and — spoiler alert — running in production.
Pivotal helps clients work on two different classes of product, and we correspondingly advocate for two basic kinds of product teams.
New Tribes: Application and Platform Teams
One class of products are the applications you want to build for your constituents: anyone from customers, suppliers and partners, to colleagues. Let’s call the teams that build this class of products the application teams.
The second class of products are in fact a single product — the Pivotal Cloud Foundry® (PCF) platform. Think of PCF as a product that you “build” and operate to bring an entire ecosystem of development services to life. Wait. What? Pivotal builds PCF, right? What do you mean that I (the customer) would build and operate PCF?
So Pivotal is in fact building PCF by writing the code and producing releases that you drop into your data centers or cloud environments. But by standing up PCF for your application team users, or specifically by implementing required policies and practices within that instantiation, you are making it your own.
For example, you might want to write entries in an audit log every time an app is deployed, scaled, or upgraded, and you would do that by snapping that feature into the platform. Let’s call this team responsible for building and operating the platform — shaping it to optimize their workloads — the platform team.
The following diagram depicts the surface area they cover, and responsibilities of the application and platform teams. It’s not a coincidence that the lists look very similar — these are the DevOps activities of a team that is responsible for bringing products to their consumers.
With the stage now set, let’s come back to the question posed earlier: “For each of these products, what skills do we need to bring into the product team, and where will I get them?” Again, starting with the latter part of the question, here is a rough sketch of how IT might be structured at your company:
I’m betting groups like Enterprise Architecture and Chief Security Office (CSO), and the other groups shown here are familiar. So let’s have a little fun with all of these gumballs:
Let’s simplify and sort these roles into the right houses — starting with the houses being the application team and the platform team that I talked about above.
We can start with some roles from application design and development, and operations:
- From the middleware and App Dev group and going to the App Team, we have the software architect and software developers — from both the server and client sides. This first move is not controversial and needs no further explanation.
- The middleware engineer goes to the Platform Team. This engineer is responsible for the platform on which applications will be developed and run. It is where they previously installed and configured application servers such as WebSphere, JBoss, WebLogic, or Tomcat, and are now responsible for the buildpacks that are made available in the PCF installation. Since PCF natively supports Java, .Net, Ruby, PHP, Python, Node.js and GoLang, and there may be different middleware engineers configuring and maintaining support for these different frameworks, voila: to the Platform team.
- The final role we’ve moved over at this juncture is operations. In a great many organizations that I’ve spent time with, both application operations and infrastructure/systems operations are handled by one organization within IT. Developers wrote the code, helped with the initial deploy and after a short period stepped away from the day-to-day operations of their application.
- The DevOps movement has transformed all of this. It has not necessarily made the developer responsible for operations. But developers generally do participate in ongoing operations to a greater extent that they have before, and it is certainly the case that application teams take on the operations responsibility.
Notice that each of the product teams — both app and platform — take on the operations role of their product. We’ve taken what has been a single role and distributed it so that every product team now includes it as a first-class role.
It means that everyone on these product teams are responsible for the full lifecycle of the product. That is the scope of accountability in a modern platform era.
Note that there are many more roles and gumballs (including many important figures that aren’t in IT) that we need to sort into their appropriate houses, but we’ll save that for future posts. As an early release you can access a live presentation of this material recorded at our SpringOne Platform conference in August of this year.
Being a software-driven business with velocity requires a whole new toolset. Yet new technology alone is not enough. Reinventing processes to achieve velocity is essential, and so is wrapping new roles and teams around that (think Conway’s Law).
Finally, requirements like regulatory compliance or capacity planning haven’t vanished, but they take on new forms and are fulfilled by amended roles. What we’ve seen in this post is just the beginning.
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced and incorporated continuously through development and innovation, because good software is never finished.
