Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide
"Good software comes from teams, that are able to clearly separate, what the system needs to do from how it achieves it" - a lot of wisdom in just a single sentence.
Platform teams who treat their developers like customers will build great platforms. Also in my experience, the best platform engineers are actually developers because they know what developers want.
To my point of view: Platform Teams are Value-Stream Aligned Teams FOR Stream-Aligned Teams, but the value is not directly aligned with the customer (the one who pay!), instead it's a derivative to the value to customer (commit small, often, with trust, delivering value as fast as possible). That's the way we approach our role in my organisation. I work in a CI/CD/CLOUD platform. The principles you've exposed are similar to those applicable to end-user but in my case, the end-users are the teams who write/operate code for the customers, We are considering ourself as small enterprise/startup within the company.
That’s how I think about it too. I like the way you described it as a derivative value stream. I’m wondering from listening to what Dave said if my concept of ‘platform’ is too loose though. I haven’t got a platform in the sense of a great big lump of software that the teams insert software components into. What I’ve got our platform team doing is assembling a carefully curated set of enabling components and the infrastructure scripting ’glue’. So things like SSO, Kafka, caches, etc and tools that support deployment. I need to dust off my team topologies and make sure I’ve not become confused :)
No I don't think that is "too loose", sounds like a good approach to me. Some of the text in the video actually recommends that approach if I understand you correctly.
This was Great! definetly a hot topic for us right now, perfect timing. The way you explain things makes it so easy to understand, appreciate you doing this. Can you do one on Complicated Subsystem teams next? There are so many parallels between platform and complicated subsystem, would love to see how you understand the differences.
Call me Peter because I'm a disciple! I'm only just starting out but CD has already helped to make progress with projects without feeling overwhelmed. I don't have to think about everything at once and this immediately makes the journey of software engineering doable and enjoyable. I'm reading "Modern Software Engineering" and I highly recommend it, I'm only a third of the way through and yet it has already changed the way I conceptualise software development. It's no longer just "coding" or "crafting" or " programming", now it's design and engineering. I also have a biology background and it has been interesting to see parallels between actual evolution and the " guided evolution" philosophy of software development. Once you get code-to-repository you have what you have, much the same way that sets of genes work when in homeostasis in organisms, you can only change what you already have and to completely change something is extremely energy intensive. Even in the context of genetic mutation, the most successful mutations (those passed on to next generations) are most often the smallest, a major change to an organism's code more often than not leads to fatal consequences due to the complexity of the underlying interaction structure. We are coding "living" software when we stay engaged with the code in our repositories through consistent small commits. Thanks Dave! You've got some of my money and attention and I foresee you'll get a whole lot more from me in future! (I'll just confirm though that I'm not joining any cults, I'm allergic to tinfoil hats and unbridled groupthink)
Thank you for that! 😎 I don't want to be in any cults either, when someone points holes in my arguments, and shows me a better way, I am grateful. That is how knowledge, and practice progress, it's a process of evolution too. I very strongly believe in treating SW dev (and nearly everything else) as an exercise in guided evolution. So I think that is what the process of science and engineering is too, we gradually accrete knowledge and discard the ideas that we have found to be untrue. I try to avoid being dogmatic, but maybe we should market tinfoil hats with a CD logo 🤔🤣🤣
Hello Dave, thank you so much for the invaluable content you offer through your books and videos. One question that I have is when you mentioned (around 16:20) that the new platform build will fail during CI, because Team A code breaks. How will the execution of the Team’s A test suite be triggered in this case so that the platform team to know that their new build failed? I am asking this because i) a platform might not even know which its customers are (imagine a popular platform that has dozens or hundreds of teams using it) and ii) Platform code and Team’s A code are in two different repos. Personally, the only way that I see a platform build to fail in the way you mentioned is through some sort of contract testing (but even this without 100% guaranteed results, because the platform cannot know how each team uses its APIs). I would very much appreciate your point of view. Thanks again for your contribution to the software development community.
Well the easiest way to organise CI in this case is to test everything together all the time. Keep everything in a single repo, and run all the tests on every commit. You can make these kind of breakages visible through architectural techniques, using static typing for example, or you could try using contract tests to confirm that nothing has changed in the interface. So there are a variety of techniques. I'd advise thinking of it from the perspective "What do I need to know to be happy to release?" that should define the scope of your constant, CI, testing.
This is what I've been struggling with on a solo project. I've literally just started to copy/paste my platform code into different modules just so I don't have to have another day where I wake up and decide to change my service and end up breaking my entire app. The approach I've taken is to have one canonical version of the platform code that is always up to date and well tested, but it's never imported by anyone. Then I just copy/paste the bits and pieces of the code that I need into the different modules. It's like a poor man's version control. It's a ridiculous approach in many ways but I haven't had to deal with irrelevant code-breaking API changes caused by a change to the platform. Designing a good, extensible, reusable, stable service is hard, and when you are the only developer you can absolutely waste your life away on it when there are other features that need to be built. Once more of the application is built I will move the platform code into its own repo and enforce stricter version control requirements. But while the platform is still being fleshed out I stay away from coupling with it with a 10 foot pole. As always great video.
@dave. thank you for the video, great content. I would like to challenge/extend your model, that platform teams need to understand the needs and plans of the consumers and stream aligned teams they are supporting but also to be a world class platform they should also understand end users as well, no matter how many layers there maybe. This allows them to understand a wider picture of problems to be solved than may be presented by a stream aligned team alone. What do you think?
It always helps to have a good understanding of the context of your problem. I don't think it is necessary to have a detailed understanding of everything though. As a minimum, I think that you should have a laser focus on the direct consumers of your service, and understand the broad aims of the layer beyond that, then you need to know what the software is for, and the better you understand that the better choices you can make, but you don't need to tie every feature change in your low-level platform directly to an end-user feature in my opinion.
To a point, yes, but one of the most significant merits, in my opinion, of a service platform is that it frees up the business to orchestrate this "catalog" of services in novel ways and bring new experiences to market. It is a major enabler of business agility.
@alanarnfeld4285 I agree 100%. You can argue that a platform team may have it focus to provide self-service API:s regarding non-functional requirements (Kubernetes, Ansible and/or Terraform) or that the platform may provide API:s supporting functional requirements (API:s used by "stream aligned teams", e.g. working with a Salesforce Financial System). In the latter case the platform team probably needs a deep understanding of the end user as well as of the business services (technical understanding) that the platform supports. A deep understanding of the business domain is probably required in order to enable business agility for the organization in the best of ways. The platform services may even conceptually belong to the same bounded context as the services in the Financial Cloud using the same core domain objects. 🏸
Google has an approach of Apps using a client produced by the platform. When the platform changes they update the clients and have to make sure all Apps work with the new client.
Most of it is fabulous and well told, but I do have one different view on the mission of platform teams reflected from the example mentioned in the video, I want to discuss it. Without a clear definition of what is the mission of platform teams, we might over-engineering our organizational structure again. That is, should the platform team focus on anything that can be called as a platform, for instance the service mentioned in the video that convert the binary from hardware to Json for downstream applications, or only the platform that tackle extraneous cognitive load, for instance loading a hardware test simulation setup which doesn't bring any value to the final product? To me a platform-like service is not a mission for platform team because it's still part of our product solution and should be managed by some stream-aligned team, but a click to provision a simulation of that hardware to generate some muck binary to test this platform-like service should be owned by platform team. In other word, the platform team maintains only the internal platform serving developers only, will never be part of the product solution.
All the sliding right and left does weird things to my brain. Can you just stay in one corner? I wouldn't mind if half the screen was empty when you don't need a picture to make your point :)
@-Jason-L Agree that approaches always can be improved. This video also describes incentives for having a platform team, which is to reduce the cognitive load on engineers and to create self-service API:s, providing consistency to end-users: th-cam.com/video/ghzsBm8vOms/w-d-xo.html
Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide
"Good software comes from teams, that are able to clearly separate, what the system needs to do from how it achieves it" - a lot of wisdom in just a single sentence.
If you come to us with a solution we may have a problem....
@@andrewnimick2175 what?
Dave are you sure you don't work at my company? It seems you always upload episodes on the current issue I'm facing right as I start to face it.
So the bugging devices are working then 🤣🤣
Very pleased to be of some help.
So true!
Hey colleagues. How do I find you on the intranet?
Same here ☺️ some synchronicity detected
Platform teams who treat their developers like customers will build great platforms. Also in my experience, the best platform engineers are actually developers because they know what developers want.
this should be on everyone's repeat-annually playlist to keep us on the path
To my point of view: Platform Teams are Value-Stream Aligned Teams FOR Stream-Aligned Teams, but the value is not directly aligned with the customer (the one who pay!), instead it's a derivative to the value to customer (commit small, often, with trust, delivering value as fast as possible).
That's the way we approach our role in my organisation. I work in a CI/CD/CLOUD platform. The principles you've exposed are similar to those applicable to end-user but in my case, the end-users are the teams who write/operate code for the customers,
We are considering ourself as small enterprise/startup within the company.
That’s how I think about it too. I like the way you described it as a derivative value stream. I’m wondering from listening to what Dave said if my concept of ‘platform’ is too loose though. I haven’t got a platform in the sense of a great big lump of software that the teams insert software components into. What I’ve got our platform team doing is assembling a carefully curated set of enabling components and the infrastructure scripting ’glue’. So things like SSO, Kafka, caches, etc and tools that support deployment. I need to dust off my team topologies and make sure I’ve not become confused :)
No I don't think that is "too loose", sounds like a good approach to me. Some of the text in the video actually recommends that approach if I understand you correctly.
I'm going to parrot this video in my meeting today. Hit the nail on the head with one of the big problems we're having.
Pleased that you found it helpful.
This was Great! definetly a hot topic for us right now, perfect timing. The way you explain things makes it so easy to understand, appreciate you doing this. Can you do one on Complicated Subsystem teams next? There are so many parallels between platform and complicated subsystem, would love to see how you understand the differences.
Call me Peter because I'm a disciple! I'm only just starting out but CD has already helped to make progress with projects without feeling overwhelmed. I don't have to think about everything at once and this immediately makes the journey of software engineering doable and enjoyable. I'm reading "Modern Software Engineering" and I highly recommend it, I'm only a third of the way through and yet it has already changed the way I conceptualise software development. It's no longer just "coding" or "crafting" or " programming", now it's design and engineering. I also have a biology background and it has been interesting to see parallels between actual evolution and the " guided evolution" philosophy of software development. Once you get code-to-repository you have what you have, much the same way that sets of genes work when in homeostasis in organisms, you can only change what you already have and to completely change something is extremely energy intensive. Even in the context of genetic mutation, the most successful mutations (those passed on to next generations) are most often the smallest, a major change to an organism's code more often than not leads to fatal consequences due to the complexity of the underlying interaction structure. We are coding "living" software when we stay engaged with the code in our repositories through consistent small commits. Thanks Dave! You've got some of my money and attention and I foresee you'll get a whole lot more from me in future! (I'll just confirm though that I'm not joining any cults, I'm allergic to tinfoil hats and unbridled groupthink)
Thank you for that! 😎
I don't want to be in any cults either, when someone points holes in my arguments, and shows me a better way, I am grateful. That is how knowledge, and practice progress, it's a process of evolution too.
I very strongly believe in treating SW dev (and nearly everything else) as an exercise in guided evolution. So I think that is what the process of science and engineering is too, we gradually accrete knowledge and discard the ideas that we have found to be untrue.
I try to avoid being dogmatic, but maybe we should market tinfoil hats with a CD logo 🤔🤣🤣
I was going to reply “You can guide my evolution anytime” but I think that may have come off in the wrong way…
@@johnboikov1360 we *need* those hats 🤣
Yea verily O Great Farley, deliverer of continuity, frequent tester of code!
@@johnboikov1360 🤣🤣 "Science is the belief in the ignorance of experts" - Richard Feynman
Hello Dave, thank you so much for the invaluable content you offer through your books and videos.
One question that I have is when you mentioned (around 16:20) that the new platform build will fail during CI, because Team A code breaks. How will the execution of the Team’s A test suite be triggered in this case so that the platform team to know that their new build failed?
I am asking this because i) a platform might not even know which its customers are (imagine a popular platform that has dozens or hundreds of teams using it) and ii) Platform code and Team’s A code are in two different repos.
Personally, the only way that I see a platform build to fail in the way you mentioned is through some sort of contract testing (but even this without 100% guaranteed results, because the platform cannot know how each team uses its APIs). I would very much appreciate your point of view.
Thanks again for your contribution to the software development community.
Well the easiest way to organise CI in this case is to test everything together all the time. Keep everything in a single repo, and run all the tests on every commit. You can make these kind of breakages visible through architectural techniques, using static typing for example, or you could try using contract tests to confirm that nothing has changed in the interface. So there are a variety of techniques. I'd advise thinking of it from the perspective "What do I need to know to be happy to release?" that should define the scope of your constant, CI, testing.
@@ContinuousDelivery Thank you for your time and response.
This is what I've been struggling with on a solo project. I've literally just started to copy/paste my platform code into different modules just so I don't have to have another day where I wake up and decide to change my service and end up breaking my entire app. The approach I've taken is to have one canonical version of the platform code that is always up to date and well tested, but it's never imported by anyone. Then I just copy/paste the bits and pieces of the code that I need into the different modules. It's like a poor man's version control. It's a ridiculous approach in many ways but I haven't had to deal with irrelevant code-breaking API changes caused by a change to the platform. Designing a good, extensible, reusable, stable service is hard, and when you are the only developer you can absolutely waste your life away on it when there are other features that need to be built. Once more of the application is built I will move the platform code into its own repo and enforce stricter version control requirements. But while the platform is still being fleshed out I stay away from coupling with it with a 10 foot pole.
As always great video.
I could barely focus on the content with this T-shirt 😂
That's the hook - Mr Farley is trying to drum up support for his t-shirt business by talking all that codin' stuff.
🤣🤣 My plan is to lure everyone in, and then spring the rule that you must wear a silly T-shirt to watch.
I wrote a for loop to click on the like button 1M +1 times, but only one time the like is registered.
I'm sure there's a StackOverFlow post about this... we could troubleshoot this issue XD
So so good - really impressed by that.
I'd love a more detailed explanation of API versioning
@dave. thank you for the video, great content. I would like to challenge/extend your model, that platform teams need to understand the needs and plans of the consumers and stream aligned teams they are supporting but also to be a world class platform they should also understand end users as well, no matter how many layers there maybe. This allows them to understand a wider picture of problems to be solved than may be presented by a stream aligned team alone. What do you think?
It always helps to have a good understanding of the context of your problem. I don't think it is necessary to have a detailed understanding of everything though. As a minimum, I think that you should have a laser focus on the direct consumers of your service, and understand the broad aims of the layer beyond that, then you need to know what the software is for, and the better you understand that the better choices you can make, but you don't need to tie every feature change in your low-level platform directly to an end-user feature in my opinion.
To a point, yes, but one of the most significant merits, in my opinion, of a service platform is that it frees up the business to orchestrate this "catalog" of services in novel ways and bring new experiences to market. It is a major enabler of business agility.
@alanarnfeld4285 I agree 100%. You can argue that a platform team may have it focus to provide self-service API:s regarding non-functional requirements (Kubernetes, Ansible and/or Terraform) or that the platform may provide API:s supporting functional requirements (API:s used by "stream aligned teams", e.g. working with a Salesforce Financial System). In the latter case the platform team probably needs a deep understanding of the end user as well as of the business services (technical understanding) that the platform supports. A deep understanding of the business domain is probably required in order to enable business agility for the organization in the best of ways. The platform services may even conceptually belong to the same bounded context as the services in the Financial Cloud using the same core domain objects. 🏸
It’s like you looked right into the heart of our system. It’s creepy how you laid out the Ivory Tower. That’s exactly what happened to us.
Google has an approach of Apps using a client produced by the platform. When the platform changes they update the clients and have to make sure all Apps work with the new client.
Most of it is fabulous and well told, but I do have one different view on the mission of platform teams reflected from the example mentioned in the video, I want to discuss it. Without a clear definition of what is the mission of platform teams, we might over-engineering our organizational structure again.
That is, should the platform team focus on anything that can be called as a platform, for instance the service mentioned in the video that convert the binary from hardware to Json for downstream applications, or only the platform that tackle extraneous cognitive load, for instance loading a hardware test simulation setup which doesn't bring any value to the final product?
To me a platform-like service is not a mission for platform team because it's still part of our product solution and should be managed by some stream-aligned team, but a click to provision a simulation of that hardware to generate some muck binary to test this platform-like service should be owned by platform team.
In other word, the platform team maintains only the internal platform serving developers only, will never be part of the product solution.
This is gold!
22:10 Thank you very much for talking. 🙂
Exceptional!
🔥That shirt though🔥
Thanks
19:48 Tolerant Reader pattern
All the sliding right and left does weird things to my brain. Can you just stay in one corner? I wouldn't mind if half the screen was empty when you don't need a picture to make your point :)
Basically what I hear is building a good platform is virtually impossible and ultimately developers *have* to learn operations.
9 out of 10 platform teams are unnecessary and are the result of poor architectural approach and org structures.
@-Jason-L Agree that approaches always can be improved. This video also describes incentives for having a platform team, which is to reduce the cognitive load on engineers and to create self-service API:s, providing consistency to end-users:
th-cam.com/video/ghzsBm8vOms/w-d-xo.html
It all makes little to no sense. Just a bunch of jibberish and buzzwords.