Software Defined Corporation

The namespace collision is real

In 2026, “software-defined” means a specific family of things in IT and OT: decoupling control planes from hardware for programmatic management. The canonical instances are software-defined networking (SDN), software-defined storage (SDS), and the software-defined data center (SDDC); the family is increasingly referred to as Software-Defined Anything (SDX). A CIO who types “software defined” into a search bar is looking for SDN/SDS/SDDC vendors, not an audit firm.

We get the question. A 2026 thesis review of this site flagged the silence on this collision. This page is the answer.

What we mean by “Software Defined”

We do not mean software-defined networking. We do not sell switches, hypervisors, or storage controllers. We do not build SDX platforms. Our use of the term is older and narrower than the SDN/SDS/SDDC family, and it points at a different problem:

Modern corporations are increasingly defined by their software — not augmented by it. The business rules, the customer relationships, the risk posture, the regulatory surface, the strategic moats: all encoded in software written or bought. When the software drifts from what it was meant to do, the corporation drifts with it. A “software-defined corporation” is one that has accepted this and decided to audit it.

SDN decoupled the control plane from hardware. Our use reclaims the phrase to mean something adjacent: decoupling the corporate claim from the corporate behavior, so the gap can be measured. That is the only sense in which we sell anything “software-defined.”

The Software Defined Index — “how software defined is X?”

In one sentence: the SDI is the measured value over the promised value, for each key performance indicator of your workflow, combined so that the weakest promise dominates. That is the whole idea. The rest of this section, and the Methodology page behind it, exists to handle the edge cases of that one ratio — promises that must hold every time, promises nobody can measure, and behavior nobody promised.

The reclamation above turns the firm’s name into a question you can ask of any system: how software defined is X? Meaning: to what degree is X’s actual behavior determined by its stated definition — the spec, the contract, the architecture description — rather than by drift, accident, or tribal knowledge?

We call the answer the Software Defined Index (SDI). A system whose behavior tracks its definition tightly is highly software defined. A system whose published definition is decoration over undocumented behavior is not — however much software it contains. Being software defined is not about how much code you run; it is about whether the definition governs.

SDI is measured, not asserted — and the measurement already exists. The degree to which a definition determines behavior is exactly the correspondence between claim and referent: fidelity. Therefore, by definition, SDI(x) = MFid(x). MFid measures; SDI indexes. One number, two names: MFid names the measurement; SDI names the question it answers.

We say “by definition” deliberately. A firm that files findings against vendors for shipping two formulas under one name does not get to do the same thing quietly. SDI introduces no new formula, dimensions, weights, or reporting form — the equality is recorded on the Revision Ledger (entry v2.3.0), and if SDI ever diverges from MFid, the divergence must appear there before any diverged score is published. Until such an entry exists, anywhere you read SDI you may substitute MFid, and vice versa.

Where do the KPIs come from? Not from us. The vendor’s written claims determine what is testable; you determine what matters — which claims your workflow depends on, and how much each is worth. Our job is completeness: making sure neither list has been quietly trimmed. The ten questions that build both lists are published as the SDI Intake.

What this firm is, in plain terms

• An audit firm. We score vendors, hardware, processes, and software against what they were sold as.
• Not an SDN/SDS/SDDC vendor. We do not build, sell, or support software-defined infrastructure. If you need an SDN platform, you need a different firm; we are happy to score the one you are evaluating.
• Not a SaaS shop. The Tools page is explicit: we build only what the score requires. They are instruments, not products.
• Not your IT department. We are the auditor your IT department wishes it had.

Why we keep the name

Two reasons. First, the reclamation thesis is the actual argument: in a world where deterministic firmware is increasingly replaced by latent software controllers whose execution integrity is not preserved, the phrase “software defined” ought to mean something stronger than “programmatic management plane.” It ought to mean “defined-by-software, and therefore measured-by-fidelity.” That is the position the firm takes.

Second, renaming is a six-month exercise in branding and SEO that would not improve a single MFid number. We would rather spend the same six months publishing the methodology, the comparison page, and the self-score on the live status page — the actual instruments. If after another year the name collision continues to cost more attention than the audit work earns, we will revisit. We score ourselves on this too.

If you came here looking for SDN/SDS/SDDC

We are not it. A non-exhaustive list of where to go: Fraunhofer IESE’s SDX overview is a good neutral starting point for the category. For a vendor, a major hyperscaler or networking firm is the usual answer. We are happy to score the one you choose.