WCF Data Services - Pros/Cons, your experiences or 2c

I have a new gig at a place that would like to move away from their usual Excel-VBA + Sql Server solutions to .net. I think the only reason they want to start using .net is because they think it's more professional than VBA.

It's a small 25 person finance company, their apps/requirements are mostly data-centric and there's a good mixture of different technologies in use (perl, Mathematica, lots of Excel, a large .net/Sql Server third party app). There's no internal .net apps in production at the moment so I'm free to run with Visual Studio 2010 & .net 4.

I was thinking of suggesting they use WCF Data Services (WCF-DS) as a sort of exposed middle tier. We can hook up .net front-ends easily. It looks like Mathematica can consume the JSON delivered by WCF-DS fairly easily. So funnily enough most of the client work will be writing a component to pull the data into Excel (they use 2007 so PowerPivot isn't an option). With WCF-DS in place I would be hoping to get some re-use and data availability whilst avoiding closely coupled client & server objects and locking all this information into specific spreadsheets.
So.. would welcome people's thoughts, suggestions, 2c, etc.

[Since I'm writing this at 11pm uk time & in the US the Superbowl is just starting, I won't hold my breath waiting for replies ]

In my experience, WCF (and probably all SOA implementations) suffer from one really annoying issue:  If the service hasn't been used in a while, there is a 'startup' lag that can cause havok in multiple ways.

Unless you have a reason to go SOA, I wouldn't.

@ScanIAm: Yeah perf and time to ship code changes were my concerns. My proof of concept was going to set up a Data Service against a current DB system they have and (hopefully) demonstrate that it's not noticeably slower than the current VBA firing SQL into the DB solution they have in place.

I guess I could rely on scheduling a keep-alive/wake-up-10mins-before-the-users-get-in call to the Data Service.

They do have big plans to start sharing data around the organisation and I have a feeling all this point-to-point sql is going to get messy after a couple of years.

@ScanIAm:There also is a really big maintenance overhead, WCF applications take a lot of coding, introducing small changes takes a long time.

@vesuvius: Yup, this is why I was tempted by something like Data Services over writing our own WCF services from scratch & utilising binary transport protocols where possible. Their current Excel/SQL Server sheets can be amended/fixed/upgraded very very quickly.

wcf data services (i.e. astoria) is great. It is a nice way to expose your data and service methods.  There are some limitations in how you can query.  For example, you can't do a select many (e.g. for-for). So it not like have a full query connection.  But normally you can work around those cases by creative query or going other way in the relation.  With built-in support from clients like Excel (et all) and LinqPad, it is a good thing.  Using LinqPad for dev and test is a real time saver and just a good ad-hoc tool.   You can also self host the .srv (if you need tight control or startup or shared state) in addition to using IIS hosting and can use plain old CLR objects in additon to DB, so there is a lot options that get surfaced in uniform way.  Facebook insights uses it. http://www.odata.org/producers