Tips For Building Successful Platform Teams
Вставка
- Опубліковано 28 вер 2024
- What is a platform team, and how do you build effective platforms? Platforms are often an important part of the strategy to scale software development beyond small single teams. Dividing work up so that common behaviours and services can be shared, rather than every service team implementing their own version, is a big gain, but it can also be a big cost. Coupling between teams is one of the biggest causes of problems when trying to build software on larger scales.
In this episode, Dave Farley, author of "Continuous Delivery" and “Modern Software Engineering” describes the pitfalls common to platform teams, the principles that are important for platform engineering, and the strategic goals that platform teams can use to guide their decisions and some tips for platform teams that help them insulate their users from changes in their services.
-------------------------------------------------------------------------------------
Also from Dave:
🎓 CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
➡️ bit.ly/DFTraining
📧 Get a FREE guide "How to Organise Software Teams" by Dave Farley when you join our CD MAIL LIST 📧
The best way to keep in touch with the latest discussions, events and new training courses, get FREE guides and exclusive offers. ➡️ www.subscribep...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd...
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
➡️ Team Topologies - Matthew Skelton & Manuel Pais ➡️ amzn.to/2Y0NdSO
NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------
CHANNEL SPONSORS:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.or...
TransFICC provides low-latency connectivity, automated trading workflows and e-trading systems for Fixed Income and Derivatives. TransFICC resolves the issue of market fragmentation by providing banks and asset managers with a unified low-latency, robust and scalable API, which provides connectivity to multiple trading venues while supporting numerous complex workflows across asset classes such as Rates and Credit Bonds, Repos, Mortgage-Backed Securities and Interest Rate Swaps ➡️ transficc.com
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
this should be on everyone's repeat-annually playlist to keep us on the path
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 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.
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.
I'd love a more detailed explanation of API versioning
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.
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
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.
22:10 Thank you very much for talking. 🙂
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.
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
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.
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.
This is gold!
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.
It all makes little to no sense. Just a bunch of jibberish and buzzwords.
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.
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.
@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. 🏸
So so good - really impressed by that.
🔥That shirt though🔥
Exceptional!
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:
ua-cam.com/video/ghzsBm8vOms/v-deo.html