Excel Services

I also did a presentation on Excel Services recently – that’s going to be a slow uptake, but I think it will be massive by the time O2010 gets rolled out to enterprises (2013?). All the devs were well impressed with the browser side (which I think is a waste of time). I had to show them the source before they would believe it was pure html + javascript. But its still a pale reflection of the Excel client.

From a control/compliance POV, a pitiful client like a browser is probably just the job though. And it does render pivot tables and charts well.

The problem is getting developer buy in, same as VSTO. They are great technologies that can add real business value, but .net devs aren’t interested in Excel, and Excel devs aren’t normally empowered to use these tools.

Excel Services could change that though – as Excel devs can publish their workbooks directly to the server straight away, and as time goes on make a case for getting Visual Studio and VSTO.

Maybe this could be the bridging technology?

cheers

Simon

Advertisements

9 Responses to “Excel Services”

  1. BIGGUS DICKUS Says:

    “but .net devs aren’t interested in Excel”

    I got slapped down by an MS manager for saying that at the ODAC last week in Redmond. Seems there are LOTS of VS devs who are just clammering to include Excel in their solutions (??) How stupid of me to not see that ;-) ……

    Dick

  2. Maarten van Stam Says:

    How stupid of me to not see that? Most likely as stupid as not seeing how many ‘departmental developers’ are out there running businesses by creating ‘smaller’ applications using Excel and VBA. We all know how this group is underestimated by everyone.

  3. Simon Says:

    Dick
    I assume that MS manager spends as much time as you visiting real businesses?
    Or does their ‘real world’ experience start and end with Contoso?
    I can tell you that every presentation I have done to VS devs about Excel has been the worst attended. In this case the numbers were down by 75% on last weeks WCF session.
    And I know its not my magnetic personality because all the VBA sessions I run for business devs are chock-a-block.
    Just cos MS want it, it doesn’t make it true!

  4. BIGGUS DICKUS Says:

    I was also told that being an Office “Developer” means “CODE” only.
    When I mentioned that I believed that Office Development in Access and Excel means first and foremost understanding the capabilities of the applications (like “Best Practices in spreadsheet design and knowledge of database design and relational theory) as well as the business processes being automated must come first before code. I was treated as a batty “old fart” which I am beginning to think is going to be more common going forward.

    I am despairing that a hugely important and productive set of tools in Excel and Access are about to be discarded worldwide simply because those responsible for it now don’t think client-side computing is “cool” and because only old guys like me care anymore. By speaking up I am destroying my reputation in the Office “Community”. I didn’t think it would come to this but I think it has.

    Dick

  5. sam Says:

    Simon…. So How about a post on What is Excel Services ?

    Way back in 95 we have One copy of Excel(Workgroup version) on a Norton Network which we could all share…..Dont tell me after 18 years its now repackaged as Excel Services

  6. Harlan Grove Says:

    With regard to Dick’s comments, cynical me doesn’t think this is unthinking prejudice against client applications so much as it’s unthinking prejudice against the value of business processes knowledge. That is, I suspect the people charged with pushing VS* on the world believe programmers can automate everything, even those things they’d have no clue how to do manually. Why, if X can be done by people too thick to learn how to use VS, how simple it must be for those who know VS.

    With recentralization seems to be coming the renaissance of Mainframethink in the guise of VSthink. I can only hope Microsoft reaps the same benefits in the same proportions that IBM reaped in the early 1990s.

  7. AnonDev Says:

    Excel Dev vs. Web Dev

    I tend to the web dev side, however I work for a company where the decision makers want the Excel dev done.

    Why do they want Excel dev?
    First they switched to an ERP system that does NOT easily allow ODBC access. Second they bought a bunch of already finished reports from a vendor, mostly based in Excel, that takes flat-file exports from the ERP system and turns them into usable Excel workbooks. Third, Excel is what they know, and they don’t want to be bothered switching apps. Fourth, instead of being told a status of the business by an already finished report, they’d rather play with half-raw data in Excel, until they figure out what it is they need and want to make a decision about the business.

    Why does this make me cringe… because in addition to making a nice view of flat-files, these Excel apps have spread… now:
    — we make new reports based on previously made reports… how? VBA macros that open up previously updated reports, and extract data, and combine them into a new Excel workbook.
    — they continue to pay the original vendor to make new apps with Excel, not understanding the tech, nor consulting those who do understand the tech; yet those who understand the tech end up with the task of keeping this mess working, even when some part of it fails every other week.
    — I get to now support these web apps, including making VBA macros that format every sheet “just so” so that when a user who doesn’t know Excel hits print, the thing comes out on paper looking good; and making VBA macros that continue this use of Excel as a DB horror!

    And why don’t I want to develop using Excel?
    — Perhaps because I started Excel dev back in 1995, and I’d like to do something else.
    — Because I still haven’t figured out where Microsoft is taking this with Excel 2007, and I don’t trust them to not trash my accrued knowledge, as they move on to some new tech, thus forcing me to retrain YET AGAIN. (Notice they didn’t replace VBA with VBA.NET back in 2000, but now where is it going?)
    — And because freaking spreadsheets are NOT a replacement for a freaking relational database!
    — Because IF the data needed to make a business decision is known, there’s no reason it can’t be pulled out of a real database faster, easier, and put into a nice looking web-based view for looking at, or a paper-formatted view for printing.

    And why web, why not client-side…
    — because every OS comes with a browser.
    — because without MS office, the business can save money every 3 years. (Or do you think it is “normal” to spend thousands of dollars upgrading MS office every 3 years, to get nothing appreciably from that spent money to make the business more productive?)
    — because then IT doesn’t have to support that client-side program.

    Is there a place for Excel and spreadsheets?
    Yes there is, of course.
    But there’s also a place for relational databases, web servers, web-based data-views, and print-formatted reports.

  8. Michel Berg Says:

    Very nice, I sure will be coming back more often. I bookmarked your site also, thank you. This is my loved sites : erp

  9. Dick Says:

    Hey, Michel Berg just comment-spammed my site too. Nice work Michel. You’re really making a name for yourself.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s


%d bloggers like this: