Rational Unified Process (RUP) started in the mid-1990s as a small manageable process framework. RUP was targeted specifically for building software within the context of an iterative lifecycle.
A Very Brief History of The Rational Unified Process
RUP quickly became the dominant process in the late 1990s, but was eclipsed by agile ways of working (WoW) in the early 2000s. RUP was effectively retired by IBM Rational in the early 2010s. Yes, RUP properly applied in the right circumstances could be very effective. Unfortunately, that often did not happen in practice.
Why RUP Lost the “Process Wars”
Over time, Rational (and subsequently IBM Rational) added additional guidance and artifacts to extend the applicability of RUP. This included package implementation, maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering and may other project types. In practice RUP suffered from several problems:
- RUP became unwieldy and hard to understand and apply successfully due to the large amount of disparate content.
- RUP was often inappropriately instantiated as a waterfall. Inception was a big requirements up front (BRUF) phase, Elaboration a detailed architecture phase, and Transition as a testing phase.
- RUP was often inappropriately instantiated in a heavy and onerous manner.
I Had Skin in the RUP Game
For it’s time RUP was an incredible resource. I did what I could to explain how to apply it effectively and to extend it where appropriate. In fact, I (co-)wrote five books specifically on this subject.
2 Comments
Paul R
The loss of RUP is definitely a step backwards, as it did provide a spectrum of flexibility and formality, driven by project requirements and risk, and we now seem to have to choose between Agile and waterfall. Just as RUP was mistakenly instantiated as waterfall, we’re starting to see the same happen with Agile, where we have excessively long Discovery exercises producing requirements baselines, with sprints effectively being milestones in a waterfall plan. This challenge is particularly acute in UK Government, where ‘Service Assessments’ are required early in the delivery lifecycle, which require a comprehensive specification of solution functionality. Feels like we’re heading back into the methodological Dark Ages sometimes.
Scott Ambler
In Disciplined Agile, see https://www.pmi.org/disciplined-Agile, we adopted many of the great ideas from RUP that I suspect you believe are missing in agile. And to be fair, they are very clearly missing from Scrum.