Discussions

News: ITToolbox Article: "Examining Enterprise Unified Process"

  1. ITToolbox has published an article by Soumen Chatterjee called "Examining Enterprise Unified Process." The article provides a directive guideline in the context of enterprise process and explains how EUP is used as an extension of RUP.
    The Enterprise Unified Process (EUP) is an extension to RUP concepts and best practices to fit it with all enterprise essences so that is best suit for enterprise organizations. The EUP introduces five new best practices as Proven architecture, Modelling, Collaborative development, Look beyond development, Deliver working software on a regular basis and Manage risk. The EUP includes two new phases and seven new enterprise management disciplines to handle multi-geographic presence and cross-system issues that organizations should address to be successful at IT.

    Threaded Messages (25)

  2. "Essences"?[ Go to top ]

    I smell envisioneering...
  3. Bullshit Bingo !
    I won.
  4. The EUP introduces five new best practices as Proven architecture

    How can you introduce a "new best practice"?
    The EUP includes two new phases and seven new enterprise management disciplines to handle multi-geographic presence and cross-system issues that organizations should address to be successful at IT.

    Two new phases and SEVEN new enterprise management disciplines. Hmmm, this should factor nicely into recalculating offshore ROI. I take it this is not an "agile" management technique.
  5. Scott Ambler's two faces....[ Go to top ]

    Hmmm, this should factor nicely into recalculating offshore ROI. I take it this is not an "agile" management technique.

    The irony is that Scott Ambler have been the one that defined the Enterprice Unified Process. So on one hand he finds that RUP was way to small and then he added a lot of stuff to it. When agile got really hot, he started focusing on Agile Modeling and focusing on "lightweight" methodologies.

    I guess that fashion and money also rules in the methodology business....

    http://www.enterpriseunifiedprocess.com/
    http://www.agilemodeling.com/
  6. fashion and money[ Go to top ]

    I guess that fashion and money also rules in the methodology business

    ha, ha! where else if not there..
  7. Hmmm, this should factor nicely into recalculating offshore ROI. I take it this is not an "agile" management technique.
    The irony is that Scott Ambler have been the one that defined the Enterprice Unified Process. So on one hand he finds that RUP was way to small and then he added a lot of stuff to it. When agile got really hot, he started focusing on Agile Modeling and focusing on "lightweight" methodologies.I guess that fashion and money also rules in the methodology business....http://www.enterpriseunifiedprocess.com/http://www.agilemodeling.com/
    Don't put all eggs in the same basket... ;)
  8. Scott Ambler's two faces....[ Go to top ]

    You cynics don't appreciate how "agile" you could be if only you put yourselves in compliance with this Enterprise Unified Process thingie and just bought a license or twelve of "IBM Rational Enterprise Unified Process Architect for WebSphere Application Developer Studio, Enterprise Edition" as soon at it hits the shelves.

    Question: I notice there is now a "Retirement" phase for software. Is that when the software in question gets acquired by Computer Associates ??
  9. Scott Ambler's two faces....[ Go to top ]

    Grow up.

    The reality is that project teams, and organizations, are all different. Different situations require different strategies. As someone who invests a lot of time helping organizations to improve, I've found that I need to offer a wide range of options so that we can find the right solution for the job. Some organizations need something comprehensive like the RUP, others need something closer to XP, and many need a combination. Any decent sized organization needs to manage many projects, and many systems, and therefore needs guidance that goes beyond what software development processes like the RUP and XP provide. Hence the need for something like EUP, which if you were to look at it you would find is very effective for what it acheives.

    As far as making lots of money, the fact is that I give away a phenomenal amount of process-related material. Just visit www.enterpriseunifiedprocess.com, www.agilemodeling.com, www.agiledata.org, and www.ambysoft.com to see that. In fact, I doubt very highly that you'd be able to find anyone else in the IT industry who has given away anywhere near that amount of material. Furthermore, if you were to invest some time to read some of the material, I suspect you'd discover that you'd find something of value.

    - Scott
  10. Scott Ambler's two faces....[ Go to top ]

    Grow up.The reality is that project teams, and organizations, are all different. Different situations require different strategies. As someone who invests a lot of time helping organizations to improve, I've found that I need to offer a wide range of options so that we can find the right solution for the job. Some organizations need something comprehensive like the RUP, others need something closer to XP, and many need a combination. Any decent sized organization needs to manage many projects, and many systems, and therefore needs guidance that goes beyond what software development processes like the RUP and XP provide. Hence the need for something like EUP, which if you were to look at it you would find is very effective for what it acheives.

    Scott, I have serious question about this. When you or anyone else comes up with these processes, are they tested? I mean, before releasing EUP, was it tried out by a number of large companies and then analyzed using some sort of empirical or psuedo-empirical data to determine it's effectiveness?
  11. Scott Ambler's two faces....[ Go to top ]

    Yes, it reflects experiences at several organizations. In fact, a feature of the book (but not the site) is that there is at least one case study in each of the discipline chapters describing application of the techniques in real world organizations (the names were changed to protect the innocent).

    Furthermore, we also provide references to relevant material, often books or other sites, supporting the concepts presented in the method. Take a look at the material posted on the site, do you see anything that really isn't just plain old common sense?

    - Scott
  12. Scott Ambler's two faces....[ Go to top ]

    Take a look at the material posted on the site, do you see anything that really isn't just plain old common sense?- Scott

    When you say that, I think "if it's common sense, why do we need so much material on it?" It seems to me that a lot of times software processes are antithetical to common sense. And lastly, common sense is sometimes wrong. What was the point again?

    But in any event, my problem isn't so much with the processes but rather that I find that management often treats the process as an end in itself. Where I work now, the process takes center stage over results. I can produce disasters but no one comes down on me unless I neglect to finish document C. That seems incredibly stupid to me. And instead of examining what is working and what isn't in our processes, we just get more process overhead over time.

    I also find that the parts of the process that should be owned by the business or management are pushed to the developers. By the end of it, 90% of the project cost is writing documents and 5% slapdash coding and 5% deployment.
  13. You need to be practical[ Go to top ]

    When you say that, I think "if it's common sense, why do we need so much material on it?"

    Wasn't it Mark Twain that said that the problem with common sense is that it isn't so common?

    It seems to me that a lot of times software processes are antithetical to common sense. And lastly, common sense is sometimes wrong.
    Yes, that's true. Everything is situational, so you need to treat processes as guidance, not as law. You still need to do the right thing at the right time, the process should provide good ideas and a general structure to follow. In the case of the EUP I think that we reach that goal. In the book we're constantly advising the reader to minimize documentation and bureaucracy and to instead focus on collaboration and communication.

    But in any event, my problem isn't so much with the processes but rather that I find that management often treats the process as an end in itself. Where I work now, the process takes center stage over results. I can produce disasters but no one comes down on me unless I neglect to finish document C. That seems incredibly stupid to me. And instead of examining what is working and what isn't in our processes, we just get more process overhead over time.I also find that the parts of the process that should be owned by the business or management are pushed to the developers. By the end of it, 90% of the project cost is writing documents and 5% slapdash coding and 5% deployment.

    Yes, this is a serious problem that I run into all the time. The book even includes anti-patterns to this effect, in fact that's another thing that I insisted we include in every one of the discipline chapters -- descriptions of really stupid things that management does. When we wrote the book I went out of my way to ensure that the material presented was practical and grounded on reality, you might want to consider actually taking the time to read some of it.

    - Scott
    http://www.ambysoft.com/scottAmbler.html
  14. process[ Go to top ]

    If you really understood RUP you'd realize how helpful it is in collaboratively fashioning value-added technology to simplify world-class solutions in order to synergistically create superior meta-services. EUP will surely do that and more.
  15. Rational[ Go to top ]

    I always wondered if RUP is what produced those wonderful GUIs in ClearCase and Rose. Every developer loves coding thouands of little modal, dialogs with non-resizeable 20 character text fields. It's also key to have 15 different applications in order to manage your source control. Error messages should never report useful info like why a file could not be checked in. Retreiving previous versions of files should be intuitive: you 'send' them to your 'briefcase' or 'my documents' where they are named clearly e.g. '34'. Finding out what happened during a rebase should not be reported up front. The developer should have to look for it. Managing the source control server should require years of training.
  16. Good job ![ Go to top ]

    First, I use EUP as a guideline and it is really a great help. Second, you can be agile with EUP. EUP does not complexify RUP but extends it at an enterprise level.
    As usual if you stupidly follow a method, of course this method seems to be un-agile; if you're mature enough to understand its philosophy you've a chance to be agile and efficient that all !
  17. Good job ![ Go to top ]

    First, I use EUP as a guideline and it is really a great help.

    Can you give an example of how it has helped?
  18. Good job ![ Go to top ]

    It help us to structure our enterprise method (with the Enteprise disciplines, additional phases) and also help us to introduce all the necessary maintenance activities into a global method.
    The Production and Retirement phases are also a good solution to define the full life cycle of a system (starting from the Inception).
    The Portfolio discipline is also a good help to document an enterprise change management process.


    For us, the less interesting discipline is the People Management discipline.
  19. Good job ![ Go to top ]

    It help us to structure our enterprise method (with the Enteprise disciplines, additional phases) and also help us to introduce all the necessary maintenance activities into a global method.The Production and Retirement phases are also a good solution to define the full life cycle of a system (starting from the Inception).The Portfolio discipline is also a good help to document an enterprise change management process.For us, the less interesting discipline is the People Management discipline.

    I'm sorry but this looks like a bunch of buzzwords strung together with synergy.
  20. Good job ![ Go to top ]

    sorry but it's just the truth not a list of buzzwords
    If you're an architect, you can understand that even for a method, the method's architecture is important. And EUP helped us to structure our method.

    But all of this is about maturity !! maybe in few years you'll understand :-)
  21. Good job ![ Go to top ]

    sorry but it's just the truth not a list of buzzwordsIf you're an architect, you can understand that even for a method, the method's architecture is important. And EUP helped us to structure our method.But all of this is about maturity !! maybe in few years you'll understand :-)

    Yours is a truly immature response.

    I asked for an example and you responded that it 'helped' with more words.
  22. Good job ![ Go to top ]

    I cannot give you a description of our method in this thread as you can imagine.
    The help is about the method architecture, the activities, roles, deliverables. The detail doesn't matter.
  23. RUP as agile[ Go to top ]

    I've heard from someone actually trying to configure RUP to become agile state the following:

    "You can make RUP look like agile, but it will never feel like an agile methodology"

    But true, I haven't tried to put a lot of effort trying to configure RUP to become more agile. One of the contributions that RUP gives are the templates. When you are trying to "slim down RUP", you still have the same templates. Some artifacts gets removed, but the remaining templates still are for a fifty person project - how are they going to fit a four person project?
  24. Agile RUP[ Go to top ]

    Take a look at the Agile UP product which I provide for free at http://www.ambysoft.com/unifiedprocess/agileUP.html

    - Scott
  25. Well ...[ Go to top ]

    <
    ... don't use them all, of course. Use the artifacts that work for you and are produced as a natural part of the workflow. For (a very oversimplified) example, class and sequence diagrams will actually be produced and used during development; vision documents will not. You don't need any 'experts' to tell you that. It's common sense, no ?

    As for Scott Ambler et. al. - why, oh why does anybody pay any attention to these marketeering types, who endlessly recycle ideas used in software development since the 1950s ? This industry has to have the largest proportion of useless crap merchants relative to total workers since the mutual fund fraud game became legal. It's like watching a bird feed its chick : it eats a worm, digests it, regurgitates it into the chick's mouth. Then it gets another worm and spits that out again ... repeat ad nauseum. The worms are all much the same ... they just keep getting repackaged and delivered. Be your own bird - don't eat the worms.

    (By the way the remark about CA was PRICELESS. Right on !)
  26. Feh and gah[ Go to top ]

    java.rmi.ServerException: RuntimeException; nested exception is: kodo.util.DataStoreException: java.util.NoSuchElementException: Timeout waiting for idle object