Hi, Are there any other community members who are adopting/trying to adopt the Platform Engineering concepts for a dev-tools/dev-exp team catering to developers of a Product Firmware or similar? The basis for my question is that I'm Project Manager for a team that does development tools, CI, developer experience for 1500 developers and we feel that our values and goals align very well with the Platform Engineering philosophy. However we aren't solely a Service Development organisation instead we cater mainly to developers of a product firmware. This means that f.i. the IDP that we have/strive for doesn't match the IDP template that seems to be the main accepted way of thinking about the IDP (or at least the only one I've found so far, some version of https://humanitec.com/blog/what-is-an-internal-developer-platform). E.g. for us CD and "deployment" in general doesn't map to firmware development or at the very least the "deployment" parts happen much later in the SW life cycle and is handled by a different team than the one handling the development services. BR Sven Selberg

Hey Sven! Seems like you’re facing the same issues as anybody in the embedded sector. Without knowing your industry (or your case more closely) it’s hard to give you recommendations, but in general the “reference architecture” is no “solution architecture” and meant to be modified and adapted where needed for your case. I have seen a lot of cases in the embedded field that build upon the PE principles, but extend their way to production as needed. Most cases try to stay as long as possible in simulators before making the leap to actual hardware. Also “production” is sometimes extended into the real field, caring for different concerns like OTA fleet updates and the like and not only for the product during manufacturing. To go from here, you’d need to share either more of your case here or poke me in a DM for a virtual coffee together.

Hi Sven, What you describes (CI and DevTools) is a platform already. It does not have to tick all the boxes. It depends on the specifics needs of your organization. The IDP template you refer to can be useful for people to build a mental model, but it is definitely not the only way. I don't see a problem with the platform being minimal and only addressing part of the software lifecycle. What you have seems very well suited to adopt the platform engineering concepts and "as a product" approach. The main product/capability of one of my teams is just CI/CD templates libraries. From their POV, their maintain that as a platform product. We have another team where their sole product is a Design System.

Fairly uncommon to have every single element deployed in a given team/environment. Consider that aspirational, but also we need to ask 'what is needed here/now' rather than what a given strategy outlines. In an air-gapped or similar environment most concepts of orchestration and control get fuzzy. Instead I'd focus on the bits that make a developers life easier. A lot of the Developer Platform functions probably exist in your org, but does everyone know where they are, how to access them etc? Is the team jumping around various tools/tabs to get a good view of whats happening?

Does this offer any integrations that may help with producing test data for different environments?

You can try doing some delivery process mapping and find bottlenecks there, which is common for teams and do not close to their core business. And address it in a Platform. I use Value Stream Mapping, Event Storming, sometimes simple DevEx Mapping (like Customer Journey)

I agree with all these great people that what you're doing is a platform and that it's about the principles over the exact tech. When thinking principles, you may get value from this idea of the layers (app, platform, and infra) that Daniel Bryant wrote about: https://www.syntasso.io/post/platform-engineering-orchestrating-applications-platforms-and-infrastructure In many ways it's a higher level abstraction from the humanitec model you already quoted, but both are very much pulling the same direction. Given it's higher level you may have an easier time mapping it to your context firmware? 🤞

Thanks for all the fine replies. We are in agreement that what we are doing already is Platform Engineering. 🙂 W.r.t. models: I feel that models are very useful in the way that you can project your reality onto the them to identify the dark spots. It is then fairly easy to analyze these areas to see if this discrepancy actually tells you anything and if addressing them would add value. (I.e. I don't regard models as a solution.) This approach usually gives more bang-for-the-buck than doing a complete bottom up analysis and trying to identify any missing pieces. The Humanitec model was too opinionated towards service development to be useful for this exercise and I was hoping we could piggy-back of someone else's efforts 😉. We have a fairly clear idea of what larger pieces are missing for our users, the issue is that we don't have the bandwidth to address them all and were hoping that the model-approach would help us either narrow our offerings (by focusing on a limited number of areas in the model) or prioritize between new efforts. To clarify my goals: • For our own sake give a more high level view of what we are accomplishing (for the proverbial back patting) but also to help us prioritize between efforts. • Describe the PE concept to Business and give them a more accurate perception of the value currently created by the team. • Identifying pieces of a PE puzzle that have no/little focus today due to bandwidth, and try to give an estimate to Business of the value it would create if someone would be given the opportunity to address these areas to give Business a fair chance to take a decision. I will study the syntasso.io article, thanks for the link and offerings of f2f sessions (I will get back to you). Thanks again! BR Sven Selberg

I don't regard models as a solution

Never truer words have been spoken. This sounds like an awesome journey and hope you keep us posted!

Just wanted to contribute a bit after reading all of the excellent answers above: The platform (and often times the portal that comes along with it) are tools that should match the way your organization (and its members) expect and hope to work. In short - the platform should work for you and not the other way around. So I would recommend (as you rightfully mentioned) to try and figure out what problems you are facing today, and what is the best way a platform could help you tackle those (and also to start small, with a single use-case and a single internal group that will experience it and provide feedback). Then after you have that information, you can start to think about the correct model/no-model/custom-model that will help you achieve that, and also the correct tools (internal, open source, commercial products) that will help you achieve that. Keep in mind that while a lot of the conversation in the PE world today revolves around the SDLC of microservice architectures, a flexible and customizable platform should be able to accommodate any use case, no matter what SDLC looks like for you and your developers. I’d be happy to chat about it if you have any questions 🙏 👍

Exactly. Platform is yet another system, supporting the business process (SDLC in this case). It has business stakeholders (dev&ops teams), and just like any other system - it needs to address their needs. Also just like any other system it needs business and functional analysis. Many Platform Engineers focuses too much on tech, too less on this analytical part (from my experience)

Thank you very much for the replies. Just to reiterate, we aren't starting out, we already have a "Platform" that has been growing and evolving for the past 10+ years (we just didn't know it as "Platform Engineering" 😉 ). I'd say that we are firmly at level 3 in the cncf maturity scale (https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/#level-3-scalable--as-product). Upon discovering that there's a whole community revolving around what we are doing we thought it could be valuable to map our "Platform" against a model that other intelligent people have made to see if it tells us something about it (like: are we missing some pieces? would it make sense to mimic the model in the organizational structure?) but also as a way to describe what values the team is contributing to the business as a whole (since these second/third level benefits and values can be hard to quantify).

As a contributor to that CNCF model, if you have any feedback, questions, concerns, or even extension ideas for it after your experience I'd love to hear it! The group is working on platform as a product deep dives right now but also a few more angles 🤞

If anyone here works for cncf.io, please can you review the hyphenation / wrapping settings in your CSS? The 2nd paragraph in the article linked by @Sven Selberg is ridiculous:

Hi Chris, thanks for reporting. I believe you may be speaking about the white paper rather than the linked doc (the Maturity Model). In regards to that report, first of all, cncf is an org, but this site ie run by a volunteer group (including me) and is always open to pull requests. Second, I can open up a conversation with the volunteer who has a particular skill in this space if you could share more about what is “ridiculous” and what you would expect. In the mean time, this does change per screen width, therefore may be something you can at least fix for your current view by changing your window size (see screenshot of this laid out differently)

(Taken offline - apologies for the slightly emotive language!)

@Abby Bangser "The group is working on platform as a product deep dives right now..." Does "platform as a product" mean something like "Platform Engineering, for product development" or "Product engineering (!?)"? Is there any forum or similar were one can track the progress and perhaps offer some questions/perspective on occasion?

Great question Sven! So "Platform as a Product" is a term that has been getting used to say that platforms should be designed and built with the same user focus and product mindset as any other software. The group identified that this was an area that was particularly divergent in the industry and wanted to focus on it. The group has created an interview framework and is trying to collect "a state of" type understanding for now. They are also looking at writing some articles on the topic to start sharing common language in the space. As for where to follow, this is an area we need to be improving, but if you aren't already in the CNCF slack and more specifically the #wg-platforms channel that's definitely where you can get involved!

Thanks Abby, I will investigate 👍

Awesome. Happy to have a chat or help connect you if you see interesting projects, but hopefully it is also a bit self serve if you prefer that!