Operationalize the Enterprise Developer – InApps 2022

In Part 1 of this series, I covered how enterprise developers were taking over the software development world, and pointed to some examples of platforms that enabled developers to deliver value more quickly. I then contrasted that with the current state of complexity faced by developers on a daily basis. In a bitter irony, developers have more choice than ever when it comes to platforms, frameworks, and tools, but it has come at the price of a diminished user experience. The paradox of choice, indeed.

While developers face a complex landscape, we have plenty of useful building blocks at our disposal. Perhaps more importantly, we can streamline our developer workflows by following better practices. In the short term, we can make better use of what we have and invest in more efficient processes that drive improvements to our existing continuous delivery tools. As a longer-term solution, we’ll look at some potentially useful technologies that may represent a major leap forward for the developer experience. But for now, let’s figure out how to turn these lemons into lemonade.

Be More Boring

First, the boring stuff–make reliable platforms. You can’t operationalize your development workflow if the tools and platforms are unreliable and don’t perform up to expectations. Make sure your developers can easily make the best use of your platforms. If you solve for 90% of your users, you can more easily create systems that streamline governance, accountability and compliance. The other 10% can build their own systems of accountability and governance as long as you provide them a way to tie into core APIs.

In order to accomplish the above, you’ll first need to make your platforms boring. There’s a lot to be said about innovation and where it should occur. Experimentation is great if it’s segmented away from core systems. Again, you want your application developers innovating and experimenting on things that add value, not things that could interfere with your business operations. Use what’s available. Don’t create or recreate your core platforms. If you feel a strong urge to build leading-edge platforms, start by asking your developers what they need. Building platforms that add more than what existing vendors already provide is a tall order–one that is quite difficult to surmount. Instead, adopt third-party platforms that you know will work and innovate on the application layers.

Software Supply Chain

Next, you’ll need to understand how your development happens. Considering that in many engineering shops, a high percentage of your software is open source, we need to stop thinking of our engineering efforts as “creating” and more akin to systems integration. We are assembling parts, piecing them together, and polishing them for end users. I find it useful to place this development in the context of a software supply chain funnel that generally moves from the left (raw, upstream components) to the right (finished product). [see diagram]

As developers take these open source components, they either apply them as glue onto an existing developer platform(s) or make the glue binding components into a developer platform. At this point in open source ecosystem maturity, most of the developer platforms already exist, as do the upstream components platforms are composed of. Usually, product development sources and situates the right components and platforms, gluing together products and services for end users. From existing developer platforms, a little code can build new platforms.

“Shifting left” is one key to better product delivery. That is, in order to make a great release, you need a great developer platform. And in order to have a great developer platform, you need better upstream components. Work upstream, improving and influencing the direction of the components you build with, and then use them to create better end products.

I probably wasn’t the first person to talk about actively managing your open source software supply chain, but I’ve been advocating for this since at least 2014.

The left-to-right flow this implies isn’t always as simple as it looks, however. This diagram has bidirectional movement at every stage–continuous feedback and improvement is essential to evolving the raw components, developer platforms, and end product. In this model, upstream movement is necessary to both efficiently manage technical debt and improve the overall product.

While there may not be a turnkey solution that does this, per se, there are certainly tools and methodologies that can help. For starters, you should start out with the highest quality components. This means using a variety of scanning tools to detect and fix vulnerable code and bugs. You should also give your developers access to these tools as early as possible. Nothing is worse than completing 90% of a project before realizing that your building blocks need immediate patching or replacing. However, scanning is just one tool in the box–you also need to make sure your developers can fix or improve the components and apply them upstream.

Why is this important? To have an efficient supply chain, it’s important to offload as much of the daily maintenance as possible. If you apply fixes that only you have access to, then congratulations–you just became the maintainer of your own fork of an open source project. You are now responsible for applying any and all patches, rebasing when your fork gets out of sync, and keeping it all operational. That is one way to balloon your technical debt. In general, you should build your compliance checking into the developer workflow as early as possible, as often as possible. If your “boring platforms” rely on specific platform, component and design choices, it’s better to push those choices to the developer at the earliest stage possible.

As you progress through your product delivery stages, you should build the expectation of orthogonal integration and innovation into your processes. Your chosen platform(s) will not only support your immediate team, but also any other team that finds your platform stable and useful. To the extent that this requires reliability and security tradeoffs against the latest and greatest, be biased towards supporting the widest ecosystem possible.

Finally, just because you arrive at the release stage doesn’t mean you can stop improving the process or components used in development. Getting a product ready for release necessarily means learning about the gaps in your technology and process and empowering your developers to identify and fix both. What you learned during product development should give you insight into what to fix on the development platforms, upstream components, and methodologies.

So, if we wanted to break this down into steps, it might look like this, from the point of view of your developers:

• Provide access to pre-approved, sanctioned components, runtimes and frameworks
• Empower your developers to contribute fixes and improvements to their upstream development
• Push for standardization around approved, reliable and boring developer platform(s), supporting an ecosystem of developers and products
• Enable and advocate for efficient feedback loops between developer platforms and supported ecosystems
• When ready to release a product, ensure there are ample paths to provide feedback upstream to the developer platform(s), in addition to the upstream open source building blocks

Companies use a number of diagrams and flowcharts to document software development life cycles — this is another variation on that theme. I prefer this version because it demonstrates the need for bi-directional upstream maintenance extending beyond your employer’s four walls (zoom walls?); while most SDLC diagrams don’t. In fact, you could probably superimpose the supply chain diagram on top of your SDLC flow and get a pretty clear picture of your development process.

So, Where to Next?

If the above sounds like a lot of work, you’re not alone. Some day, some enterprising vendor or several vendors will figure out how to offer comprehensive services that solve many of the problems identified above. And then, we will tear it all down and build something new, because that’s what we do. We’ll rediscover all of those problems we solved previously in different contexts. This is the circle of tech life.

Until then, we automate, build our compliance into the workflow, reduce (some) developer choice, standardize on boring platforms and sustain upstream components by empowering your developers to contribute to them.

Featured image via Pixabay.