Partnering with Platform Providers

Loads of organisations are heavily reliant on using platforms provided by others. But how to work in partnership with those Platform Providers can be difficult. Having been on both sides of this in my career, here’s a few pointers for the customers of platform providers to look out for. Caveat: this is oriented mostly at the smaller end of town, I’m not talking about the Cloud Hyperscalers or platforms like Salesforce or the like.

  1. Platform Investment: You’re looking for some sort of commitment to continued investment in the platform. How to measure or monitor this? You could ask for CapEx spend, and for that to be at least the same as over the last 24 months or so (you’ll definitely want to capture any period prior to acquisition by PE or other Global behemoths). Ask the Platform Provider to provide baseline and annual reporting of this to you. Any CapEx spent on making the platform suitable for other jurisdictions should be in addition to this – since that’s often a distraction. Ask the Platform Provider to share their Roadmap for the platform and associated components at least annually, and try to create some way for your organisation to influence direction and priority to suit your strategic needs.
  2. Code Quality/Managing Tech Debt: A firm commitment to increasing code quality and the paying down of technical debt: measured by unit test coverage in the core platform and APIs, as well as the number of scenarios that have automated tests. Needs to also cover associated components, like any reporting or data/analytical layer . You should ask for an evidenced baseline of this and reporting on an annual basis. Software Bill of Materials (SBOM) disclosure: Current baseline and Roadmap, including information about work to address any End-of-life OS or Frameworks/Libraries that the platform relies on, as well as the version of frameworks and dependencies. (This is also relevant under the “Security” heading.)
  3. Capacity: A commitment to maintain a minimum number of developers dedicated to the platform, with a strong preference that those developers are colocated, or at least in the same timezone. This is also somewhat relevant on the security front as well, as the platform provider may seek to offshore development, but may need to lower security to do so. Again, baseline and annual reporting of this.
  4. Performance: You should ask for a full-load performance test with a base of your current size, plus a simulated load of 150% to give confidence about your ability to grow and not be held back by the platform you are reliant on. This might cover peak loads such as annual peaks of transaction processing, month-end or weekly peaks for processing as well. Be open to discussion about what the measures could be, but they should exist and be supplied regularly. Again, also cover the reporting side (if there is some sort of Data Platform).
  5. Security: there’s a lot here, and it’s a moving feast, but the usual annual pen test isn’t enough. Need an open and honest baseline assessment with clear roadmap of improvements and capacity ring-fenced and prioritised to do the work required to keep ahead of the game. Initial questions like network segmentation (Dev, Test, Prod), which AD domain has access to Prod, permissions review, any macro usage that accesses the DBs, DR/BCP tests (random, not planned for). Ask for and expect continued work towards a Zero Trust Architecture. Annual security audit with findings shared (not just a pen test). SBOM disclosure, as above. Should also ask for a list of Macros that might handle PII, and expect that this should shrink over time, or at the very least be sourced from the analytical layer not the operational data store (assuming monolith here).
  6. Privacy: assurances that privacy controls and access are configured such that no operational users or developers outside of your local jurisdiction have access to PII. Ask for progress toward SOC2 or similar.
  7. Observability: Platform Provider should provide access for your organisation to see real-time telemetry of Platform Performance. You will want early warning of any potential issues, with both processing and/or APIs.

What have I missed? I’ll add to this list as it occurs to me…