Yes, RUP is my baby by Ivar Jacobson

 I often get the question:  “RUP was your baby, but how do you look upon RUP today?”  In an interview a couple of years ago I responded jokingly: “Yes, RUP is my baby, but you know babies grow up and some of them need correction.”  RUP was created in Sweden under the name Objectory.  This was in 1987. 


Objectory was really new since its base could be used to describe all aspects of software development.  Our focus was to identify all of the rules that we use when we develop good software: what are good use cases, good components, good test cases, etc.  The literature in software engineering was totally empty in this space at the time. In order to do this we used object modeling to describe Objectory.  Now we could let the base grow forever – technically speaking.    Any company could make their own new process using Objectory.


Objectory became very successful.  It survived the merge with Rational in 1995.  The next version was named Rational Objectory Process, but after the success of UML, the name was changed to the Rational Unified Process or RUP as we all know it.  In the work of merging the two companies, the process content grew significantly.  However, hidden behind the size, our innovation of how to create a process base and the rules for goodness survived.  The crown jewels of Objectory had survived!


Thus, RUP is one of my babies.  The challenges with Objectory and consequently with RUP were serious. 


  1. Adoption
    Although our way of working in creating a process base was new and great, adoption became quite expensive.  To truly be successful with the adoption and consistent usage was to involve customization, mentoring and consulting which most customers couldn’t afford.  Thus the success rate was too low.
  2. Growth
    RUP was developed inside one company and all new ideas from the outside world had to be filtered by our own people and added to RUP.  It goes without saying that ideas come from anywhere in the world and by having a process be company owned makes it difficult to assimilate these great ideas.  The use of community much like what has been done with open source models would allow for continuous input and improvement.  This also allows for scrutiny. 
  3. Execution 
    All processes are paper-ware and often managed by people who don’t use the process.  This quickly becomes a problem in most organizations because the process becomes a religious document and not a realistic one.  This then has the effect that what teams do and what the process tells them to do is often not in synch.  And since the team is in charge (doing the work) the value of process becomes small.


These challenges paved the way for the agile movement.  The different agile methodologists have one thing in common: they hate RUP.  But that is NOT very smart. There are lots of good ideas in RUP.  Many companies have made the effort in adopting RUP and done so quite successfully.  This has provided them with a very competent staff and something to build on for the future.


However, “the baby needs correction”, and I and my company have done so.  The adoption problem is attacked by focus on the essentials and being light instead of trying to be complete.  We use cards and game boards to describe the process.  Moreover, you don’t need to adopt a complete process all at once, just adopt a practice at the time.  The growth problem is not a problem anymore, since we downplay big process and we make instead practices first class citizens.  Practices can come from any source including the RUP and much of the practice work we have done is in support of RUP adoption. Practices can be composed to create your own way of working.  Finally, the execution problem which is the hardest to achieve, is for the time being our little secret, but you are welcome to learn more about it by studying EssWork and EssUP. 


Trust me, this is very smart.

  1. Skip Pletcher | July 21, 2011 at 2:18 pm Reply


    If: a unified process project is risk-driven (especially in the first two phases) and uses a risk list of some sort to guide the team…

    Then: Does there exist some set of typical risks which are essential to every software project, a sort of ‘default risk list’ which the team can pare, tailor, and detail as necessary through the course of the evolution?

    Perhaps, for example:
    We don’t know what the problem is
    We don’t know what the solution looks like
    We don’t know how long it will take to deliver the solution (or how much it will cost)
    We don’t know whether the stakeholders (and subset users) will like the solution
    We don’t know whether the technical solution (architecture) will work
    We don’t know whether we’ll be able to deliver the full solution in time

    Does such a generic risk list already exist somewhere? Should it?

  2. Srinidhi Boray | July 17, 2008 at 8:00 pm Reply


    Large companies are riddled with complexities. Owing to this the enterprises are in constant transformation. This means constant changes in the requirements, which means changes to software specifications. The changing requirements within large enterprises are complex. It is here where RUP is very useful. I have had several rough conversations with the proponents of Agile modeling. They claim Agile is useful for small projects, where business analysis is not critical and when the development team is small (less than 10 people). Also, Agile folks quote Standish Report to indicate that about 75% of the projects in US are less than 10 people staffed. But they forget 80-20 rule. This means there are several projects which are large and over 100s of millions, and all of the large projects put together they make a mighty sum.

    Yes, go for a bicycle when it is needed to carry at the most 1 plus 2 people. Provided you want to put one person on the bike carrier behind and the other one on the bar in the front, if that is convenient. Also, with the soaring gas prices, this will be awesome, when you have to travel short distance. I used to do this and it used to be lot of fun. Well!! I guess now one knows how to build the argument in the contrary. When there is a thesis, then there is always an anti-thesis. Let’s say RUP is the thesis.

  3. Jurgen Appelo | May 14, 2008 at 4:23 pm Reply


    Ivar, thanks for sharing this with us.

    “The different agile methodologists have one thing in common: they hate RUP. But that is NOT very smart, in fact, that is stupid.”

    What people hate is a heavy process where lightweight methods are sufficient. I’m afraid RUP has always presented itself as a heavy process. Just browsing through the Kroll/Kruchten books makes the average software developer want to cry out in agony.

    In my opinion, it is the way RUP was presented that was the problem. RUP practitioners claim that one can downsize RUP to match small projects. But that’s not the best way of presenting a method.

    Would I buy and downsize a Boeing 777 if it’s only a bicycle that I need?

  4. mikemacd | May 12, 2008 at 8:58 am Reply


    Always interesting to read about some of the history behind UP