Platform

A platform is not a technical artifact. It is a financial asset with an organizational operating model and a return on consistency that compounds over time.

What Platform Actually Means

The word "platform" is overloaded.

In consumer software, it means an operating system, an API layer, a marketplace. In startup contexts, it means anything with network effects. In enterprise IT, it means shared infrastructure.

The definition that matters for the work I have done:

A platform is shared engineering capability that reduces the per-unit cost of producing each subsequent thing that uses it.

That definition has three parts, all of which are required:

Shared — available to more than one product, team, or use case. A platform that only one team uses is not a platform; it is a private library.

Engineering capability — not just infrastructure or tooling, but the accumulated knowledge, architecture, validated components, and verified practices that make new development faster, safer, and cheaper.

Per-unit cost reduction — the economics must be favorable. If the second product using a platform is not significantly cheaper than the first, the platform is not working. If the tenth is not cheaper still, the platform is not compounding.

By this definition, most "platform" initiatives fail — not because the technology is wrong, but because the economics never materialize. The platform exists. The shared architecture is defined. But each product team still carries similar costs because the shared capability was not built to the level where reuse is genuinely faster than building from scratch.

Platform Is Relationships, Not Just Architecture

The Keystone Library Network taught a lesson that I have not seen contradicted:

A platform works only if the organizational relationships required to share it already exist.

KLN's technical infrastructure — shared databases, remote authentication, consortium-scale migration tools — only became possible because fourteen institutions had already built the trust model required to share. The Remote Patron Authentication System worked because libraries were willing to honor each other's patron credentials. WebAdmin spread because the relationships in the Voyager user community gave Shippensburg's development visibility with Endeavor Software.

The architectural design came second. The relational infrastructure came first.

This pattern appears in regulated software as well. A shared platform across a medical device portfolio requires, as a prerequisite, that software, systems, quality, regulatory, and clinical stakeholders have aligned their incentives, vocabulary, and governance model. Without that alignment, the platform becomes technically possible and organizationally inert — used grudgingly by product teams who view it as a constraint rather than a resource.

Building the relational infrastructure for platform adoption is slow, non-linear, and invisible in most project plans. It does not appear on a Gantt chart. It does not produce a deliverable. But it is the rate-limiting step for whether platform investment translates into platform adoption.

→ See also: Voyager, KLN, and the Consortium

Where Platform Value Actually Appears

Platform investment is typically evaluated against first-product delivery.

This is the wrong evaluation criterion. It almost always makes platform investment look unattractive.

The first product built on a new platform is slower than it would have been without the platform, because the platform is being built simultaneously. The components are being designed for reuse before the full requirements of reuse are known. The shared practices are being established while the team is also trying to ship.

The ROI on platform investment appears in:

Long-term support. Products built on shared architecture share the cost of maintenance. Security patches applied to shared components propagate across the portfolio. Documentation maintained in one place remains accurate across products that use the same component.

Cybersecurity. A portfolio-level cybersecurity posture is only achievable when products share components. When products are built independently, each product's security assessment is independent, each vulnerability in a shared dependency must be remediated independently, and the organization cannot maintain consistent posture. Shared architecture transforms cybersecurity from a per-product expense to a portfolio-level investment.

Regulatory compliance. In regulated domains, each documented submission builds on the patterns established by previous submissions. A shared architecture means shared regulatory patterns — submission strategies, design control structures, verification approaches — that reduce the preparation cost of each subsequent filing.

Training and onboarding. Engineers who know the shared architecture can be productive on any product that uses it. An organization with a strong platform has a talent development advantage: new engineers learn one system, not many.

The third product. If first-product economics look unfavorable, evaluate second-product and third-product economics. The compounding appears there.

The Two Failure Modes

In regulated software portfolios, two organizational responses to the platform question consistently fail:

Product autonomy without shared capability. Each team optimizes locally. Each product develops its own architecture, toolchain, testing practices, and documentation standards. This looks efficient at the product level and is catastrophically inefficient at the portfolio level. Cybersecurity cannot be maintained consistently. Regulatory patterns do not transfer. Engineers cannot move between products without starting over. The organization rebuilds the same capability repeatedly.

Centralized mandate without engineering ownership. A platform is defined and declared. Product teams are required to use it. But the teams did not participate in designing it, do not understand its rationale, and experience it as a constraint on their velocity rather than a resource that serves them. Compliance is minimal. Workarounds accumulate. The platform becomes a political problem rather than a capability problem.

The path that works is a third option: harmonized architecture with genuine cross-functional ownership. The platform is designed to make product teams' work easier, not to impose consistency for its own sake. The teams that use it have a voice in its design. The investment model credits platform work explicitly rather than subsidizing it invisibly through individual product budgets. Ownership is real, which means accountability is real.

The hardest part of this is organizational design, not technical design.

Cybersecurity at Portfolio Scale

Cybersecurity in regulated software is a portfolio problem masquerading as a product problem.

Every connected medical device, industrial system, or safety-critical platform has a supply chain of components, libraries, and dependencies. The vulnerability surface of any product is not limited to the code its team wrote. It includes everything that code depends on.

When products are built independently — each with its own dependency selections, each with its own patching cadence, each with its own security assessment — the organization pays the full cost of cybersecurity separately for each product. A vulnerability discovered in a common library requires separate remediation across every product that uses it, carried out by teams that may not know each other's dependency inventories.

When products share components through a governed platform, the cybersecurity economics change fundamentally. A vulnerability discovered in a shared component is remediated once, in the platform, and the fix propagates. The security assessment of a shared component applies to every product that uses it. The organization maintains a single view of its dependency inventory rather than N separate views.

This is not a secondary benefit of platform investment. In environments where post-market surveillance, SBOM transparency, and regulatory scrutiny of cybersecurity practices are increasing, it may be the primary justification.

Empowering Local Institutions Scales Better Than Centralization

A lesson from the Keystone Library Network that applies broadly:

Platforms that empower local operators scale better than platforms that centralize control.

WebAdmin was built specifically to give individual library administrators the ability to schedule and monitor bulk operations in the Voyager ILS without routing every request through consortium hub staff. Each library could manage its own workflows. The hub staff were freed to handle problems that genuinely required central expertise.

This design decision — to distribute authority to the operational level rather than concentrate it at the center — made the platform more capable as it grew, not less. The load that would have crushed a centralized model was absorbed by the distributed institutions.

The opposite design — centralize everything, require central approval for every significant action — creates bottlenecks that scale with adoption. The more institutions use the platform, the more requests the center must handle. At some adoption threshold, the center cannot keep up, and adoption stalls.

The design principle: platforms should concentrate governance (standards, security, quality controls) and distribute authority (the ability to act within those standards). Concentrating both governance and authority creates bottlenecks. Distributing both creates chaos. The right balance is clear standards with local execution.

Measuring Platform Value

Platform value is difficult to measure directly, which is one reason it is chronically underinvested.

The costs of platform investment are visible: engineering time, delay in first-product delivery, organizational coordination. The benefits are counterfactual: what the second product did not cost, what the security incident did not happen, what the regulatory finding was not issued.

Counterfactuals do not show up in dashboards.

Metrics that make platform value visible:

Time-to-first-commit on new products. How long does it take a new product team to be productive using the platform? This measures the platform's fitness for onboarding.

Defect recurrence rate. What fraction of defects found in one product are also found, independently, in another product using similar components? High recurrence means shared root causes that a shared platform should address. Declining recurrence over time means the platform is improving the portfolio's quality.

Security patch propagation time. When a vulnerability is discovered in a shared component, how long before all products using that component are patched? This is directly measurable and directly attributable to platform architecture.

Second and third product delivery time relative to first. The clearest signal that platform investment is working.

Cost of regulatory submission reuse. In regulated environments: what fraction of a new product submission is adapted from previous submission content versus created from scratch? This measures whether shared architectural patterns are generating regulatory efficiency.

None of these metrics are available in the first year of platform investment. They require the patience to measure across multiple product cycles. The organizations that invest in platform without that patience will abandon the investment before the ROI materializes.

→ Related: Engineering · Patterns · Leadership