Music: The Jesus And Mary Chain - Happy When It Rains (1987)

This week we take a look at toolchains in platform engineering.

Getting Informed

A software toolchain is generally considered to be a set of tools used during the activities associated with the creation and modification of various programs throughout the lifespan of those programs. And just as programs can be simple or complex, a toolchain can be a simple or more complex set of tools.

So, if software is noshing away at the world around us, an equally awful analogous exercise is thinking of toolchains as a dentist office tray of instruments in a plaform engineering dentist office established to help developer patients maintain ever increasing collections of software teeth as new programs are born and age. 😬

And we tried so hard 🎶

Stepping away from dental analogies, toolchains referenced in platform engineering related content from cloud service providers (CSP) are increasing. Obviously, one can assume each CSP promotes a Cloud Adoption Framework (CAF) with references to tools — possibly with a bias towards their own.

Build a compliant multi-account cloud environment with enhanced security features, and packaged, reusable cloud products. Source: AWS

[…] your platform team must iterate through multiple cycles of building and development as they put into place your platform’s tools, scripts and capability enhancements. Source: Azure

Your developers and admins are your most important constituencies, and we recommend setting up a long-lived platform engineering team that treats your platform like a product. Source: GCP

Again, a toolchain is not one thing. Instead, a toolchain is a composable set of things that very much depends.

Will a toolchain supporting dozens or hundreds of software developers of a large company with a diverse portfolio of business lines in a highly regulated industry be identical to the toolchain for at another company that offers one mobile app? Probably not, but there might be similar tools.

And we looked so good 🎶

Stepping back to dental analogies, some developer patients will have software with long lifespans¹. Other developer patients will have “there’s an app for that”² software that takes huge Schumpeter-esque bites out of the way business was done in prior years — but nobody wants to see big needles and pliers. 😬

So, if developer patients visit the platform engineering dentist office, experience is increasingly important. Does the platform engineering dentist office experience really have to be frustrating or filled with old magazines and trepidation? 😬

Imagine… 😬

• No preparation required, no appointment required.
• No waiting required, immediate service upon arrival.
• Maximum comfort that tailor fits vs. a slab meant for contortionists.
• Preferences preserved, favorites in the catalog for immediate playback.
• Managed expectations, progress indicators to observe each step until completion
• Easy to understand next steps, guided where to go after completion.
• Feedback and metrics captured throughout the experience, internal measurement and highlighting areas for improvement.
• Effortless updates, communicated via preferred notifications to provide updates on future experiences that are be even better than the last visit based on personal and collective feedback.

Now, sit back and relax. This next tool in the toolchain will numb the immediate pain but good news — you might not feel so lightheaded afterwards or sore the next day. 😬

So, what will be the next major tool to append to toolchain in the growing list of platform engineering pursuits?

Until then… Place your bets!

Work Plug

As a reminder, after a +25 year walkabout, I’m an IBMer (again). For 2023, in “Work Plug”, I’ll share a new link each week that is educational, accessible, and relevant to platform engineering from fellow IBMers³ in the wider IBM Community.

Stay tuned!

Disclosure

I am linking to my disclosure.