RUP is dead

RUP, according to Wikipedia, is an iterative software development process framework created by Rational Software. This has been successfully followed for many projects by all the Major System Integrators over the years. Until Now.

2 things have changed this. Open Source, Agile. One can say that the 2nd one is an assumed entity of the first initiative. Nevertheless, both of them have combined to make change to the way Software Development used to happen.

No longer are customers willing to wait for years to see their end-product. That is a big risk in current times. Customers also don’t have the patience to wait for a longer period to see how their application is evolving. Regular demos are very important in a project (so that early feedback can be provided).

In fact, new development projects are rare to start now. In the current recession, if projects can wait, they are put in cold storage.

The fact that each of the phase depend on a bunch of documents to be produced – which may or may not be used subsequently – is also discouraging project teams in adopting the RUP methodology. Code is always the best documentation of an application. If you have properly documented your code, chances are that anyone maintaining the application will be able to understand it better than a set of UML diagrams.

The Open Source Movement has also shown how well the Agile model of developing working code has worked. The use of Wikis and other Web2.0 methodologies also help in higher productivity among delivery teams.

Of course, this is not to say that Agile is the best model to approach – it has got its own pros and cons. One has to depend on the methodology based on the project needs and then decide. But, the use of RUP in projects have definitely reduced.


Tags: , , , , , , ,

8 Responses to “RUP is dead”

  1. ray ladriere Says:

    I am sorry to see that you fundamentally don’t understand the methodology. The process is not document driven nor requires the creation of large amounts of documents. the process is adaptable for all types of development from “high ceremony” high documentation efforts such as health, pharmacutical, or man rated defense or space missions.
    Commerical applications require less ceremony, and can reduce the documents creation level.
    the fundamental tenet of the proces is that it is risk driven architecture focused. In other words plan iterations, build core capabilities central to the architecture, addressing high risk items first.
    It is better to know “what’s left” is well understood than have a lingering high risk item in the applicaiton architecture.

    very disappointing article – you should have done your research.

    • Madhusudan Rao Says:

      Thanks for your comments Ray. Coming from a Rational background, I can see your inclination to support the methodology 🙂

      For long, one has seen that the Rational process has ensured that the projects become bloated and delivery cycles are delayed.

      If you want to deliver a project in 3-6 months (which is the norm today), Rational is practically impossible.

  2. Mark V. Smith Says:

    Ironically, not 30 minutes ago I was doing some light reading in Object Oriented Project Management with UML by Cantor. Chapter 3, Choosing a Development Lifecycle Model describes four lifecycle models which at this point we would call “traditional.” Of course there was the Waterfall model as described by Boehm which dates to the ’70’s, Boehms Spiral model, dating to the late ’80’s, Rapid Application Development (RAD) also from the ’80’s, and Controlled Iteration as embodied in RUP which gelled in the early to mid ’90’s.

    What struck me most is how really incremental the agile processes are rather than revolutionary. philosophically RUP is a valid response to the same pressures and conflicts that resulted in the agile methodologies, it just didn’t resolve these pressures for all experiences of object oriented programming. The phases map to problem solving methodology rather than artifact documentation methodology; the customer is included in the team; collaborative design that is allowed to change; tight iterations result in parallel analysis, design, implementation, and testing activities; use-cases (stories) define the build content; high visibility to the work in progress with usable, testable product at the end of each iteration; which of these have been discarded by Agile?

    RUP is a framework that does not define the level of ceremony, the CUSTOMER defines the level of ceremony. I would argue the reason the opensource movement and agile methodology are so closely linked is because in so many opensource projects, the developers ARE the customer and are not truly accountable to external entities for rigorous schedule and budget compliance.

    A better argument for the claim that RUP is dead would be that more and more, it is what software development in State Government projects looks like. By the time the State gets around to using anything, its gotta be obsolete. (That isn’t to say the developers are backward, just that documentation and accountability required by the bureaucracy of the State work against innovation.)

  3. Ayman Nassar Says:

    All projects regardless of how small or big need some sort of requirements traceability, iterative synthesis, change controls, modeling or representation, all of which are components of RUP. (I have summarized the main concepts of RUP on my blog at , even in agile environments you still need to do these items).

    Today we have projects of a more diverse nature and the portfolio of methodologies to choose from are wider – in all honesty, there is no new invention here. Call it RUP, call it agile, call it Bob’s methodology… at the end of the day our value as PMs or project/system architects is to customize the approach/methodology for whatever need is out there, and not implementing it as is.

  4. MengJun Jiang Says:

    We prefer to treat ‘Agile’ as a mindset more than a process or methodology.

    There are also many other discussions on how to tailor your UP process to agile or similar.

    We also see agile does rely on the team heavily, a simple ‘definition of done’ or ‘a not perfect user story’ or a not that so good customer relationship could struggle you down…

    And I would vote for this statement too ‘the process is adaptable for all types of development from “high ceremony” high documentation efforts such as health, pharmacutical, or man rated defense or space missions.
    Commerical applications require less ceremony, and can reduce the documents creation level.’

  5. Puneet K Says:


    If the project is 3-6 months old and RUP is not suited to meet project’s objectives, then its a case of looking for other methodologies. I something is not useful for you for ‘Few Project Types’, its dead for you.

    Not for COMMUNITY.
    Users of RUP are spread across the world. And its not DEAD for them.

    There are numerous cases of RUP being useful and still LIVING.

    Thanks starting this discussion.


  6. Jeff Milne Says:

    I led a team of 16 BAs, developers, DBA, and QAs – delivering a full-featured Loan Origination System as a SaaS product for consumer lending in just 16 weeks using an agile / RUP approach. The system was: about 120 screens, CRM at its core, Web-based / SaaS / SOA architecture, interfaces to the 3 credit bureaus, with full regulatory compliance using a highly configurable rules engine, and SAS 70 Type II certified. The database used an object / relational model that had about 3,000 attributes. The system served as a platform for additional products and derivative works.

    RUP is a set of tools that is more descriptive than prescriptive. It has a very adaptable framework that, if used intelligently, can accelerate delivery of high-quality systems. If the project team wastes time creating non-essential deliverables – that is not the fault of RUP, it is the fault of a misguided project leader.

    Jeff Milne, MBA, PMP

  7. hjoab Says:

    RUP after all takes care of the programmer/developer and of all aspects of development, SCRUM doesn’t. SCRUM’s rapid success is based in the over simplification and under estimation of the software development process and in the exploitation of programmers. If you cannot keep the pace you’re out. But who can really keep the pace? Let’s wait some years more when all this hipe from new graduates and new comers full of energy be burnned up. No nobody’s gonna save them.haha

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: