Platform Priya
“All change requests are platform requests.”
Does the platform become a bottleneck?
Elevator answer
Application teams should change pricing and order flows without filing a platform ticket. Platform review belongs where one connector or runtime change can break everybody.
3 coffee-machine misconceptions
Consultant Nigel
“No standards means no waiting.”
Consultant Nigel
“Every exception needs a board meeting.”
The real explanation
Centralization occurs when a framework owns business meaning it does not understand. TPF should not do that. Application teams define their flow composition, domain decisions, and use of supported boundaries. They should be able to change application-owned steps and policies without asking a platform team to interpret the business.
Coordination is appropriate when a change affects a shared contract. A connector provider or operation contract can have many consumers; framework runtime semantics can affect every pipeline that relies on them. Their identities, versions, capabilities, compatibility promises, and generated behavior deserve deliberate evolution. Requiring the same process for a team’s local business step would be a platform bottleneck disguised as consistency.
Use blast radius, not hierarchy. Orders can change PricingPolicy locally. Changing the shared Stripe connector's retry classification needs its product owner because forty flows may charge money differently afterward. Changing runtime-wide replay behavior belongs with the framework team. The typed declarations make it possible to see which sort of change this is before opening the ticket.
Trade-offs
TPF gains safer shared evolution. It gives up completely invisible cross-team change.
When TPF is not a good fit
If an organization wants no common runtime or contract surface at all, a shared framework cannot provide value without creating unwanted coordination.