IT‑IS‑Networking
Technology › Design & Engineering

Reliability Engineering

Computing whether a design will meet its availability target before it is built — and treating drawn redundancy as a claim rather than a result.

Also known as Availability Modeling, MTBF, Reliability Block Diagrams, Single Point of Failure Analysis, RTO / RPO

Left to right is time. Each row is one of the 10 disciplines this one worked alongside, ordered so kindred disciplines sit next to each other rather than alphabetically — a landscape only means anything if neighboring rows belong together. Height is the work running in that domain in that year, weighted by what failure would have cost — life-safety ×3, a statutory obligation ×2.2, the estate itself ×1.5, an evaluation ×1. Every project declares which of those it was, so each ridge traces to an entry you can open and disagree with. Only the work that used this technology is counted, so what shows here is the company it kept rather than the record around it. Height and color are on the record-wide scale rather than this page’s own, so a modest estate draws a modest landscape and any two of these pages can be read against each other.

Drawn redundancy is a claim. Computed availability is a number somebody else can check.

The distinction is the discipline. Two paths on a diagram look independent; whether they are depends on whether anything is common to both — a carrier, a headend, a duct, a power feed, a building. A reliability block diagram forces that question, because a shared term collapses two parallel branches into a series chain no matter how the picture is drawn. Parts-count prediction turns a bill of materials into a mean time between failures figure against a published reference library rather than a vendor’s assertion.

What makes it worth doing in the right order is that findings become requirements. Run the model first and the weak links and the hidden common terms arrive while the design is still a draft; run it afterward and they arrive as observations in a report nobody is funded to act on.

It shows up in four places in this record. As the opening step of a utility SCADA engagement, where the analysis was commissioned before the design. As a seventeen-year practice in a city estate, modeling enterprise systems for robustness and recoverability. As the evidence standard applied to disaster recovery, where “tested” was given a definition most estates cannot meet. And as scoring criteria in a procurement instrument, where redundancy and survivability were kept as separate questions — the first asks whether a design absorbs a component failure, the second asks whether it keeps delivering service when it cannot.

Applied in

  • Citywide Network Total Cost of Ownership Study2023–2024A weighted scoring instrument for a manufacturer standard ahead of a refresh — which earned itself within three weeks, when a reseller's savings claim turned out to be priced against the wrong baseline.
  • Reliability Engineering Practice2000–2023A reliability toolchain bought for one utility engagement in 2000, carried into a city estate, and still running twenty-three years later — availability as a computed number rather than a drawn assertion.
  • Disaster Recovery Validation and Application Tiering2020Criticality bound to recovery objectives in an instrument rather than a narrative, and a definition of "tested" that the estate could not yet meet — reported rather than softened.
  • Public Access Wireless Program2005–2019Fourteen years and four program names — JaxWiz, municipal Wi-Fi, public wireless, Downtown Wi-Fi — from inheriting somebody else's pilot to a signed, mapped downtown build still being extended four years later.
  • JEA Utility SCADA and Redundant Control Sites2000–2004SCADA across 24 treatment plant sites on a SONET and ATM core — water and wastewater engineered as separate systems, with the control network separated from the corporate one two decades before the industry had a name for it.

See also