[{"data":1,"prerenderedAt":137},["ShallowReactive",2],{"articles-building-platforms-for-vendor-led-enterprises":3},{"id":4,"title":5,"body":6,"date":118,"description":119,"extension":120,"image":121,"imageAuthor":122,"imageLicense":123,"imageSource":124,"meta":125,"navigation":126,"path":127,"published":126,"seo":128,"slug":129,"stem":130,"tags":131,"__hash__":136},"articles\u002Farticles\u002Fbuilding-platforms-for-vendor-led-enterprises.md","Building Platforms For Vendor-Led Enterprises",{"type":7,"value":8,"toc":109},"minimark",[9,16,19,22,27,30,33,36,39,42,46,55,58,61,64,68,71,74,77,80,84,87,90,93,96,100,103,106],[10,11,12],"p",{},[13,14,15],"em",{},"A lot of my customers don't build their own integrations. They hire someone who does, for the length of a project, and then that someone leaves.",[10,17,18],{},"I keep running into the same customer shape. A business team with no technical know-how of its own, running a project on a vendor's time and a vendor's keyboard. The vendor ships the integration, invoices the last milestone, and moves on to their next engagement. What they leave behind becomes the customer's problem the moment something breaks.",[10,20,21],{},"In this article I want to work through why that model quietly erodes integration quality, what a platform aimed at this specific situation needs to assume about its users, and which capabilities actually move the needle rather than adding another policy document nobody reads.",[23,24,26],"h2",{"id":25},"the-vendor-leaves-the-business-team-stays","The vendor leaves, the business team stays",[10,28,29],{},"This is the part that's easy to miss if you've never sat inside one of these organisations. The people deciding to integrate a new system are, quite reasonably, not the people who know how to integrate a new system. So they fly in the expertise: a systems integrator, a boutique vendor, a freelance specialist, whoever ends up behind the keyboard for the duration of the project.",[10,31,32],{},"That's not a bad model on its own. Specialisation exists for a reason.",[10,34,35],{},"The trouble starts the moment the project ends and the vendor's access gets revoked. The customer's own integration team, the people who actually have to run this thing in production, gets pulled in two directions at once. During the project they're fielding ad-hoc requests from a vendor who needs an endpoint, a credential or a decision made by end of day. After the project they inherit whatever got built, with whatever documentation the vendor felt like leaving behind.",[10,37,38],{},"Sometimes that's fine. I've seen it work out plenty of times.",[10,40,41],{},"I've also seen a canonical model quietly bypassed because nobody on the vendor side knew it existed, an API shipped without a single validation rule because nobody enforced one, and a support inbox that fills up six months after go-live because the person who understood the integration is now working for a different customer entirely.",[23,43,45],{"id":44},"governance-belongs-in-tooling-not-a-slide-deck","Governance belongs in tooling, not a slide deck",[10,47,48,49,54],{},"The reflex response to this is more governance. Write the principles down, hold a review board, make vendors sign off on an architecture document before they start. I get the instinct, it's the same one I described ",[50,51,53],"a",{"href":52},"\u002Farticles\u002Fautomate-api-governance","writing about API governance execution"," more broadly. But a slide deck has no opinion about the API description a vendor actually ships. It can't fail a build. It can't reject a pull request.",[10,56,57],{},"Enterprise architecture that only lives in slides is architecture vendors will never open. They have their own deadline, their own tooling, and no real incentive to read your governance document before they start writing code.",[10,59,60],{},"What I believe instead: the principles and patterns you want enforced need to be executable, and the expertise needs to sit at the edge of the estate rather than centralised in a review committee three approval steps away. A federated operating model, where the platform itself carries the know-how instead of a person who has to be pinged for it, is what makes this workable at the pace vendors actually operate on.",[10,62,63],{},"There's a real difference between a rule that says \"APIs must follow our naming conventions\" and a rule that fails the pipeline when they don't. One is a hope. The other happens whether or not anyone remembers to check.",[23,65,67],{"id":66},"zero-ticket-integration-is-the-actual-goal","Zero-ticket integration is the actual goal",[10,69,70],{},"Here's where I think most governance efforts stop too early. Enforcement alone gets you compliance, and compliance alone doesn't get vendors to like your platform. It gets them to route around it.",[10,72,73],{},"The platform has to be worth using on its own merits, not just on pain of rejection. If the fastest way for a vendor to integrate with your estate is also the way that keeps your architecture principles intact, you've won without a single review meeting. If the fastest way is to skip your platform and ask a human for a shortcut, you've lost regardless of what the governance document says.",[10,75,76],{},"That's what I mean by zero-ticket development. A vendor should never need to open a support ticket to understand what's available, how to consume it, or how their data maps onto your canonical model. The moment they do, you've reintroduced the ad-hoc overload this whole thing was supposed to prevent.",[10,78,79],{},"So the angle can't only be policy enforcement. It has to be fast enough and good enough that vendors don't want anything else.",[23,81,83],{"id":82},"what-the-capabilities-actually-need-to-do","What the capabilities actually need to do",[10,85,86],{},"I keep coming back to three things a platform like this needs to nail.",[10,88,89],{},"First, it needs to make the customer's own business team want it. Adoption doesn't start with vendors, it starts with the people who feel the benefit first. If a business team experiences what it's like to onboard a vendor without the usual chaos, they'll insist on the platform the next time a new vendor walks in. That's a stronger enforcement mechanism than any mandate from architecture.",[10,91,92],{},"Second, it needs to do the heavy lifting for the vendor instead of just watching them. SDK generation from the API description. Validation of that description before a single line of integration code gets written. A unified API surface so a vendor isn't reverse-engineering which of your seventeen internal systems they're actually supposed to talk to. Data mapping onto your canonical model, so the vendor's payload becomes your shape automatically instead of by convention nobody checks.",[10,94,95],{},"Third, it needs to lower the barrier to entry, relentlessly. A vendor who has never seen your estate before should be able to find what's available, read documentation that actually explains it, and see a diagram that makes the topology click, fast. Every hour a vendor spends guessing is an hour your integration team spends answering questions the platform should have already answered.",[23,97,99],{"id":98},"where-this-leaves-governance","Where this leaves governance",[10,101,102],{},"In an environment where you own the whole stack, governance can afford to be a conversation. In a vendor-led environment, I don't think it can. A conversation-based approach assumes continuity, the same people, the same context, over time. A vendor-led environment guarantees the opposite: new people, no context, every single project.",[10,104,105],{},"The fix isn't fighting the vendor-led model. It's building a platform that assumes it from the start, one that enforces what matters, does the tedious parts for you, and gets out of the way for everything else.",[10,107,108],{},"If a vendor never wants to go back to their old way of working, you've built the right thing.",{"title":110,"searchDepth":111,"depth":111,"links":112},"",2,[113,114,115,116,117],{"id":25,"depth":111,"text":26},{"id":44,"depth":111,"text":45},{"id":66,"depth":111,"text":67},{"id":82,"depth":111,"text":83},{"id":98,"depth":111,"text":99},"2026-08-20","Why customers whose integration work is delivered by external vendors need a platform, not more governance meetings, to stop quality drifting away the moment the vendor leaves.","md","\u002Farticles\u002Fbuilding-platforms-for-vendor-led-enterprises\u002Fcover.png",null,"Public Domain","https:\u002F\u002Fcommons.wikimedia.org\u002Fwiki\u002FFile:Original_Blueprint_of_United_States_National_Agricultural_Library.jpg",{},true,"\u002Farticles\u002Fbuilding-platforms-for-vendor-led-enterprises",{"title":5,"description":119},"building-platforms-for-vendor-led-enterprises","articles\u002Fbuilding-platforms-for-vendor-led-enterprises",[132,133,134,135],"governance","api","developer experience","maturity-model","Ep51o6k4kB6GB2HSXld9IpSXSaQwd994Uoc8kUTvl70",1787950873104]