IBM to acquire Rational for $2.1 Billion

Discussions

News: IBM to acquire Rational for $2.1 Billion

  1. IBM to acquire Rational for $2.1 Billion (142 messages)

    IBM just announced the acquisition of Rational Software, maker of the Rose modelling tools, Clearcase configuration management tools, and many other development oriented toolsets. The $2.1 billion deal is IBM largest since the $3.5 billion purchase of Lotus Notes Corp. in 1995 and marks its latest move away from the computer hardware business that had been its trademark for decades.

    Read IBM to acquire Rational Software (from ibm.com).

    Before the Bell-Rational jumps, IBM lower, futures off.

    IBM to Buy Rational for $2.1 Billion.

    IBM sets $2.1 billion cash for Rational.

    IBM rachète Rational.

    What will this mean for the Rational tools? Will they continue to support non-Websphere-oriented development? Is IBM becoming too much of an ICT superpower to be healthy for our industry, and for Java/J2EE specifically? These are questions that I ask myself - and that I would like to discuss with the community. In any case: you got to hand it to IBM: they are executing on a fantastically strong strategy that allows them to be a formidable partner to Business-owners that do not mind being tied to a single-sourcing vendor.

    Threaded Messages (142)

  2. Imagine using Rational Rose to design Websphere applications. That thought is enough to make me want to switch to the .net platform.

    As far as tools and app. servers are concerned I'll take Together Control Center with JBoss, Orion, or WebLogic.
  3. I am coming from a strong java/j2ee back ground. I highly recommend the switch to .net. I did!
  4. <quote>
    I am coming from a strong java/j2ee back ground. I highly recommend the switch to .net. I did!
    </quote>

    Bill, is that you again, you must be very bored at Redmond today!
  5. We hate Bill but sometimes he is abosolutely right.
  6. <We hate Bill but sometimes he is abosolutely right. >

    More .not dollars at work. You think he cares whether he is right or not?
  7. .not dollars buy many things, including mind washing machines.
  8. Mackie: "I am coming from a strong java/j2ee back ground. I highly recommend the switch to .net. I did!"

     FROM:COL. DAVID OPONGA
     DEMOCRATIC REPUBLIC OF CONGO.
     EMAIL:davidoponga at writeme dot com
     Dear Friend,
      
     SEEKING YOUR IMMEDIATE ASSISTANCE.
     Please Permit me to make your acquaintance in so
     informal a manner. This is necessitated by my urgent
     need to reach a dependable and trust worthy foreign
     partner. This request may seem strange and
     unsolicited but I will crave your indulgence and
     pray that you view it seriously.
     My name is COL. DAVID OPONGA
     of the Democratic Republic of Congo and One of the
     close aides to the former President of the
     Democratic Republic of Congo LAURENT KABILA of
     blessed memory, may his soul rest in peace.
      
     Due to the military campaign of LAURENT KABILA to
     force out the rebels in my country, I and some of my colleagues were instructed by Late President Kabila to go abroad to purchase arms and ammunition worth of Twenty Million, Five Hundred Thousand United States Dollars only (US$20,500,000.00) to fight the rebel group. But when President Kabila was killed in a bloody shoot-out by one of his aide a day before we were schedule to travel out of Congo, We immediately
     decided to divert the fund into a private security
     company here in Congo for safe keeping. The security
     of the said amount is presently being threatened
     here following the arrest and seizure of properties
     of Col. Rasheidi Karesava (One of the aides to Laurent
     Kabila) a tribesman, and some other Military
     Personnel from our same tribe, by the new President
     of the Democratic Republic of Congo, the son of
     late President Laurent Kabila, Joseph Kabila.
     In view of this, we need a reliable and trustworthy
     foreign partner who can assist us to move this money
     out of my country as the beneficiary.
     WE have sufficient ''CONTACTS'' to move the fund
     under Diplomatic Cover to a security company in the
     europe in your name. This is to ensure that
     the Diplomatic
     Baggage is marked ''CONFIDENTIAL'' and it will not
     pass through normal custom/airport screening and
     clearance.
     Our inability to move this money out of Congo all
     This while lies on our lack of trust on our supposed
     good friends (western countries) who suddenly became
     hostile to those of us who worked with the late
     President Kabila, immediately after his son took
     office. Though we have neither seen nor met each
     other, the information We gathered from an associate
     who has worked in your country has encouraged and
     convinced us that with your sincere assistance, this transaction will be properly handled with modesty and honesty to a huge success within two weeks. The said money is a state fund and therefore requires a total confidentiality. Thus, if you are willing to assist us move this fund out of Congo, you can contact me through my email address above with your telephone, fax number and personal information to enable us discuss the modalities and what will be your share
     (percentage) for assisting us.
     I must use this opportunity and medium to implore
     You to exercise the utmost indulgence to keep this
     Matter extraordinarily confidential, Whatever your
     Decision, while I await your prompt response.
     
     Thank you and God Bless.
      
     Best Regards
     COL. DAVID OPONGA.
  9. Huh?

    Cameron? Is that you? Knock, knock.

    Duh.

    Sandeep.
  10. LOL :)
  11. I am coming from a strong java/j2ee back ground.

    >>I highly recommend the switch to .net. I did!

    And I highly recommend You study J2EE technology a little more. You don't know what you are saying...
  12. Agree, but if IBM / Websphere (with or without modeling) was my only choice for J2EE as .not is from m$, I would have never considered J2EE.
    For coding, modeling, and J2EE deployment (Websphere included, and if you must do all three from one tool), Together CC is the best environment.

    Nevertheless, the thought of having Visio as my ONLY .not modeling option would not only make loose sleep, but also opt for Websphere / Rational.

    Tools choice is what allows us to succeed.
  13. Check out PowerDesigner (www.sybase.com/powerdesigner).

    PowerDesigner is a great product, handles UML, can run rings around the data modelling in rational and can model .net components.
  14. Agree with you my friend....

    The news did not cheer me up..

    I like Pramati as a development tool and plan to stick around with it!

    Rob
  15. Oh

    Please give me a break, just use rational XDE from WSAD
    as we do and its fine.

    later
    leo
  16. Two point one BILLION dollars for Rational, we've just kicked them out in favour of TogetherSoft or is it Borland now?
    BEA would have been a better acquisition; at least they'd have one good product.
  17. I suspect IBM are trying to corner the crap software market.
    It's time the US Department of Mental Health Step In...
  18. "BEA would have been a better acquisition; at least they'd have one good product"


    Exactly, I was worried for Borland geting bought by IBM. I thought IBM would want to replace WebSphere with Borland Enterprise Server and get TogetherSoft in the deal.
  19. I am stunned.

    Whaaaat are they going to with it???

    Perhaps IBM are trying to build a monopoly on unusable software (this will get some flames ;-) I am only kidding)

    Seriously,

    We are evicting what ClearQuest we had for Jira.
    We are evicting what ClearCase we had for CVS.
    Rose was evicted a long time ago...


    WTF do IBM possibly hope to do with this junk? I would understand it if they only payed a fiver at a car boot sale ... but $2B??


    -Nick
  20. I think it's a good strategy for IBM. Eclipse is the only worthy competitor to Visual studio right now.
    And integrating UML tool with the IDE is the way to go and it's will be the way everyone will be going. Like it or not.
    And whoever wins the tools market wins the lion's share of corporate J2EE market.
    And it will be long-time before free open-source tools can match the tools like Visual Studio, Eclipse WSAD etc.
  21. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Eclipse is the only worthy competitor to Visual studio right now.


    Ah? What about IntelliJ's IDEA, it beats Eclipse hands down and has orders of magnitude more refactoring than Visual Studio .NET. At a few hundred $s it's good value too, perhaps not quite a cheap as Eclipse but hey, you'll get pay-back in days once you start using it.
  22. Rajnikant,
    A few problems with your predictions,

    1) For IDEs, have you heard of JBuilder and IDEAj?

    2) For UML, have you heard of TogetherSoft?

    3) For J2EE servers, have you heard of "EJB 2.0" compliant Weblogic, Borland Enterprise Server, JRun and Oracle9iAS (Orion), just to name a few?

    4) For Free, You may not know, but JBoss is better than WebSphere and JBoss is free!
  23. I have always disliked Rational's products for their poor usability. Rational and WebShpere will make a great pair!

    And while Visual Studio.NET may be great for GUI development, Intellij IDEA blows it away as an editor.

    And for Together, while I used to enjoy it, it has suffered from the 'bloat' factor. What happened to 'best of breed'?
  24. Yeah ...
    The only thing that IDEA Misses is GUI Tools, like UML/GUI Stuff. What if Borland grabs IntelliJ :?
  25. 1) For IDEs, have you heard of JBuilder and IDEAj?

    Yes. But I still think I'll go with Eclipse. It's all about choice.
    > For UML, have you heard of TogetherSoft?
    Yes. Could you tell me more about their model-to-code and ANT, JUnit and refactoring abilities and integration with my favorite IDE Eclipse.
    > For J2EE servers, have you heard of "EJB 2.0" compliant >Weblogic, Borland Enterprise Server, JRun and Oracle9iAS >(Orion), just to name a few?
    Yes. I think they are good. But we are talking about development tools here.
    >4) For Free, You may not know, but JBoss is better than >WebSphere and JBoss is free!
    Check out Jonas (http://www.objectweb.com/jonas) it performs better than JBOSS and if you're interested it's free and open-source too.
  26. <quote>
    And integrating UML tool with the IDE is the way to go and it's will be the way everyone will be going. Like it or not.
    </quote>

    I agree, but IBM could have done it a WHOLE lot cheaper buying a smaller company like NoMagic, makers of MagicDraw UML, which, like IntelliJ IDEA, is a terrific product and great value in its space. Plus, it already has Eclipse integration.

    Borland buying Togethersoft made me cry. IBM buying Rational makes me laugh.

    Btw, does this mean that the RUP will become the IUP? That would definitely be a boon for computer book publishers. They could publish new editions of every useless RUP book out there, and plenty of saps would buy them.

    -- Jason
  27. <snip>
    I agree, but IBM could have done it a WHOLE lot cheaper buying a smaller company like NoMagic, makers of MagicDraw UML, which, like IntelliJ IDEA, is a terrific product and great value in its space. Plus, it already has Eclipse integration.
    </snip>
    It's all about market share and customer base Rational has. Most of the money went for that.
  28. This means that Rational XDE .Net and others may or may not continue.

    Or is IBM getting more in to OpenSource Market ?

    IMHO The life of J2EE/Java Developer will become more easy. and Companies like BEA/Borland/MS will be kneeing to IBM to continue.

    And now we dont have any UML Modeler for .Net , or are we ?
  29. If IBM bought Rational just to kill XDE.NET that would make it worthwhile, sadly though I doubt it. It's an intersting question though about the future of the .NET range.
  30. <quote>
     This means that Rational XDE .Net and others may or may not continue.
    ....

    And now we dont have any UML Modeler for .Net , or are we ?
    </quote>
    I doubt that this would happen. I don't think IBM is that stupid. Why would they want to stop selling something when it get's them revenue?
    On the J2EE side it allows them to be a one stop shop. IBM Hardware + Rational for Design + WebSphere For Development.
  31. "On the J2EE side it allows them to be a one stop shop. IBM Hardware + Rational for Design + WebSphere For Development."
    -- R V

    That sounds a bit like WebGain, a proven failure.
  32. That sounds a bit like WebGain, a proven failure.
    ---Brian Miller
    I would give IBM Marketing a lot more respect than Webgain. To any big organization IBM sell's a lot of stuff (Think Lotus, Tivoli, DB2, Rs/6000's.). For these kind of customers it's one less one vendor to deal with and also an opportunity for some discounting. Plus For IBM it gets them access to Rational customers who are not IBM customers already.

    Disclaimer. I don't work for IBM and don't use any of their products (except eclipse which is technically not IBM). I am only Rational-izing the IBM decision -:).
    Cheers
    Ravi
  33. I really don't understand this takeover. Rational by all measures is outdated and outclassed in the modeling world (no pun intended), people seem to be moving on to Together if they have the money or open-source/cheap (e.g. poseidon) if they don't.

    So it would seem that IBM's name may be the only thing that keeps Rational going, rather than IBM gaining any decent technology out of the deal. I'm sure they could come up with one heck of a modeling tool/configuration management suite for 2.1 billion if they put their mind to it. Why bother with Rational?
  34. <SNIP>
    (except eclipse which is technically not IBM)
    </SNIP>
     
    Well it depends how technical you want to get, it's written but OTI and IBM employees, on IBM sites and paid for by IBM.
     
    <RANT>
    Rational offers IBM, Revenue, Customer Base, Brand, Products, Skills, and Comp. Advantage. It will most probably continue as a brand for the moment and I would expect to see further integration into WSAD and new products in the future.
       There seems to be an ever increasing feeding frenzy in the J2EE tools market as companies realise that their development timescales and budgets are rapidly heading back to the unpleasant days of C++ and CORBA. I see many corporate development shops going design crazy, getting very very hung up of the latest levels features and functions. I see previous generation development managers buying the BS they are getting from their realtively young and inexperienced "business mission disconnected" developers. I see unfinished, slow and buggy code in production because nobody other than the developers can get into the black box that is a running J2EE app and discover that "it has no clothes". There is no consideration for performance or how much these things are going to cost in production. I see n-tier architectures using XML to communicate between the multiple layers running in a single JVM! I see projects where over half of the effort goes into developing frameworks and re-useable code that is NEVER! EVER! EVER! re-used.
       I see amazing waste, and I don't see the tools simplifying the job. Where are the libraries of thousands of industry standard EJBss, where are the common object models, where are the drag and drop development tools that business managers could use? All I see are things like: 5,000 lines of application code, 20,000 lines of "framework" code (yeah right) and hundreds of EJBs just to maintain maintenance tables....(I kid you not)
       <RANT>
          Oh yeah for all those above who have given websphere a hard time, go and download the 5.0 demo, as I did, and take a look. You don't have to use it but at least appreciate it HAS improved.
       </RANT>
    </RANT>
     
    Paul
  35. Excellent <RANT> Paul.

    <MY_RANT>

    I see a lot of overdesigning too. I'm a contractor and the fulltimers I work with just got back from "pattern" training. The latest application design they have come up with has EVERY FREAKIN' PATTERN THAT THEY LEARNED IN CLASS. Layer upon layer of overkill.

    The BEST J2EE training in the world is being a contractor and moving from shop to shop. I get to see firsthand how NOT to do things.

    </MY_RANT>
  36. Right on, RC!
    While being just another way of writing expensive/poor software, overdesigning's siren song will still be heard for another while. ... I was about to rant some more about this but it certainly has nothing to do with IBM/Rational.

    IBM constantly proves that they have pretty focused management and I doubt the technology in Rational was what they were after (especially given the price tag).
    I certainly wouldn't compare them to WebLoss! (I still miss Visual Cafe)

    R.
  37. My Goodness, some really clueless people posting here today. Let me help you guys out a bit ..

    First, the trend in development is outsourcing. Now think about this for a bit. For 30+ years we have tried to develop software in the US, and while we have made some progress, its still done more or less in a haphazard way. There are a lot of reasons why (which I won't go into), but no one seems to think spending the time to get specs in place is important - or in some cases necessary.

    Now, I personally find it amusing that some people actually believe that outsourcing development is the "magic bullet". HELLO !!! Do you understand that now you are going to half to spend the time and money to start developing real life specs ?? Not half-assed ones, not semi-complete ones, but ones that actually tell the developer what the user wants. But wait !! Most companies don't have these processes in place, so there is going to be a cost (which isn't going to go away) to learn how to develop those specs, and develop them in a consistant fashion.

    Now in the long run, this whole process may actually end up improving the overall product that gets produced. And it *may* end up doing it a little bit cheaper, but I don't see how you can get that return without an investment.

    Personally, I think this acquisition is a brilliant move, and primes IBM for future success in this emerging market segment.
  38. "Now, I personally find it amusing that some people actually believe that outsourcing development is the "magic bullet". HELLO !!! Do you understand that now you are going to half to spend the time and money to start developing real life specs ??" -- George

    I infer from this that you consider Requisite-Pro to be the key product of the acquisition rather than Rose.
  39. Huh ??

    The Specs are one of several components that need to be built. Req Pro is a tool that will help you get the requiremnts into a standard format, but you still need to give the outsourcers some idea of how the business works. Remember, they don't know. So, you are going to need to describe it to them in some painful detail.

    Remember, they are 11,0000 miles away, and work while you are sleeping in the US. The more you leave up to their "imagination" the more the chance of getting crap back. Hence, you need to truly lay out all of the components you want.

    Remember, in today's environment you have employee's that work closely with business people to develop appliccations in the absence of spec's. How do you expect developers overseas to create code if they don't know your business ? Or your data needs ? To my knowledge, ReqPro doesn't capture these in a meaningfuyl way .... Not in a way that I would trust an outsourcer to develop an end result.
  40. Insightful, George. Very insightful indeed. Well said.

    Sandeep.
  41. What's your point George?

    If acquiring Rational won't help companies write good specifications how does it help IBM in the future that you envision?

    My perception is that management hasn't changed its approach to defining requirements very much. Those managers who always wanted to wing it in the past are still winging it.
    I've not seen a manager yet who learned from a bad or failed software project. The managers who failed because they wouldn't demand that requirments and software designs be written seem incapable of learning.

    The bursting of the .com bubble did away with a lot of these people, but it did away with some of the good managers too.
    Market forces seem to punish the good with the bad so I don't see the market solving this problem. If failure eliminated the incompetent in the software industry this industry would have shaped up a decade ago. Instead we see Microsoft becoming the world's most valuable corporation.
  42. Can you show me the line where I said Rational Tools won't help ?

    All I am saying, is that you ARE going to see a trend where creating Business Specifications is going to be a requirement - Not a nice to have. And you are going to need *some* process/tooling to make that happen.

    And if you read what I have posted, I have been saying exactly that - Not only doesn't our industry promote reuse (Web Services is going to be the closest we ever get), but learning from projects is rare (present company excluded !)

    With the acquisition of PWC and now Rational, it just makes sense to me what IBM's slant is. Personally, I think its going to work out quite well
  43. Here's the line:

    "To my knowledge, ReqPro doesn't capture these in a meaningfuyl way .... Not in a way that I would trust an outsourcer to develop an end result. "

    George, you started out by calling people "clueless". Then said that outsourcing would lead businesses to write specs. before having software developed. Then you said that specs. alone weren't enough and that knowledge of the business is also important, but that ReqPro doesn't help when it comes to capturing business process knowledge. Then you asked where you said that Rational tools won't help. Oh, and in between you said that this acquisition "is a brilliant move" for IBM and will help them in this new market segment.

    Sigh...

    Maybe you need to think your ideas through a little more or at least do a better job of writing them down before insulting others here.
  44. Dean,

    *SIGH*

    Perhaps YOU didn't read the thread carefully. Go back and look thru the number of posts where the focus was on "my tool is better than your tool", the tools are crap - all of which suggests typical "Religious wars" that we see in our industry, wars which always seem to impact productivity.

    The key here is the fact there are trends that are very very real. The nonsense I read had absolutely NOTHING to do with the acquisition. If that isn't clueless then I don't know what is.

    I stand by my statements that outsourcing is going to change the paradigm of developing Specs. I don't know what your definition of a spec is, but just a few paragraphs of "I want this" ISN'T A SPEC. You need details of what you want your business to look like, components you need developed, how you want them to interact and the data you need to keep. If you trust your "outstourcer" to magically dream all of this up, and get it right, then I argue you are making a huge mistake.

    So instead of plowing thru this nonsense of "I think this tool sucks", you might want to understand the real implications of this merger, and the impact it will have going forward.
  45. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    George - I first joined a software house 32 years ago and the big issue was capturing user requirements in a meaningful way. We weren't terribly good at it then and there has been no noticeable improvement since. We succeeded because we were trained to talk and, more importantly, listen to users in face-to-face meetings around a whiteboard (or in those days a flip-chart or the back of an envelope). Distance outsourcing will only work well for small projects until video-conferencing technologies improve enormously (I have recent experience of this). Not sure what this has to do with Rational because spec. (and modelling) tools are only useful for capturing specs not deriving them.
  46. <Quote>
    Not sure what this has to do with Rational because spec. (and modelling) tools are only useful for capturing specs not deriving them.
    </Quote>

    Exactly!! Anyone can learn who to draw the pictures correctly. The real talent (which a rare few have in my experience) is to determine what to draw.

    Daniel
  47. Requirements - on and on and on. Communicating requirements between development team, the users, and the business (yes, users and the business are two different things) is what I do.

    Everyone wants this process or that methodology, and they think it's going to fix everything. "If we just write it in UML, it will make up for the fact that we were given 2 weeks to do requirements for this project. If we use RUP, if we use XP, if we go to Agile...."

    It doesn't matter if you use UML. It doesn't matter if you're using Rational Rose or Together or any other tool. What matters is having good analysts who understand what REQUIREMENTS ARE and how to communicate them to a team. And having management support to do their freaking job.

    I've used UML where appropriate, I use the pieces of it that makes sense, it's bloated. I've used plain-text use cases. I've used Rose, and I've had to use Visio. Whatever works, doesn't matter, what's important is knowing the requirements and the development team so you know what they need communicated to them.

    And you've also got to have people around who understand that things are going to change, and we've got to work together to manage those changes. That means flexibility in the technology and someone in place to manage the users and the business.

    A fool with a tool is still a fool, be it the wrong people having to do requirements, or a manager with a development team.

    My 2 cents.
  48. Elaine,

    You are making too much sense. Why can't you just buy into the the tool/methodolgy sales pitch like most others?

    Excellent summary.
  49. Well, in my opinion IBM just take off there shirt and annoced 1-1 war on Microsoft.Bill gates look out.
    Ibm want to have there own Visyal studio.
    Remember vs6?they have that Data modoler which was aa try fro competing with rose-
    I dont know how the new vs7.net is look likes but i pretty sure that this is a ibm way to accknoledge microsoft that the j2ee,librety allince going to win.

    Another thought,Maybe IBM going in about 56 years to acquire Microsoft and then "rule the World".......
  50. For big projects, what we lack is true tracability from vision doc to code.
    RUP/UML does not help much in this area since there is still a gap between UseCases and business conception phase.
    The future of good software is just about this : getting rid of unstructured specs, and provide a mathematical way to go from the business strategy to the code...one might think to a kindof killapp such as a super-powerpoint that would just requires a mouse click to generate and compile the code.
    In fact, i do believe we really should get rid of ppt, doc and other non computerizable formats...A promising path to achieve what i intend to describe here is the B-Language and relative formal testing methods...
    Computer languages and methods have made a great step toward non IT people by making themselves more 'readable'. It high time, those non IT people, make a step toward IT and start learning formal ways to give us valuable/usable inputs.

    Laurent.

    PS : now that IBM drives XDE, i hope they will make it fully XMI compatible or at least provide a sort of mdl/mdx compatibility. BTW, can someone tell me why did Rational come with another propriatary format such as mdx ???
  51. "...our industry promote reuse..." -- George

    That was true of the C++ days, but the situation is quite different with Java. The JDK core classes and the various J2EE containers are pervasive successes at reuse. I'm having to write less and less code with each project since Java and its third-party open-source efforts are ever-more comprehensive.
  52. I completely agree with u. There has to be a way to get the developers understand the business too. Putting down the specifications into usecases or whatever is not sufficient.

    cheers,
    Lav
  53. Race wrote:
    >
    >The latest application design they have come up with has
    >EVERY FREAKIN' PATTERN THAT THEY LEARNED IN CLASS. Layer upon
    >layer of overkill.

    No worries. The naturally selective pressures of a competitive free market tends to take care of projects like that.

    >The BEST J2EE training in the world is...moving from shop to
    >shop.

    Yes, exactly. There's no other way to develop perspective and sensibility.
  54. I couldn't afford it for Java or .Net anyway. Maybe now I will be able to get it through the toolbox subscription.

    IBM has its hands in more than just Java. I can see the .Net product lines continuing. BTW, the standalone version of XDE is built on Eclipse.
  55. Who didn't see this one coming for a long time?
  56. OK, this brings the questions of who is going to buy Borland now. My bet is on BEA. Sun doesn't have its eyes on the ball at this moment and Oracle is already building/has Relational like functionality into its tools (Oracle Designer, JDeveloper).

    By the way, has anyone used Poseidon from gentleware? Is it any good?
  57. I have heard some good words about it .... but didnt see much usage of it
  58. It was interesting to know how everybody feels about IBM and Rational strategies.

    As far as I can see, this is really very good news for the Software Industry, as a whole. I guess, it just shows IBM's commitment to lead the Industry towards more matured process oriented Industry standards. Remember, Rational is NOT valued JUST for its UML Modeling tool. But for its dedication in setting direction in adopting process oriented development standards. Rational's MDA(Model Driven Architecture), Sun's Ace Project(http://research.sun.com/projects/ace/), the concept of Executable UML are all very much promising and now with IBM acquiring Rational, it could scrutinize to set the vision and improve on Development Practices in the next 5 years.

    Great News! I love it!

    Best Regards,
    Murugan Kanpa
  59. process oriented development standards


    :-O

    I think you will find that it is the failure of process-heavy development that Rational products have been in heavy decline...

    -Nick
  60. 2-ways to manage complexity...[ Go to top ]

    There are 2 ways to deal with the complexities of building quality software:
    1.) Adopt rigorous processes that minimize unintended consequences and missed requirements that can wreak havoc in long projects with rigid, hard-to-use technologies.

    2.) Reduce software complexity, increase productivity, improve architectural visibility, and enable applications to accept change more easily.

    IBM's focus on services and this move to embrace process(i.e. #1) are both natural reactions to not having products doing #2.

    ...The future of software is #2.

    Matt
  61. 2-ways to manage complexity...[ Go to top ]

    Exactly. Spot on.
  62. 2-ways to manage complexity...[ Go to top ]

    If I understand right, point # 2 talks about the 'Goal' and the point # 1 talks about the 'Solution' to achieve that Goal :-)

    Hence, are you saying: "To meet the future GOALS of the software as in point # 2, IBM is embracing point # 1? I agree with you, totally!
  63. 2-ways to manage complexity...[ Go to top ]

    No, I think we are not agreeing...

    The two approaches are aimed at the same goal. The first one is required only if the software takes a long time to build or is brittle.

    For instance, look at the planning/process/manpower required to send a man into space in the sixties.

    Now, The space shuttle is going up and coming down all the time completing all sorts of missions with a fraction of the process.
     
    Matt
  64. 2-ways to manage complexity...[ Go to top ]

    "IBM's focus on services and this move to embrace process(i.e. #1) are both natural reactions to not having products doing #2." -- Matt

    You well summarize the contest between RUP and XP. I once worked at a company that practised RUP, and my personal productivity was the lowest ever.
  65. Where does SUN fit into the picture........

    Is Sun going to be bought out by IBM
  66. HI!

    It seems that most people here don´t like Rational tools.

    However, I like it. Since we begun using them where I work, we had great productivity gains.

    Besides, all other tools I tested before (at least inside IDES, like JDeveloper - correct me if I'm wrong) are class diagram editors, and this is simply not enough for a comple project specification cycle, which includes a lot of other info and diagrams (Use Cases, State Machines, Deployment and the list goes on...)

    I don´t think there are another tool in the market as complete as Rational Rose Enterprise Edition. So IBM did a good move in its way to become the world leader in systems development.

    I have other question... Who´s next in IBM´s shopping cart? Who knows a really big one... Who knows.... SUN?

    Andre Augusto
  67. Don't know what happened in this thread, but it has totally gone ballistic. I was HOPING to have a useful discussion with 'the community' about the significance of this event. However, as it turns out this thread is a completely useless "i like this tool better than the other"-discussion.

    Very disappointing.

    Rik
  68. Very disappointing


    Yup. After a few posts a thread turns usually into J2EE vs .NET or IDEA vs. others or JBoss vs. BEA/IBM/Sun.

    yawn...
  69. Perhaps this event is not as significant as you would like. Based on the majority of respondees who dislike Rational products, I don't think most of us care.
  70. Hi,

    Rational's value as a company to IBM was really more from their brand name and customer base, rather than the value of their product line. They have a significant percentage of market share in the "development support tools" realm. And IBM plans to preserve the Rational brand name.

    Also, given that IBM and M$ are rivals in the enterprise OS and database realms, it will be interesting to see M$'s reaction to all of this. Rational software integrates with VS .Net.

    What's to stop IBM from stomping on MS? Probably nothing. :-)

    I still that Rational cranked out some pretty low quality software. I've used most of their tools extensively - there are parts that are good, and there are parts that are totally lousy.

    I don't think any of that is going to change though.

    This might open up the market for cheaper better tools from vendors who can be more responsive to user's needs. What the industry needs is lots more usable software.

    Sandeep.
  71. What's disappointing is most people say false claims about software because of personal opionions. When dealing with JBoss or other stuff people use the latest version as a comparison but everyone uses WebSphere 3.5 which is 3 years old. I mean WebSphere 5 is out, fully J2EE 1.3, production version, Axis software, WSAD 5 is out. Support for many J2EE 1.4 features.

    It's not fair, compare WLS 7 ro WAS 5 or what version of JBoss. WLS 6.1 to WAS 4. etc.. I don't see anyone using WLS 5.1 or Jboss 1.0 as a measure of what the application server supports.

    All tools and App servers have features that are better than others or worse. Those people that can only expose features in their favorite tool either don't want to try or just don't have the technical knowledge
  72. Agree. WSAD 5 is really good development tool. Some features are better than IntelliJ and JBuilder.
  73. Where did you get WSAD 5 from?[ Go to top ]

    we've got 60 day trial of WAS5 but cannot do CMP/DB mappings without WSAD5 - can you download a trial version from somewhere?
  74. Where did you get WSAD 5 from?[ Go to top ]

    we've got 60 day trial of WAS5 but cannot do CMP/DB mappings without WSAD5 - can you download a trial version from somewhere?
  75. Roland,

    Yes, I see many people have their opinions based on older version of the products.
    But I guess that it points out that using free open source tools like JBOSS makes it easy to run latest version all the time. It does not cost anything apart from download traffic.
    At work, we use some of older version of tools because of non-technical reasons (usually financial or failure to make a good business case). When we moved to OS tools like Ecilpse, Ant, and XDoclet, one of the key rationale was that we, developers, could keep up with the change in technical trend and get the benefits sooner than wating for approval of the PO and other process ....... required to obtain commercial s/w.
  76. I have a different perspective on this. And its a methodology one.

    OK, first real methodologies I got into where Schlear Mellor, Booch (2nd ed), ROOM and that other one... Of them all Booch was best, especially the clouds, fluffy, nice.

    They made loads of money and flogged tools to those few shops that gave a damn.

    Then UML comes out, and changes to boxes and they all make more money. Basically the message is 'Those methodologies we made up before we all crap, but this new one is spot on'.
    This time, the industry in general is strugling with OO and needs help in the form of boxes for objects. UML wins.

    But, there are others who want a slice of the mothods pie. So they think anti process and invent agile - cos it's pretty much all thats left outside of UML. And to sell product they need a message.

    At this point, loads of folks have gone through the UML object diagrams which paper the entire office wall and so are ready for agile.

    UML launches even more tools, and starts pretending they are agile as well. But the message is a bit weak, "Our current methodology is still great, look, it's so great that we can do process and anti process all at once, just leave bits out, or use anti-process in between the process bits.'

    So, I was wondering what the booch,uml heritage guys would do. a) retire and have a good laugh. b) invent something else, and make money off the same people all over again.

    So, does the death of UML (via Agile, and too many folks with real experience), and the death of rational (via IBM) spell the release of the methodology gurus? Are they now free (well, after a tie in) to invent the 'Gestalt Uber Methodolgy'? Come on folks, we all need another methodology, and the vendors need some new ones too.

    Jonathan
  77. Perfect. I am repeating the previous message here !

    Everyone wants to invent a methodolgy better than the pervious one. 'Process' and not common-sense is the buzzword. Then when the Process market gets saturated, invent anti-process. Make crap tools for both and sell !!

    The CIOs meet the Sales People of companies like Rational, and buy this crap, and give it to the development teams, who in turn are forced to throw away their common sense, and adopt some processes and tools. Then half-way thru the project everyone realises that what they have achieved is all paperwork and no work.

    Today we have UML, tomorrow VML, WML, XML, ZML. And many make money, some lose. Can we have some Technical Managers at the top taking decisions, instead of people who have no idea what it takes to execute a project ?
  78. Rational gets bought for 2.1 Billion Dollars.
    Not sure if this is the right forum to ask this but... i haven't heard any comment on pricing . Is the Rational Deal overpriced ?

    (Lotus bought for 3.5 Billion Dollars, PriceWaterHouseCoopers gets bought by IBM for 3.5 Billion Dollars.)
  79. Regarding Agile Methods as the death of UML and agile being anti-process, you must remember that agile is not just XP. Feature Driven Development is an agile method that incorporates process. FDD requires software design (usually done in UML).

    So agile isn't always anti-process and anti-UML. XP may be anti-process.
  80. Micheal you may sound happy using TEXTPAD
  81. Yeah, but both BEA and IBM release free developer versions of the app servers for developers to catch up on the trends. Eclipse was created by IBM and the majority of the developers work for IBM so I would say they embrace open source as well.
  82. I would think IBM saw past Rational's failed suite strategy towards Rational's new XDE product and its tight integration with WSAD. WSAD5 is a great tool in itself and combined with XDE it will be formidable. The combined per seat price should drop too. Also, as app servers become commoditized, as IBM appears to be discounting WS to buy market share, the tools are the differentiater that close the J2EE and process learning curve and risk gap to get the sale. Rational sells to IT managers who want to look organized although developers may hate the stuff. XDE is different. I use it and like it. It's a crutch, it's a mentoring tool for those learning UML and J2EE, and a candy and a gum. It helps me communicate, makes me look smart, get's me dates.

    I don't know where the .Net XDE product plays out, hmmm?

    Death to flexlm. Cheers to the three amigos. They have realized their final use case.
  83. It's so good that Rational is gone. Their bad products are showcases of what happens when you employ RUP to software development.

    Sun used to have a bad habit of buying trash on the market, look at their iPlanet. Now IBM's surprising us.
  84. IBM knows software and it knows their business pretty well. $2.1B is a relative figure and they are doing this for reasons they believe will be profitable. While I am not a fan of Rational, I'm sure the OpenSource evangelists within IBM (yes they have them) are scratching their heads.

    Overall, this may be good for the tech industry and the overall tech market. Remember guys, this market sucks right now and anything to help keep it alive should be something we should consider positive. Perhaps Rational was about to take a nasty fall that would have hurt the industry economically and IBM came to the rescue... Perhaps not...

    liquid
  85. IBM seems to be capable of creating very good software like OS/2, but then it is also capable of creating lousy software like WebSphere.

    You may be onto something when you mention the financial aspects of the Rational acquisition. The Wall Street Journal article on this merger quoted an IBM vice president on how this would affect their bottom line in the near future, but said nothing about how it would affect their products. IBM may have been just buying cash flow and a customer base rather than a product line.

    Marketing has always been more important than engineering when it comes to selling software.
  86. Bingo. It's about the marketing. The fact remains that Rational has a large install base in the highly coveted "enterprise" space. I put "enterprise" in quotes because usually it just means big spenders, and not necessarily smart companies.

    Also, don't forget that this board is crowded with technical elites -- really, if you are reading this, you are one. Most CIOs are not technical elites, and if a product comes from IBM, like their mainframes and their Intel servers, they'll buy it. IBM bought a revenue base with the hopes that they can cross-sell the product into existing IBM shops. Don't overthink it. People really are that gullible when it means not risking their $250K/year jobs.
  87. We are using Websphere APP Server 4.03 for year we didnot run into any issue. Some of our WAS appservers have been running for 6 months with zero down time they take like 6 million request per day.

    I think Websphere 4.0X is thousand times better than weblogic 7.0 . Now Websphere 5.0 has come out and it has all 1.3 J2EE features EJB 2.0 . WAS 5.0 is easy to install and administer I think Weblogic is very hard to install when it comes to application and tuning Weblogic 7.0 it is a nitemare even their constultants seems to be confused how to tune weblogic 7.0.
  88. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Some of our WAS appservers have been running for 6 months

    > with zero down time they take like 6 million request per
    > day.

    Dont believe you.

    > I think Websphere 4.0X is thousand times better than
    > weblogic 7.0 .

    Is it exactly 1000 times better, or is it more like 1500 times better?
  89. Is IBM going Microsoft way?
  90. Is IBM going Microsoft way?


    He, he, this is an old IBM way that Microsoft "embrased & extended", :) .
  91. Design Models are Useful[ Go to top ]

    I don't know where the idea that analysis or design models are not useful in themselves came from. I cringe whenever I hear about draw a model and generate the code.

    I've been useing a demo version of Rose 98 for 5 years now. It is limited to 30 classes in a model, but that is nore than sufficient to layout out the basics of a central design concept in a complex system. It is then a great blueprint for the developers. But I'm certainly not going to put every get/set into the classes so that it can stay syncronized with the code.

    Daniel
  92. Design Models are Useful[ Go to top ]

    IBM has good tools but they continue to fail in marketing the value unless your true blue. IBM in the past had agreements with Rational products so I would think Borland and BEA are driving up the ante to build better software faster. IBM will take the methodical approach to integrate this with their service org. to generate more project people and time to pay for this aquisition. I've always thought if you don't believe in strong development processes then Rational software was not for you, must be pretty diciplined to make it worthwhile over the long haul. Especially in large organizations otherwise you have piles of shelfware and lots of $$ spent. IBM fills in some product gaps here, just expect all the product titles to change by putting "websphere" in front them in order to further confuse the product line:)

    I'm interested to see if they continue supporting .net with XDE or just sell it off to msft or other 3rd party.
  93. Design Models are Useful[ Go to top ]

    <quote>
    I'm interested to see if they continue supporting .net with XDE or just sell it off to msft or other 3rd party.
    </quote>

    I don't think they will keep supporting .net for very long. What I'm sure is that there is no selling any piece to MS. The reason Rational sold to IBM is that Microsoft is building analog functionality into Visio. So you can expect that by the time MS gets Visio right, the market share of Rational in the .net platform will be very small (or do you expect MS to play fair and make Visual Studio integrate well with XDE as well as with Visio).

    I think IBM will keep the XDE integration with .net as is. They will try to lure XDE users to WS with migration toolkits and good deals. The people that stick to .net will be sooner than later using Visio.
  94. Rational was vendor neutral in its XDE code generation. It generates WebLogic descriptors as part of its deployment process. Now I wonder how long this will continue. XDE comes in three flavors, WSAD plugin, Workbench (Eclipse) plugin, and Visual Studio plug-in. Two will die on the vine I foresee.

    I think I'm migrating to xdoclet anyway. Middlegen looks like it will fill in the gap for CMR. As for a modeling tool, Dry-Erase markers and Visio UML stencils work very well.

    As for the detailed requirements for offshore dev. I don't think ReqPro is a substitute for vision and commnication even if its in the middle of the night.

    cheers
  95. I agree that some of Rational's products has some issues, but when you look upon Rational's customer base, many of the large companies uses Rational's product.

    If you look at the products I think that the acquisition makes sense. Rational has products focusing on Requirements (ReqPro), Configuration Management (ClearCase), Change control management (ClearQuest), modelling tools (XDE is the future for Rational/IBM here), Testing tools (a lot of them) and the process. In ALL of these areas does IBM lack tools.

    I wouldn't say that these are perfect tools, but Rational have done a considerable effort trying to unify these products. Might be this IBM have focused on. If they we're to buy several small companies (maybe better tools) they still would have to do the integration.

    Just my few thoughts.....
  96. Is IBM going Microsoft way?


    IBM embraced opensource Linux, Java development I dont see the Evil empire M$ doing that.

    Bill Gates still talks down on Linux and Java.

    As a matter of fact all we have seen is M$ trying to choke every competetion out of the market they are in everything.

    OS (Windoze), database (SQL server), exchanage server, web server(IIs), security, dev platform (.Not), MS office, games (xbox), tv, hand held, pc hard ware. ( all piece of crap )

    MS is a pure monopolistic evil empire.
  97. Come on, Rational and Together and all the rest are over priced and over bloated unusable tools. All the refactoring i need is regex, and Visual Studio .NET has great search and replace capabilities. I didn't see anything like that in Idea or Jbuilder.
  98. <All the refactoring i need is regex, and Visual Studio .NET has great search and replace capabilities. I didn't see anything like that in Idea or Jbuilder.>

    Use some of your .NOT dollars and get Together, it has very good refactoring as well as search and replace. Latest versions of JBuilder and Idea are very good also.
  99. Michael: "Come on, Rational and Together and all the rest are over priced and over bloated unusable tools. All the refactoring i need is regex, and Visual Studio .NET has great search and replace capabilities. I didn't see anything like that in Idea or Jbuilder."

    Might as well use emacs then. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  100. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    I still fail to see a clear strategy on IBM's part (other than acquiring the Rational customer base). Weren't they trying to reinvent themselves by embracing the open source, anti-process approach? All of a sudden, in the midst of it, BAM! they throw 2.1 billions at the most rigid, structured process approach there is. What gives?

    It gets to be really hard to preach the repulsiveness toward the big upfront design (extreme programming), and at the same time preach the necessity of a big upfront design. They are contradicting themselves big time.

    Personally, I don't believe in extreme programming, but I'm also skeptical towards big upfront design. I think both approaches are facing the wrong direction. Both are obsessed with *how* to do things, leaving out the *what* (and the *why*). Without a reasonable 'what', everything is doomed to failure. You can have the most perfect 'how' methodology, it won't help you one bit if you don't know what you're doing. Unfortunately, all those tools and methodologies are only concerned with 'how'.

    'How' is the easy part, and a team of experienced implementers will beat any tool and any methodology on any day. That's what all those 'visionaries' fail to see.

    But the biggest problem is communicating *what* is it we are trying to build. That's where most of the confusion arises. Software being the intangible phenomenon causes people to form different pictures and different goals even when working on the same product. Because of that, the resulting thing is almost always a dysfunctional monster that typically fails to deliver.

    So the only solution is to focus on the area where such errors creep in. And neither Rational, nor XP, are doing that. Consequently, they won't be able to deliver in the long run.
  101. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Hello Alex:

    You said

    "So the only solution is to focus on the area where such errors creep in. And neither Rational, nor XP, are doing that. Consequently, they won't be able to deliver in the long run."

    I've also been asking questions about which process provides can deliver in the long run. I've been unable to find an answer. If XP and rational are doomed to fail, do you know of a process that will not fail?

    Thanks
    Abongwa
  102. It's not about the *process*, it's about the people you have doing it. You need good architects/analysts, who understand analysis isn't about the code or the technology, it's about the functional requirements, the *what* of the technology. As stated before, the process is the *how*. Underneath that, you need people who understand analysis for OO development teams.

    From what I've seen, XP is not enough, RUP is way too much. There's a middle ground we have to reach. But what is important is getting the right information, not how you make it look on a piece of paper or what notation you use or what you call the deliverables.

    Sorry if this is vague, but the requirements problem has a lot more to do with the requirements analysts and management than which methodology someone buys into.
  103. Elaine,

    Re: Middle ground.

    Have you actually managed to work this through and discover an appropriate middle ground?

    I'm pretty much in the same boat. RUP is way too heavy-weight. True, you're supposed to be tailoring it to the specific needs of a project, but even that proves to be time consuming at times.

    XP is good, but there seems to be a sense of formalism missing.

    What have your experiences been in this regard?

    Sandeep.
  104. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Elaine wrote:
    "It's not about the *process*, it's about the people you have doing it. You need good architects/analysts, who understand analysis isn't about the code or the technology, it's about the functional requirements, the *what* of the technology. As stated before, the process is the *how*. Underneath that, you need people who understand analysis for OO development teams."

    I absolutely agree with you. The trouble is, where are the people? Show me people!

    Most people I've worked with were severely undereducated for the responsible positions they were occupying. I'm not saying this to belittle them, only to point to the fact that we don't have apropriate education venues where people would be trained in those skills. I know this, because I'm teaching software development at several local educational institutions. All the educational coordinators want to do is allow us to prepare courses that they could understand. Of course, when I suggest that I should deliver a course on goal-oriented design, they refuse me flatly, because, you know, what the hell *is* a goal-oriented design? Who's ever heard of it?

    So, it's the chicken-or-the-egg situation.

    "From what I've seen, XP is not enough, RUP is way too much. There's a middle ground we have to reach. But what is important is getting the right information, not how you make it look on a piece of paper or what notation you use or what you call the deliverables."

    Again, I couldn't agree more with you! People like yourself give me hope for the future.

    "Sorry if this is vague, but the requirements problem has a lot more to do with the requirements analysts and management than which methodology someone buys into."

    Absolutely true. Elaine, where do you work and would you consider coming to work for us?

    Alex
  105. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    I'm flattered. :)

    I've worked for a lot of different places, which is probably the point. I've seen things fail too often, and I've seen them work, and I know what works.

    Get someone on your team who understands use cases (Cockburn's book is excellent on this) and task analysis. Make sure they also understand usability. Partner them with a technical architect who understands both the tehcnology and the business. Make sure they get along famously and understand who is responsible for what. I never talk technology to users, the developers trust me to handle requirements. Make sure both of them are OO, abstract thinkers for a Java team.

    Get a good project manager who will listen to them both.

    Do strategy. Work with the business. Build a business case for the system and ROI justification first. Get organization buy-in.

    Do analysis. Do enough of it. Build good, solid use cases. Build class models. Check them against each other. Make sure your technical architect and your analyst are both OO, so they can speak the same language.

    Do design. Design revolves around use cases and class models. I usually do the user interface, the developers focus on the technology and the code. The developers do state transition and sequence diagrams, not the architect, helps them work through the code. We stay in close contact. If anything happens that affect the class model or the use cases, we coordinate that. I map the user interface to the class model, so we're all on the same page.

    We manage our users and the business. We've got to have a great project manager for that. I've met precious few, and the ones that are good are worth everything to a team.

    And then, we code. We use iterations. The base class model and use cases live under the iterations and give us the big picture.

    It works. I've done it. This is the only way I'll work now.

    E-mail me if you want to talk further - jbrownson at usa dot com, I don't want to drive this board nuts with this. :) It's off-topic for the Rational/IBM debate.
  106. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Hi Elaine,

    You wrote:
    >Make sure they also understand usability.

    I tend to keep usability aside. It's a different issue, the one that can be solved by a separate team of experts. I can try to explain my rationale as follows:

    Suppose I'm in a situation where I need to sign a very important document. Time is critical, and I need to sign it right away, or forget about the deal. To my horror, I realize that I forgot my pen!

    I'm scrambling, looking around in embarrasment. Finally, someone hands me a pen. A grab it in gratitude and scribble my signature. I'm greatly relieved.

    Now, the pen I've used to sign that important document may have been very usable, or extremely unusable, or anything inbetween. But, whatever it is, it served the purpose. One could criticize its usability features, or one could choose to abstain from criticizing it.

    In any case, the usability of the pen could be improved later. But the point is, we don't have to wait until the pen was made more usable. That's why I say that usability is an aside issue, that can be treated separately from the software development process.

    >Do design. Design revolves around use cases and class
    >models.

    I am more interested in practising the so-called "quality before design" discipline. In other words, I focus on quality, and will not allow a single line of design to be made until we're absolutely clear on the definition of quality for that project.

    Alex
  107. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Alex,

    Your views are no doubt typical for many. Nevertheless I disagree. At least in products (which is the only thing I work with) the usability is by a power of degree more important. Do the UI interface first, then hand over the rest (less important work) to the server programmers. As long as it is fast and maintainable it doesn’t matter greatly.

    It is the "quality before programming" principle.

    Regards
    Rolf Tollerud
  108. I'll try to address both of you.

    First, Alex. I usually work with a seperate usability person on my team, God bless her. But, one of the tenents of usability is we build for the users. It's not just about the user interface, it's also about task analysis and building what users need first. It's that understanding of the business and the users and what they need. It was that piece I was referring to. The point is (and you stated this earlier) we are building these systems for users, for people.

    In my experience, as I'm working on drawing out those task scenarios and capturing them, a good object architect can find the high-level classes as we're talking. It's an analysis tool.

    WE DO NOT DISCUSS TECHNOLOGY IN ANY WAY UNTIL ANALYSIS IS DONE, PERIOD. OO is not just technology, it's a way of thinking and organizing independent of a single technology.

    Rolf, I disagree with you. In an enterprise environment, you have to keep the objects and code in sync with the interface. Developing code on the basis of an interface architecture leads to brittle, unextensible code, because it reflects the system at that current state in time, not how it may need to extend to the future. So, we build code on something more extensible, which is an object architecture. We base that code on the real world of the business and task analysis, that is our underlaying foundation. And no matter how you capture it, that is what every system needs to revolve around.

    That is my ultimate point. The information needed by everyone is what the system needs to do. You discover that by looking at the business and the tasks around supporting the business. It doesn't matter how you capture and notate it, that piece of information is what needs to be communicated, and it needs to be communicated in a way that development teams can understand. When I'm dealing with a Java team, we talk in objects, and we all understand each other.

    You need analysts trained to go after that information, then communicate it to an OO team.
  109. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Elaine,

    >WE DO NOT DISCUSS TECHNOLOGY IN ANY WAY UNTIL ANALYSIS IS
    >DONE, PERIOD.

    Music to my ears! There is nothing more important in the world of software development than the above sentence.

    Re the usability: something could be more or less usable, which makes it more or less frustrating to the user (nothing is totally usable, as I'm sure you'll agree). But there's an even more important issue -- is that 'something' even there? My job is to make sure that I come up with that 'something', that I make it available. Then, I pass it on to the usability guys to polish it and pretty it up a bit.

    >It's that understanding of the business and the users and
    >what they need.

    I don't fret too much over what the users need. People need many things. For example, right now I need, among other things, to undergo a root canal operation. Not something I'm really looking forward to, I can assure. Or, pretty soon I'll need to file my income tax return. Also not something I'm looking forward to (actually, don't know which one of these two I'd like to avoid more). Yet, I need those things, there's no two ways about it.

    So, if I offer to my users something that I know they need, that's not a guarantee they will like it. If I want my product to be a resounding success, I must offer something that I know my users will *desire*. That's the key in the goal-oriented design.

    Alex
  110. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    We're saying the same thing, getting caught up in the semantics.

    *What* we do is look for system requirements based on goals. Those goals support the purpose of the system, which always revolves around a business need of some kind. None of these systems are free.

    We will have different ways of *how* we go about that. I am a senior information architect, and I work almost exclusively with Java/OO teams. My approach in how I communicate with them is different...and it changes for every team, it depends on what they need from me. I have to be open to the team I'm working with. Some teams need more, some less. Some use Rose or Together, some Visio, some follow XP and use CRC cards to model. I've worked with many different teams in different circumstances, and my basic job doesn't change. I'm still going after the *what* of the system.

    No matter how we get there, we still need to know that. Too many times, we neglect it. In my experience, software developers LOVE it when I join a team. It's management I have to fight to get this done. "Why can't we just code it?"

    I suggest Alan Cooper. I suggest Mark Mayfield and Jill Nicola's books, they taught me. I suggest Peter Coad's methodologies at TogetherSoft, he taught Mark and Jill. I like Scott Ambler. I love Alistair Cockburn. Read it, and take what applies to you, your team, and your situation. Then figure it out for yourself. But go after the *what*, apart from technology, then get to the *how*.

    Then beat your managers and project managers with a 2x4 until they get it too.
  111. Hi Elaine,

    You said:

    "I suggest Alan Cooper. I suggest Mark Mayfield and Jill Nicola's books, they taught me. I suggest Peter Coad's methodologies at TogetherSoft, he taught Mark and Jill. I like Scott Ambler. I love Alistair Cockburn. Read it, and take what applies to you, your team, and your situation. Then figure it out for yourself. But go after the *what*, apart from technology, then get to the *how*.

    Then beat your managers and project managers with a 2x4 until they get it too. "

    Just add a little of Constantine and Lockwood to your mix and presto life is good!

    Your point of what applies and what situation is exactly what software designers are supposed to do.

    For example, I'm using some of RUP and Constantine's Use Case approach for my J2EE projects.

    The point is, I'm able to survey the ideas out there and apply it to my needs. My needs (everyone) are usually to deliver an application that meets or exceeds my users expectations. I'll use any artifact that will help achieve this goal.

    Very simple concept, but extremely difficult for those who don't get it. I'm a software developer and I enjoy writing Use Cases, rare, I know. So, I try educating Project Managers and Systems Analyst - what Use Cases are for.

    But, I still get:

    The system shall this
    The system shall that...
  112. ARGH! Thank you, George! I was trying to remember who wrote "Software for Use." One of the first software analysis books I ever read. It's been stolen off my bookshelf twice, I don't mind. The more who read it, the better.
  113. Elaine,

    Your reasoning is way of too abstract and high level to be of any use.

    If you are building an HR package you look for someone that have involved in HR, if you are building an Survey Analyze program you look for someone who have 2-3 such programs under his belt, if you are building CRM - I'm sure you getting my drift. In other words, you look for people (architects, programmers) that have a lot of experience and have a "NAME", reputation, from the specific business problem in question.

    <Q>So, we build code on something more extensible, which is an object architecture. We base that code on the real world of the business and task analysis, that is our underlaying foundation"</Q>

    Sounds like a marketing summary for some executive meeting..

    Regards
    Rolf Tollerud
  114. Rolf, you seem to enjoy insulting people, that's a pretty pathetic hobby to have. You should learn how to have a civil discussion with people, and not feel threatened by it.

    Now, our discussion. I agree with you when you're talking about simple systems, such as an HR application that handles employee records. However, when building an enterprise system, you need much more. Example: We need to capture order information, such as order location, who placed the order, and all materials needed to fulfill that order. That order needs to be routed to the proper fulfillment group, and that is defined by location and materials needed. That information lives in SAP. You need to get that information to tell the system what to do. You also need to update inventory in SAP so the materials will be reordered when the inventory gets too low.

    You also need to push the order information to the customer's system, real-time. There's no user interface there, it's all back-end. Once the inventory gets too low and you need to reorder, that automatically needs to be pushed to the supplier's ordering system, might be SAP, might not, could be anything, no way to know.

    And, all different divisions in the company are interested in the ordering data for reporting purposes. They all need to access it and run reports against all different parameters. They want it customized to their location and product line. And they want to be able to personalize what they see, set their own preferences in the interface.

    In order for this to work, we've got to get to data stored in 3 different legacy systems.

    Now, who's your expert here?

    My teams and I have built these systems for Texaco, Halliburton, Chevron, Dynegy, Enron, Schlumberger, and others...many dot.coms no longer with us, but with some nice systems somewhere. If you can do the architecture for the system above, focused on the user interface as your specs, I'd be completely amazed and chastized.

    And by the way, don't accuse me of being a pointy-haired one. Pisses me off.

    Laney
  115. Isn't it a rule of TSS that the discussion is finished when someone mentions dilbert :-)

    Sort of like mentioning hitler in usenet...
  116. Sounds like a good rule to me. :)
  117. How to measure success of a project:
    a) You have users
    b) The software works

    I think that sums it up - point a being the real measure and point b the nice to have :) Read the pen example above which illustrates that nicely.

    How to get to these positions is all about team and talk. With the pictures being a way to aid communication - hopefully, but having little other purpose. The Process aspect is about staffing, resources, measuring and monitoring. The communication aspect is about where people sit, and a mix of personalities and skills.

    Ideally, spec docs exist, are comprehensive and up to date. It rarely happens, because the analysts can't do them.

    The methodology branding of a project is about selling the team and assuring others, a kind of safety blanket for the money men.

    Jonathan
  118. Goal oriented developing[ Go to top ]

    I'd be interested why do you say XP is not enough - or that RUP is too much?
    RUP is a framework - although it's now used pretty much as an euphemism for waterfall, as most organizations decided to formalize their waterfall using RUP. XP can be formally modelled by RUP as well - see dX for a good example.
    XP not being enough - again, XP doesn't sa no documentation - it says you should not do documentation ust because someone says so.
    I would say that any process, however good can be misused. I think someone already said here that a team of good people will find what works for them regardless of what management tells them to use. That's why I like Cockburn's Clear the most - it says "get good team and the rest is easy".

    <q>Do analysis. Do enough of it</q>
    This is hard. Really realy hard. I haven't seen yet a project that would do "just enough" of it. Before it finished, that's it.

    As it stands now, there is not way of formally verifiying that your analysis, UCs and design are correct. You have to rely on people to read them, understand, keep the whole picture in head (due to various exceptions in the business illogic) - and vast majority of people invariably fails somewhere. The more you do in each of these "untestable" phases, the harder it is to verify it, not to mention that the chances of loosing something in the translation from one to another you loose (potentially important) information.
    Doing _real_ formal requirements spec is hard. I mean spec written in a formal non ambiguous language (which immediately rules out English and other "human" languages). There are things like Z etc, but they weren't very successfull. The reasons are pretty much the same why there isn't that much people doing quaternion calculus.
    Also, if you took the pain to write something in formal language, why should you have human developers to translate it to another formal language? Some XP people call this code is the design, I prefer to say that the design is the code.
    And by the way, I do think that there's a lot of people who are starting to treat XP (the "how" of it) as the Silver Bullet. Happens to anything that at least looks like it might have success where others have miserably failed.
    But we can take this whole thing off-line if you want.
    Regards,
    Vlad
  119. Goal oriented developing[ Go to top ]

    "That's why I like Cockburn's Clear the most - it says "get good team and the rest is easy".

    Yes. And this is what I cannot teach or give any sort of methodology for.

    I've worked on many different teams, using many different methodologies. I think the way I should have expressed it is "for any team who tries to follow RUP to the letter, they will be churning out documents forever. For any team that tries to follow XP, unless the people on the team REALLY follow XP, it will not be enough."

    I've worked with XP teams. For it to work, you need to do all of it, not just pick and choose pieces of it, which is too often what I've seen happen, and someone called it XP. Or someone said "oh yeah, we do XP," but it was an excuse not to do any analysis at all, just code. XP still requires analysis.

    For RUP, I've seen teams get so bogged down in class diagrams, component diagrams, state transition diagrams, sequence diagrams, use case diagrams, etc, that they never move forward to code. That doesn't work either.

    In the end, having the right people is what matters. No methodology can overcome that.
  120. Hello Elaine,

    interesting, that the successful steps you describe (as the process Alex described) is 100% what RUP describes.

    No I don't mean you stealed it from RUP. Guess what? RUP is based on the best practices of successful projects.

    Unfortunately if you follow this thread there are not a lot of people that really know the content or should I say spirit of RUP (else they couldn't write some of the statements). I think many of the statements come from some very popular messages, that go around and are more likely been read than the RUP itself. You cannot blame anyone, that doesn't want to read at least over 100s of pages to get an opinion about this process instead of repeating others opinions. It's up to the people that really know RUP to correct these messages.

    It's easy to imagine that some RUP projects really failed and worked ineffective. I think there could be 2 main reasons:
    1. As others stated, the people and their knowledge ist important
    2. The introduction of every new process will slow down the productivity before it enhances it later on.

    regards,

    Andy
  121. I think that if you have a good analyst who knows how to work with users, the business, and development teams, it doesn't matter if you use RUP, XP, Agile, or any other technique. If that team works well together, you will be successful. As I said before, it depends on what my team works best with, it doesn't matter to me. My job is to get them the information they need.

    And if you don't have that, life is going to be hard for everyone.

    Take care,
    Elaine
  122. The process helps your people work effectively.

    A good middle ground between RUP and XP is Feature Driven Development. I've seen results that I didn't think were possible when using FDD along with good people. You'll find a couple of books on Amazon about FDD. You can also find info. about it on Togethersoft's web site.
  123. If you look at the essence of FDD, you only find 2 best practices from past software developmentz knowledge:

    1. Functional decomposition
    2. Design with patterns

    Both can be usefull, but

    - functional decomposition is absolutly the wrong way for modern OO development. It is an old method fron SA / SD times as the waterfall approach and we know today many disadvantages as with the waterfall approach (for example the ignorance of an architecture for reuse)
    - If you look at all disciplines, you need for software development, It's much more than that (I would guess FDD is about 10% of a complete software lifecycle)
    -> How does FDD help me understanding the business?
    -> How does FDD handle changing requirements?
    -> How to work in a team?
    -> How to manage and baseline the artifacts (code, documents, diagrams)?
    -> How to plan and manage the project?
    -> How to assure the quality?

    These and much more questions are left open or are poor covered by FFD (to my best knowledge) and I think this is the main reason why it is very rarely used.

    regards,

    Andy
  124. Andreas,

    Your comments on Feature-Driven Development are way off the mark. Are you sure you're talking about FDD and not some other process?

    I'll correct a few (but not all) of your misunderstandings.

    FDD starts with domain object modeling. You have to break the project down into very small units of customer-valued functionality. That's where you learn about the business. (In FDD you'll break those units down again into feature sets.)

    Changing requirements are handled in FDD the same way they are handled in other methodologies. You write new designs and new code. There is no other way to handle changes in requirments. Where FDD helps alleviate the costs of changing requirements is that you are constantly developing very small units of customer-valued functionality. (A small unit is one that takes less than 2 weeks to design and write code and unit tests for.) When requirements change you may find that you can make use of code that you previously wrote because you have written small working feature sets with functionality the customer understands instead of larger modules that may be only partly working when you get a requirements change.

    FDD also helps avoid changes in requirements by requiring that you learn about the business first by doing domain modeling. This helps reveal problems with requirements early in the project.

    Planning is done by feature set. If you don't know what a feature set is then you don't know what FDD is. (And since you ask how FDD helps you plan the project it sounds like you don't know what FDD is.)

    QA is built into the design and code by feature set process with design and code reviews. (I add unit testing to the design and code requirements.)
  125. The right methodology?[ Go to top ]

    Abongwa Ndumu:

    "I've also been asking questions about which process provides can deliver in the long run. I've been unable to find an answer. If XP and rational are doomed to fail, do you know of a process that will not fail?"

    In order to get some info about this all important matter I recommend you to check "Agile Software Development" by Alistair Cockburn, there you will find some very interesting thoughts and insights about the "why of the how" (what is a methodology? do we need one? why?) and the "how much of it is enough" (factors to measure, the definition of success, etc.) Enlighting reading but not methodology recipes I'm afraid.
  126. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Hello Alex:

    >
    >You said
    >
    >"So the only solution is to focus on the area where such
    >errors creep in. And neither Rational, nor XP, are doing
    >that. Consequently, they won't be able to deliver in the
    >long run."
    >
    >I've also been asking questions about which process
    >provides can deliver in the long run. I've been unable to
    >find an answer. If XP and rational are doomed to fail, do
    >you know of a process that will not fail?

    Yes, I do. The process that is guaranteed not to fail is called goal-oriented design. This is the process almost no business (to my knowledge) employs today, mainly on account of the lack of proper education. Now, before I give you a short description of what it actually is, I need to take a step back and explain a thing or two about software:

    First and foremost, we have to ask ourselves -- why do businesses use software? Certainly not because someone told them it's cool to use software. Basically, the answer to that question is: businesses use software in order to increase productivity. Whether by increasing the inhouse productivity by allowing the employees to use devices/tools to expedite their workload, or by increasing the sales/customer support efforts, the only reason businesses use computing infrastructure and software is to increase productivity/decrease cost and thus increase profitability.

    Knowing this, we are inevitably led to the conclusion that the central theme in designing any software product is the end-user (or, the human user). Human users have unique goals, which come to the surface at the time when users are using software products. The only reasonable thing a software product must do at that point is serve users' goals.

    However, 99% of the software I've seen not only does not support end-users goals, it works directly against them (thus frustrating users to no end). Why is that?

    This phenomenon is due to the overall mentality of software developers/designers, who have been trained to strictly serve the underlying machinery. The computing resources (meaning, memory, CPU, etc.) are much more precious to these people than the human resources.

    What goal-oriented design teaches is that we must invert our focus. We must learn to ignore the requirements of the underlying machinery, and focus 100% on the requirements imposed by the human users. Only then will the software we're creating be able to deliver.

    Alex
  127. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Alex - Lot of excellent points there but as soon as I see 100% I get mighty suspicious. The successful projects I have worked on (i.e. the ones useful to the business and popular with the users) have been succesful because there was a dialogue between the users and those developing. That dialogue worked because the developer representatives (not just analysts but people with a knowledge of available and suitable technology) could both listen properly to the users and explain to them where their initial requirements were difficult or non-performant and come up with an alternative acceptable to all parties. There isn't a methodology for this, it's a matter of talking to other people, understanding what's driving them and entering into a relatively ego-less dialogue. Never found a tool that helps with that.
  128. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Hi Geoff,

    You wrote:

    >Alex - Lot of excellent points there but as soon as I see
    >100% I get mighty suspicious.

    OK, make that 99% focused on the end-user requirements.

    I agree with you that there isn't a good tool for conducting requirements gathering. However, my problem is in this: why should software developers be involved in the process of requirements gathering? Requirements are strictly related to the business, so we should let business people worry about collecting and articulating them. I think that us meddling in the requirements gathering creates all these problems in the first place.

    Once businesses are clear on what is it they are trying to automate, we should step in and deliver. Businesses have no reason to mess with us at that point, as we're the experts, and we know how to deliver. I think we should keep these responsibilities clearly separate, rather than muddying the issue.

    So, the much touted 'dialog' that you also talk about is a moot point, from where I sit. Some may say that the dialog is necessary and unavoidable, because the business people may be confused about what is it they really want. To that I can only reply: if they are confused, no amount of dialog with software people will clarify their position. They must make an effort to clarify their needs on their own. I always tell the business people I'm dealing with: "come and talk to us only when you're ready; don't bother wasting our time with half-baked ideas."

    Alex
  129. Requirements Capture[ Go to top ]

    Alex - Agree mostly with you and Elaine (way ahead of Rolf in my list of people to choose to implement a project) but it's the (in UK terms) Rolls Royce/Audi/Vauxhall issue (sorry don't know US equivalents). The user will say he wants/needs a Rolls Royce, he'll end up being given a Vauxhall whilst sensible discussion would have got him an Audi (which is what one really needs). If you forbid all consideration of technical feasibility until requirements are fully gathered you either get a non-performant system or revisit the requirements. Note I say consideration not discussion - the user gets told 'we could do that but it will be expensive and slow the system down, would something like this be acceptable?' and then work from there to get a compromise that meets functional, cost and performance requirements. As Elaine said all these roles are hard to fill and depend on people not methodologies, tools etc.
  130. Requirements Capture[ Go to top ]

    Hi Geoff,

    You wrote:
    >If you forbid all consideration of technical feasibility >until requirements are fully gathered you either get a non->performant system or revisit the requirements.

    The above is another urban legend, or myth, that I'd like to examine more closely here.

    Like Elaine said in one earlier post, we should be extremely careful not to allow any discussion/consideration of technical nature to enter our analysis/high-level design efforts. I'm with her 100% on that. Introducing technology at such early stages is utterly detrimental to the success of the project/product. Many people seem to have difficulty grasping this.

    In order to try to facilitate the understanding of that principle, I'll repeat the post I've submitted to another thread recently (hope you guys don't mind a little bit of cross posting):

    <quote>
    I've recently developed an end-to-end framework that is centered around XML Schema documents. Users declare their business (including all the constraints and validations) in an XML Schema (i.e. a repository), and then my framework reads the XML Schema document(s) and generates the whole bloody application. Everything, including the business rules layer, the persistence, the presentation, the logging, the validation etc. layers are generated from the XML Schema.

    That exercise forced me to carefuly examine the process of coding, because my framework had to emulate a bunch of real life programmers. Guess what -- I've discovered that the act of programming is a real trivial exercise. Sure, it is way mystyfied, to impress the common folks, but when you get to the bottom of it, it is rather trivial, meaning you can teach a piece of software to do it.

    So now I have this piece of software that replaces an army of highly paid coders. It generates the whole end-to-end application in less than 20 seconds. To produce the equivalent amount of fully working code, real people would probably require weeks, if not months of uninterrupted coding.

    So my question still is: what's so special about the act of coding? Many people have looked at the code produced by my framework, and weren't able to distinguish whether that code was written by humans, or produced by the machine. Thus, I really don't see anything extraordinary in the ability to produce code.

    Now, the ability to design an application is something totally different, something machines will never be able to approximate.

    Alex
    </quote>

    Back to our discussion -- I've reached the conclusion that what really matters in the automation I've described above is the ideas that got expressed inside the XML Schema. Once we have the XML Schema document(s) hammered out (meaning, we have our ideas about what is it we want the system to do clarified), everything else flows naturaly from there. But the tough part is to put the right, meaningful things into the XML Schema. And trust me, it's far from being trivial or easy. It may take months and months to get there.

    The good news is, once you're there, you don't have to worry about the technology too much. The technological solutions are converging nowadays, everything is web-based, distributed. The persistence layer can either be XML-based or RDBMS-base, doesn't really matter (my framework is XML-biased, but it can also cope with RDBMSs). The presentation layer will most typically be HTTP-based, although my framework also generates fully blown Swing (Flash and WML reserved for future development).

    The most important point is that during the analysis/design phases, no thought related to the underlying technology must enter the picture. We discuss things in terms of 'here something happens, you push a button or something, and this thing appears'. We talk in terms of magic, because that helps us eliminate the danger of slipping into the technology trap.

    So, in my view, the technology is irrelevant. It should be automated to the highest possible degree, it should be standardized, it must recede into the background. In other words, in must be made invisible. Nobody out there really cares about the technology. I know this is a very unpopular thing to say to the group of techno-apologists, but that's the way the cookie crumbles, folks.

    Alex
  131. Requirements Capture[ Go to top ]

    You're a brave man, Alex.

    For different reasons, the technical architects I work with don't want technology solutions discussed in the analysis phase. Some I've heard....

    They don't want the developers on their team to go off and code something before they really understand it. They don't want anyone talking technology, period.

    They don't want anyone writing code before they figure out the architecture of the system.

    They want to do high-level analysis, then define iterations.

    My own prohibition - talking technology with the business and users (which is who we do analysis with) is a SCARY proposition. We don't mention it in front of them, ever. We don't want to hear "hey, I can do this in Excel, what's the problem?" It's their role to tell us what they need, it's the developer's role to figure out how to best use the technology to deliver that.

    Elaine
  132. Requirements Capture[ Go to top ]

    According to Martin Fowler in 'The New Methodology', RUP can be either agile or predictive.

    What I as a programmer would like to see is less Word documents/MS projects/index cards/massive collections of UML and more structured XML data for specifications.

    I personally think there is a place for intelligent UI simulators, something to prototype what a client wants to see, yet contains enough metadata to be usefull to the end project.
  133. Requirements Capture[ Go to top ]

    Hi Lyndon

    You said:

    "I personally think there is a place for intelligent UI simulators, something to prototype what a client wants to see, yet contains enough metadata to be usefull to the end project. "

    Check out www.foruse.com and look into the Use Cases for GUI design.

    RUP suggests GUI screens for prototypes of requirements while foruse suggests GUI screens for design phase.
  134. Requirements Capture[ Go to top ]

    Alex,

    Forgive me if I'm skeptical of your claim that you have a software package that develops working applications from end to end. I've heard that too many times before. In 1995 one company had a product they claimed could do that. Their slogan was "Not one more damn line of code again - ever!". I can't remember who or what that company or product was. Needless to say that they didn't succeed. 1995 was the beginning of the development of the small army of highly paid Visual C++ programmers.

    Your software may be able to create an application in certain circumstances, but I doubt it works in general. I'd be especially interested in seeing how robust and intuitive the rich clients that your system produces are.

    If it takes months of writing difficult XML schemas to get your system to do its magic then what good is it? Aren't the XML schemas just another form of implementing designs and code?

    It sounds like all you've accomplished is moving the work of programming to your XML schemas. If you've really made writing software trivial then you'll have succeeded where lots of others have failed before. And you'll be rich beyond your wildest dreams.
  135. Requirements Capture[ Go to top ]

    Forgive me if I'm skeptical of your claim that you have a

    >software package that develops working applications from
    >end to end. I've heard that too many times before. In 1995
    >one company had a product they claimed could do that.
    >Their slogan was "Not one more damn line of code again -
    >ever!". I can't remember who or what that company or
    >product was. Needless to say that they didn't succeed.
    >1995 was the beginning of the development of the small
    >army of highly paid Visual C++ programmers.

    I never made claims to the effect that my product will eliminate the need to write additional lines of code. My approach is a bit more realistic. When I say that my product generates an end-to-end application, I don't mean that it generates a fully complete app. What I mean by the end-to-end application code is that all (or, most) of the aspects of a modern application have been included. Such as, persistence layer (XML or RDBMS), presentation layer (HTTP, Swing), business logic layer (business objects), validation tier, etc.

    Of course, the code my tool produces is generic in nature, and there is always room for improvement. But at least it gives you a solid skeleton which you can use to elaborate/polish your ideas. It may save you up to 60 or even 70 percent of the development time, depending on the problem domain you are trying to address. And, to me, anyone who scoffs at a potential of saving over 50% of the effort may be lacking some plain common sense.

    >Your software may be able to create an application in
    >certain circumstances, but I doubt it works in general.
    >I'd be especially interested in seeing how robust and
    >intuitive the rich clients that your system produces are.

    You are right -- my framework targets your typical business application problem domain. Using my framework, you won't be able to generate a nice video game, that's for sure. Nor would you be able to generate the latest HTML authoring tool.

    As for the clients, in a desktop mode it produces all the standard interface features -- menus, toolbars, tabbed panes, JTables, etc. In the HTML mode it produces standard forms/tables. Nothing to write home about, but at least gives you a nice skeleton to use and throw in some extra 'meat' if you wish. But even as is, it is usable, though a bit stark, I must admit. However, it produces corresponding style sheets, so you could play with those, etc.

    >If it takes months of writing difficult XML schemas to get
    >your system to do its magic then what good is it? Aren't
    >the XML schemas just another form of implementing designs
    >and code?

    No, it doesn't take months to write difficult XML schemas. You can write a very complex XML schema in less than a day (why don't you go and have a look at the XML Schema specifications?) What does take months is the analysis and design of a complex business problem domain. But such analysis/design does not require any tool -- you can use paper and pencil, or something like CRC cards if you wish.

    However, the difficulty of coming up with a realistic analysis and design has nothing to do with XML schema. It's the nature of the beast, and no methodology or technology in the world can change that. It's strictly within the domain of human common sense.

    >It sounds like all you've accomplished is moving the work
    >of programming to your XML schemas. If you've really made
    >writing software trivial then you'll have succeeded where
    >lots of others have failed before. And you'll be rich
    >beyond your wildest dreams.

    It's really funny to even mention that anyone could make writing software trivial. The act of writing software will never be made trivial. It's as impossible as saying that someone finally made running a marathon trivial.

    Writing software is an extremely difficult task. What we are trying to do is eliminate or minimize the more repetitive, mundane task in order to free our time and energy to focus on more difficult/complicated issues.

    Alex
  136. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Alex,

    Where can I learn more about goal-oriented design?
  137. And Alex, when I say task-oriented or goal-oriented analysis, it's the same thing. I always determine the user goals first, then build scenarios to support them. That's where the usability comes in - we design something to help them meet those goals as efficiently and easily as possible.
  138. IBM to acquire Rational for $2.1 Billion[ Go to top ]

    Dean,

    You wrote:
    >Where can I learn more about goal-oriented design?

    Unfortunatelly, you won't be able to find books that talk eplxicitly about that topic. I would suggest you start with related books, such as "Exploring Requirements: Quality Before Design" by Donald C. Gause and Gerald M. Weinberg (here is the link: http://www.amazon.com/exec/obidos/search-handle-form/102-1676850-7504100), or "The Inmates Are Running The Asylum" by Alan Cooper (http://www.amazon.com/exec/obidos/tg/detail/-/0672316498/qid=1039553990/sr=8-8/ref=sr_8_8/102-1676850-7504100?v=glance&s=books&n=507846).

    Other than that, you'd have to get lucky enough to get involved in a hands-on team where some members are experienced in doing the goal-oriented design. That's what happened to me 6 years ago.

    Alex
  139. Borland buys Together. If Microsoft buys Rational, IBM is left in the cold trying to integrate anything into WSAD/Eclipse. They have to buy Rational. It also feeds their consulting arm. All other consulting groups and companies buy from them. Global Services has another lead to a gig. Micrsoft starts pumping money into Visio. What's the next enterprise tool to get snatched up? Microsoft buy's Redhat or BEA? Redhat merges with BEA? Oracle buys Sun?
  140. Microsoft will just fill in their development gaps and buy Mercury Interactive.. They can always extend Visio to play like XDE once they come up with another methodology (MUP instead of RUP) they feel is superior.
  141. The press release announced that the acquisition was primarily driven by the "On-Demand" strategy (see http://www-1.ibm.com/services/ondemand/index_flash.html ).

    I'm not sure that the Rational toolset was that high a factor in the purchase equation - though I understand this to be of greatest interest to readers of this thread.

    As many have written here, its not just about tools, its about people and the ability to use them well. If I were IBM acquisitions strategists thinking about how to staff credible teams to convince companies to outsource their IT systems (isn't that what "on-demand" is about?) then, the acquisition of the Rational services team, which I assume are fairly well versed in modeling and using the toolset, would perhaps make sense. To convince a CIO to outsource, you must be able to describe what it is you are going to do, and how you will take into account customizing or tuning the solution to the customers' needs. I think Rational has a credible capacity in that area. The toolset may be quite incidental in this acquisition move. The tools will help with the strategy, but primarily because they will facilitate the implementation part of the "on-demand" strategy for customer accounts; and of course, pre-sales.

    What's in it for those interested in the Rational toolset? If the business unit meets it's objectives, it'll be able to keep on going, and will now have an improved channel through IBM's sales force and other channels (some of that flows in the other direction as well).
  142. This is a very perceptive analysis. I hadn't thought of that.
  143. ...is for Grady Booch and IBM to do some mutual butt kissing

    http://www-106.ibm.com/developerworks/ibm/library/i-booch/