Better Discoverability with SDLC-Oriented Product Architecture
"Principles of design:
1. Use both knowledge in the world and knowledge in the head.
2. Simplify the structure of tasks.
3. Make things visible: bridge gulfs between Execution and Evaluation.
4. Get the mappings right.
5. Exploit the power of constraints.
6. Design for error.
7. When all else fails, standardize."
- Donald A. Norman, The Design of Everyday Things
"Fragmentation" and "Discoverability" are two commonly experienced product problems with Internal Developer Platforms. "Fragmentation," related to the "Local Optimization Problem," means the products or services the Platform provides don't fit together well. As a result, customers spend significant effort to figure out how to get fragmented products to work together. "Discoverability" refers to a customer's ability to find products and applies to both new developers looking to see what products are available and experienced developers who want to know when something new and better is available.
In this post, I will review examples of places that have made meaningful improvements in solving these problems by applying DevOps lifecycle or SDLC stages to their product architecture and why this is a good solution. Also, there are other ways Internal Developer Platforms architect their products, and we'll see a few other conventions that make sense.
Example: Netflix
Danny Thomas talks about how Netflix has a Developer Productivity group with three domain-oriented teams aligning to the significant parts of the SDLC engineers go through:
"Developer productivity is split into three domains. So we have the develop domain, which is what I work in, and that's everything in the local development loop -- bootstrap, development, test -- everything up until you push code pretty much...then there is delivery, so they're the folks that do continuous integration and continuous delivery and then...operate which is metrics, telemetry, logging, everything you need once your service is up and running and you're keeping the lights on."
However, the structure alone isn't enough to solve fragmentation:
"...pretty much every domain has an experience team as well, and so one of the weaknesses of our developer experience today has been we have a whole bunch of great individual tools that make up what we call the paved road...but we've found that the seams between the tools, the way they integrate, these abstractions can be very leaky and it's easy to fall through the cracks when you hit a roadblock, and we've seen this particularly when we're onboarding new folks."
From this, we learn that structuring around SDLC phases helps determine the right paved paths or tools to build and deliver, but fragmentation is still an issue.
In "Unifying the Netflix Engineering Experience (DX)," Brian Leathem talks about the work Netflix is doing to address fragmentation. He provides a screenshot of how Netflix structures its products through a Developer Portal:
It's grainy, but the navigation is as follows:
Discover By:
Capability
SDLC Stage
Primary Role
Organizations
All Products
Learn
The Paved Road
About the Site
Share Feedback (links to Slack)
Listening to the customers and what questions they ask provides paths to discoverability that also reduces fragmentation. By discovering via "Primary Role," for example, or different journeys across SDLC stages, different patterns can weave together to provide a more holistic path. We see a similar approach from RedHat.
Example: RedHat
A March issue of the Platform Engineering Newsletter described the four pillars of their Internal Developer Platform product architecture that RedHat use:
Onboarding. This includes all the tasks a developer must do to get their team and application on the Platform. First impressions matter, so make it count!
Code time. A quick workstation setup and a fast and reliable inner loop improve both developer experience (DevEx) and productivity.
Build time. A comprehensive and reliable CI/CD process is one of the most important components of team productivity and application reliability.
Run time. Teams need self-serviceable and observable infrastructure in order to be fully autonomous.
I reached out to one of the presenters, Natale Vinto, who explained that they align journeys and deliver opinionated patterns through those domain pillars to implement the journey a customer or persona travels, which is not that dissimilar from the SDLC-enabled discoverability Netflix also presents.
Why do these approaches work?
The approach works for two reasons:
First, it structures products using a mental model the customers already use, so there isn't a need to teach a different convention. The structures are informed from listening to the questions your customers ask. As we can see from the Netflix example, engineers may ask where products exist based on SDLC, Capability, Organization, or role/persona.
Second, it standardizes a "product" and how they combine into journeys. Backstage provides paths to create templates for different types of "entities" (APIs, services, webpages, etc.), so using templates to standardize products and where they exist establishes a convention. Both RedHat and Netflix extend standardization to combine products into “paved roads” to address fragmentation.
So, when thinking about the product architecture of your internal developer tools, ask:
What are the existing shared mental models and questions an engineer asks when looking for products? Do our products work in harmony with that?
What are the standards and constraints that define the edges of a product? How are they codified? Where are standards missing, and is there friction due to that?