Office v browser

Interesting article here:

I’ll be interested to see the results when published.

I think it may be a bit too broad brush, with lumping word processing, spreadsheet and presentation together, but we’ll see.

As a comment I put ‘Excel is the centre of my world by an order of magnitude’.

I’m guessing most of us here are similar?



13 Responses to “Office v browser”

  1. MikeC Says:

    Interesting reading, and very true about the constant predictions that “Facility X is about to make Applications A, B & C obsolete” – I’ve lost count of the number of articles I’ve seen about this, often without any evidence to support, and often followed by the disappearance of Facility X.
    Much in agreement with you Simon, though I can see the sense, at a high level, of putting the MSO apps together. Although I use Excel & SQL Server extensively (almost exclusively), throughout this company Word is used much more, and PowerPoint is probably used more times across the company in a month than Excel is in six.

    My own comment was: “Without MS Office, our entire organisation would fall to pieces in less than an hour”, which is probably a fairly generous estimate considering the nature of our business.

  2. Stephane Rodriguez Says:

    Where I have worked (before I became an independent vendor), BI tools were replacing MS Office at a fast pace. Especially centralized BI tools, plus a couple power users tools for most demanding users. MS Excel is heading there too. Just that it won’t do it alone, it needs the help of the rest of the Microsoft product arsenal (sharepoint, application server, clustering, database backend, alert services, …).

    Ironically enough, I have tested the latest revision of Google spreadsheets (charts, named cells, …) yesterday and it’s really good. Don’t see much applications on top of their API so far though.

  3. Harlan Grove Says:

    As for the Microsoft product arsenal, I work for a company that uses Lotus Notes as their e-mail/groupware backbone. No Sharepoint or Exchange servers at all, and no plans for them. Such spreadsheet-like services that already exist are provided by middleware that formats calculated output either as HTML tables or Excel workbooks. Server-end calculations are either coded directly, purchased 3rd party applications (very specialized, e.g., earthquake and hurricane simulations), or canned S-Plus scripts. Other than as an output/export file format, Excel isn’t used on the company Intranet.

    However, there are many specialized pricing/costing/planning applications in Excel. While Excel has been a very rapid development platform for these applications, its biggest advantage is rapid (crude!!) UI development. To be honest, the calculations would be more reliable (well, maintainable) rewritten in S-Plus or similar array-based programming language, but the programming needed to provide a UI isn’t fun and requires greater care than most non-full-time, in-house Excel ‘developers’ are used to giving.

    All things considered, spreadsheets are the most flexible development tools I’ve used, but that flexibility comes at the cost of higher maintenance. Huge workbooks with promiscuously mixed user input, relatively static data and formulas are all too common, and a real PITA to fix. Still, they’re useful. My rule-of-thumb is that large models (>10MB) using mostly in-house data shouldn’t be spreadsheet-based, but small (

  4. Stephane Rodriguez Says:

    Harlan Grove “that flexibility comes at the cost of higher maintenance.”

    That’s why you have BI tools, part of it is introspection tools that on the one hand abstract stuff away (eg business object layer), and the equivalent of reverse lookup tools making it (much) easier to fix “the mess”. Add data quality tools (ETL). Add to this the inherent structure provided by regular reporting tools, as compared to the free-form Excel spreadsheet, it does not take much more to infer that, yes, Excel is amazing for RAD, but horrible for maintenance.

  5. Harlan Grove Says:

    BI is only useful for in-house data fetched electronically from in-house data sources in predefined formats/layouts. BI is useless for customer-provided data received in whatever file format and data layouts the customer feels like providing. The market is HIGHLY competitive, so there’s NO leverage to push back for plainer or more standard data format/layout.

    Dedicated ETL tools just don’t cut it, and the average end user won’t be able to figure them out anyway even if the company were daft enough to pay for licenses for all end users.

    BI, BO, ETL, etc only make sense in relatively centralized data processing departments. They’re useless for near point of sale applications.

  6. Marcus Says:

    Hi Guys,

    I left a similar comment about bundling the MSO apps citing banks vs. legal firms as an example of the importance of Excel or Word respectively.

    Like Stephane, I’ve also seen a growth in BI tools but to complement MSO apps not replace them. The number one question users ask after a BI implementation (such as Business Objects) is: “Can I export this to Excel?” At one bank I’m currently working with, one of the managers bluntly stated that they couldn’t function without Excel and Access.

    As I’ve mentioned in a previous post, one of the big hurdles in browser based apps is not functionality but data security and ownership. Most banks (and I’d imagine Law/Patent firms) are paranoid about document security. While the browser based apps may attract other markets (small business, students), we’re a long way from SoX, Basel and domestic regulators giving their blessing to financial institutions and other corporates using this app model.

    Cheers – Marcus

  7. Stephane Rodriguez Says:

    Marcus said “BI implementation (such as Business Objects) is: “Can I export this to Excel?” At one bank I’m currently working with, one of the managers bluntly stated that they couldn’t function without Excel and Access.”

    All major BI suites support native Excel export. But it is important to understand that most of these don’t create Excel formulas when exporting because there is a disconnect between the report as it is displayed, and the actual underlying aggregates/calculations : the opposite would imply a strict identical semantic definition of functions between the reporting tool and Excel. Which in other words means you can still do static analysis with an exported report as Excel, such as drill down, but not a dynamic analysis. Of course, when your data is in Excel, you can do all what Excel allows to do with data.

    A scenario I have never seen realized is create a report using a conventional BI tool (such as Crystal reports), export it as Excel, add Excel formulas and other changes, then save it back to the BI tool.

  8. Dennis Wallentin Says:

    Perhaps a stupid question but why can’t Office vs Google, Excel vs BI Tools, VBA vs /VSTO/VSTA just co-exist?

    After all, different information needs require different tools.

    Kind regards,

  9. Stephane Rodriguez Says:

    The answer to the question is that they coexist since they target different audiences. But the trend I see is tool standardization across the organization, and that has been particularly the space with the adoption of BI.

  10. Marcus Says:

    Hi Stephane,

    “Can I export this to Excel?”
    I was alluding to the observation that many BI users appear to be stuck in a paradigm rut. Through their BI tools they have a lot of power at their disposal, yet most want to be able to export to Excel to ‘play’ with the data themselves. That may entail adding formulas, graphs or simply making the report ‘prettier’ for a PowerPoint presentation.

    Write back Functionality
    I believe (but don’t quote me) that Hyperion Essbase’s Excel Add-In had write-back functionality. You could extract data directly into Excel, make changes (including formulas) and load them back into the database.

    Cheers – Marcus

  11. sam Says:

    “Can I export this to Excel?”

    This is a critical feature requested for in any kind of data handling application ….

    And the reson is people are not happy with the “format” of the output thrown out by these applications … or the ouput from these reports does not have a column which the user would like included in the report….
    or the graph thrown out by the application is different from what the user wants….

    Hence every one wants the raw data back in to Excel…. to “play with”

    So the other application ends up just storing data….

    Input data is in Excel – and is exported in to the database…Data from database in imported back in to Excel….

    The end result …. you have an expensive software which just stores data and does littel else….

    If only Excel had capacitiy to handle large data….


  12. Simon Says:

    10 years ago most BI types had their own proprietory (?) reporting tools, and they all promised to save us from spreadsheet hell. And customers stayed away in droves. And rightly so they were pathetic, often making the old mainframe reporting tools look refined by comparison.

    Users continued to download tons of data to Excel, do their analysis and create their reports. As Sam says, generating little value from their new tools.

    5 years ago BI vendors finally caught on and produced decent Excel add-ins, so they didn’t have to second guess how we use our data. Now the uptake is improving.

    I’ve worked on web projects and sat with devs who have 5 kloc of javascript just to do a bit of sorting and filtering (Ajax/web 2.0 long before the current hype).
    Any Excel/VBA dev could do the same functionality, better in less than 50 lines of code in Excel/VBA, which all the users had anyway. Personally I think the browser is a rubbish interface for nearly all the stuff I do. (but that could just be me!)

    Dennis yes they can and do co-exist, but its always nice to feel you are backing a winner when investing time and effort.

    Marcus yes Essbase has ‘lock and send’ write back, and AS has something similar, great for forecasting applications. Of course this all has proper security too, most orgs disable write back for reporting apps.


  13. Harlan Grove Says:

    Re forecasting applications: where’s the ARIMA and/or regression components of AS? Or do you mean ‘forecasting’ in the sense of budget forecasting, i.e., thin, ad hoc quantitative fig leaves over SWAGs?

    Disclosure: I’ve never worked for a company that didn’t have SAS on their mainframes and at least one other stats program on smaller hardware. BI may be more useful than pure RDBMS facilities, but from what I’ve seen, BI doesn’t include robust statistical forecasting.

    What am I missing?

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: