https://platformengineering.org logo
Join Slack
Powered by
This message was deleted.
# platform-blueprints
s
This message was deleted.
šŸ‘ 2
m
That's a very important question and first of all it's critical that the org is aware of the potential impact on the flow of stream-aligned teams when we're trying to "help" but we end up (unwantingly) with platforms that are more blockers that helpers.
Of course, we must start by the business related platform being self-service, that's a must.
But even then, a common problem is the boundaries of the platform being too strict and defined upfront. That is a common mistake that leads to painful dependencies down the line. Maybe the abstractions are too high level for some teams, forcing them to use workarounds or frequently wait on platform teams to make changes. Or the abstraction is too low level, causing cognitive load on the stream teams.
In short, it's definitely beneficial to think about possible non-infra/SRE/DevOps platforms. You can find some really interesting examples here: https://bit.ly/3NgtKoW
I love how uSwitch evolved from an initial could infra platform to now having multiple platforms around consumer data and even marketing: https://teamtopologies.com/industry-examples/organizational-evolution-accelerating-delivery-of-comparison-services-uswitch
Or how NAV, a gov org in Norway, has a design platform and a data platform on top of the Applicaton platform: https://teamtopologies.com/industry-examples/how-the-internal-technology-platform-creates-value-at-nav
p
How does this related to the (in)famous "Spotify"-model? Like Tribes? Is everything you describe "inside" a tribe?
m
In my opinion, those higher level platforms are where a lot of the platform value shines.
@Paul Puschmann it's unrelated to tribes, we're not based off the Spotify model at all.
You can find the key concepts from the Team Topologies book here: https://teamtopologies.com/key-concepts
a
Thanks a lot for the info!
šŸ‘ 1
p
... šŸ¤” . Thank you, so I should do some serious reading first šŸ˜‚ . I only wondered what you would think of something like "platform" as a separate tribe.
m
Personally, I think tribes are fine if they're aligned to true domains, but dangerous if aligned to disciplines like SRE or DevOps. A tribe typically sets very strong incentives so you end up incentivizing the wrong things from a business perspective possibly.
šŸ‘ 1
A clearly defined platform could be a tribe. But there should be a clear value proposition to this platform which is aligned to the needs of the other teams and the organization's goals.
šŸ‘ 2
p
And I guess you'd recommend to have "the platform" inside of a tribe?
m
There's no silver bullet to recommend. Sometimes it makes sense for large distributed orgs to have multiple platforms that are localized per region, even if they provide similar services, for e.g.
šŸ‘ 1
Other times, it doesn't make sense to do that.
I think a sense of belonging is important, whether that's with tribes or some other construct.
p
Yes, it highly depends. Thank you so far. I'll have to think about this šŸ™‚
m
We talk about trust boundaries in the book, these are important to keep in mind when organizing platform teams as well. Having 300 people in a single "platform" group is going to cause issues of trust.
šŸ‘Œ 1
We go into more details of all this in our Platform as a Product online training: https://bit.ly/3MS88Pt
šŸ‘ 1
āž• 1
(you can use code platformcon-15off for a 15% discount)
But just to go back to @Angel Costelaā€™s initial question, it is key for any platform, but especially for business & data focused platforms to keep the boundaries of what's in and out of the platform quite fluid and evolving over time. We can use things like a team dependencies tracker to help us have leading indicators of potential issues over time: https://github.com/TeamTopologies/Team-Dependencies-Tracking
ā¤ļø 1
25 Views
Open in Slack
PreviousNext
Powered by