News Stay informed about the latest enterprise technology news and product updates.

IBM takes (yet another) swing at Office

Time warp anyone?

When news outlets reported this week that IBM/Lotus unveiled Symphony an Office-y application set, long time software resellers must have thought they’d entered the way-back machine.

Lotus fielded its original Symphony more than twenty years ago. On board was a young tech whiz kid named Ray Ozzie. You may have heard of him. Symphony was to be the follow on to Lotus’ blockbuster 1-2-3. No such luck.

The current Symphony is yet another attempt by IBM to loosen Microsoft’s grip on the desktop productivity market. This time it’s a freebie ODF-compliant suite. Buzzword check: Open source? Check. Cross-platform? Check. Anti-Microsoft? Check. It’s a go!

But before we get our knickers in a twist, let’s recap how many times IBM, and before that Lotus, tried to do this.

There was the portal play, when IBM started delivering a simple text editor, basic spreadsheet—you see where I’m going here—with its WebSphere portal. The sales pitch there was that for many companies these applets had plenty of functionality for most users and would obviate the need for expensive Microsoft Office upgrades

The pitch would have gone something like this:

IBM to customer: “For 80 percent of 80 percent of your users’ needs these applets are enough. The rest can stay on their old MS Office and you can use all that upgrade money to buy IBM portals!! We’ll save you money because everyone needs a portal anyway.”

Customer to IBM: “No thanks.”.

Earlier, Lotus Development (pre-IBM) tried to counter Office with SmartSuite, surrounding 1-2-3 with Ami Pro, Freelance—a much better app than PowerPoint, btw—and the nifty Approach database. It went over like a lead balloon, except in some big IBM shops. And maybe IBM itself. For awhile.

Then there was eSuite, a set of Java-based component applications. Result: DOA.

IBM must hope this time around that its OpenOffice clone will dislodge some Microsoft Office holders at a time where Microsoft is under fire big time from European antitrust officials. Face it, for all of Microsoft Office’s dominance, many of its users frankly don’t like it very much. Many resent Microsoft pressure to upgrade for new features they will never use and do not want. One solution provider specializing in small business accounts say many are irate that they are no longer able to buy Office 2003 for users in workgroups wehre it has become the standard. They resent pressure to upgrade all their users–regardless of need–to Office 2007.

So maybe, maybe, this time IBM will get some traction although it is unclear to me why this offering would one up OpenOffice or StarOffice which are, face it, widely available already.

So, will — what is it–the third, fourth, fifth time a charm for IBM? We’ll see.

Barbara Darrow, a Boston-area journalist, can be reached at

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I have read the introduction but NOT the whole article. My response is based on the definition of requirement as per ISO 9000:2005 (which I understand is confirmed in 2008).

3.1.2 Requirement: Need or expectation that is stated, generally implied or obligatory

The requirements may be simple or complex and they are determined by the Customer / User including regulatory authorities. So, If FDI gives long and extensive requirements they have to be met by any process / methodology. In fact being long and elaborate obviates the need for too many iterations of validation. The team may take time to understand long requirements but that is up to them.

My company has been an Agile shop for the past 3 years and are exclusively in the FDA regulated space. We have been audited regularly and you can easily be agile and meet the FDA requirements. You do have to have more process in place, but the key is to do "just enough" process to realize the quality that the FDA is looking for. You need system level requirements, traceability, etc that may not be necessary for non-regulated development. The key is to work with the FDA or other regulatory body and come up with a joint interpretation so that the intent of the regulation is met.
My team is not subject to FDA, but we are subject to CMS (Center for Medicaid & Medicare Services) regulations and audits. I imagine it's similar to being under the thumb of any other government agency - they think up new rules, and we have no choice but to implement them in our systems, often with short notice. Sometimes, it seems as though we are more of a support team, as we have a constant stream of small changes that are the result of CMS changing existing rules or creating new ones. We rarely have the time to take on large projects. 

I'm not sure if that makes us better or worse suited to agile, but we do call ourselves an agile team. We take a continuous flow type of approach and although we have iterations, we do not commit to getting specific work done during iterations, and we don't "protect" our iterations, because we are constantly interrupted with new requirements that we must implement. It does get frustrating at times, but we just take the changes as they come and do our best to respond to them quickly. I guess that's really what being agile is all about.
Being agile doesn't mean you don't have process, and it also doesn't mean that you have to give it up to do regulated work.  There's a balance between them.  Although, finding that balance,  may be tricky.