Solutions Architecture and Delivery Methodology (Agile, Waterfall, or Hybrid)

Overview

During Solutions Realization Planning’s Work Planning activity, a Solutions Architecture engagement must determine how the chosen Solution Set will actually be delivered. The IF4IT framework for choosing delivery methodology already exists: it treats delivery methodology as a fit decision, evaluated against four indicators — Consequence of Failure, which acts as a gate; Decomposability; Incremental Deliverability; and Time of Delivery — rather than an enterprise preference applied uniformly regardless of the work’s nature.

Hybrid delivery is a legitimate outcome of this evaluation, not a default compromise: it applies specifically when mostly Agile-shaped work contains isolatable Waterfall-shaped components with clean interfaces, separable workstreams, and defined reintegration points. Forcing all work through one methodology by policy, rather than applying this framework, is exactly the failure mode the framework exists to prevent.

Best Practice: Apply the Methodology Decision to Each Solution Set, Not to the Enterprise as a Whole

During Solutions Realization Planning, evaluate the specific Solution Set being realized against the framework’s four indicators, rather than assuming the enterprise’s prevailing delivery methodology automatically applies. A Solution Set with high consequence of failure or low decomposability may warrant Waterfall or Hybrid treatment even in a predominantly Agile organization, and the reverse holds equally.

Benefit(s)

Evaluating each Solution Set on its own merits avoids forcing a methodology mismatch onto the realization work — the same failed delivery, wasted investment, and concealed risk the delivery-methodology framework itself was built to prevent — rather than inheriting whatever methodology happens to be organizationally fashionable.