Really funny you bring that up. There's a webcast I was listening
to this very morning about OBAs (Office Business Applications).
How about that. We Web application developers site browser ubiquity as a business case for our applications. Well, some folks apply the same logic to the ubiquity of Outlook and Excel. What goes around comes around.
I noted a couple incongruities in their rationale though. One one hand they embrace the business objects model in Office, but on the other hand they site the perils of embedding a lot of business logic on the client, indicating that they've been down that road ... but never again.
I was kind of thinking about linking inbound and outbound email to CRM records by having procedures that looked at To: and From: headers in messages. If messages are from / to a known client, then add a reference to a CRM table. But where should that logic be applied? On the server, or the client? My tendency would be to apply that logic on the server - not employ the Office business object model.
They also got into online/off-line considerations. Folks want to be able to work off-line. My initial reaction is that if you're on an airplane, loosen the tie, lean the seat back, enjoy the movie, read a book, talk to your seat mate. Enjoy your time away from the office.
But they propose bringing up an order and flagging it for approval, and synchronizing that with the database ... later.
I suppose that sounds appealing at a certain level, but I'm personally leery of off-line transactions. The customer may have exhausted their line of credit in the mean time. And you're relying on email for posting transactions. Is that safe? Personally, I've seen too many cases where email was never delivered.
Nathan.
midrange.com
