One of the oft quoted barriers to .net and Excel take up is the deployment hassles with the .net components. I have concerns in this area too (and have voiced them), but I wonder how obstructive they really are.
Every client I have worked with recently has at least .net 2.0 on their corporate desktops. Whilst no one seems keen to deploy more than necessary to their desktop estate, I can imagine getting say the VSTO runtimes deployed could be do-able. Everywhere I have worked uses rich powerful tools to manage their desktops, either SMS, or Altiris or similar.
Another common discovery is enterprise data sources replicated in tatty spreadsheets because the users did not know about, or could not access, or did not trust the enterprise solution.
These factors make me wonder if the challenge of .net/Excel solutions deployment is either all in the mind, or a cultural/business politics issue? I certainly don’t think there are significant technical barriers.
So if we want to boost uptake then we need to be addressing cultural/social type issues. Microsoft can’t do this alone, or maybe not even at all. They can address the technicalities, and I think they are with VSTO for example
Here are some of the obvious issues
- business users rarely have official access to .net dev tools.
- business users do not want to be tied to IT deployment requirements (time scales, quality, access, testing)
What we need are some compelling applications or systems that demonstrate how and why .net is so much better than what everyone is currently doing. Now I haven’t gone too far out of my way to look under absolutely every stone, but I haven’t come across anything in .net that made me think: wow that is so much better than anything we have now.
I have seen that with C. Fast UDFs is a compelling feature IMO. If .net could write UDFs that are as performant as the C API, but easier to learn, and safer to write, and supported on Excel services and realistic for business developers to deploy, and maybe worked with the numpty UI. Then I think .net might gain some traction with Excel devs. It would need to work (seamlessly) with more than the latest version of Excel.
.net apparently has some great UI stuff, but Excel is not Photoshop, or Powerpoint. I’m not sure glitzy UI is as important to many Excel users as the Office team seem to think. Although I’m not claiming any authority in this area – I’m not big on UI.
I have done a few data access apps in C# and it works very well. One was a command line app – C# is much better than VB6 for that, and much easier than C/C++.
Are you seeing more opportunities in .net?
Are business users starting to show more interest, or am I spending too much time in IT departments?
cheers
Simon
Smurf on Spreadsheets 
Wednesday, 7th January, 2009 at 12:44 am |
You work in a very different sphere to me Simon. I am generally employed by the business, and the only time I get to see IT (if there is one) is early on where in essence they try and lay down the law, tell me the rules, how I need to keep them informed, ettc., then I never see or hear from them again.
My customers, if they are aware and understand it, are scared .Net, as they worry that IT will seize this as an opportunity to impose control on them. The only real exceptions to this was the major finance houses, those guys know that IT is a cost centre whereas they are a profit centre so they don’t get bullied easily. Of course, things may have changed in the past few months, it will be interesting to see in my next such assignment.
Wednesday, 7th January, 2009 at 9:18 am |
you have certainly identified one of the biggest challenges that IT faces if it is to survive. IT (thinks it) controls the toolbox, and lives in a project management world where getting it absolutely right is seen more important than delivering something. It is not alone in this but it has to solve the “back of a fag packet” conundrum that sucessful ventures depend on. In other words it has to learn how to live with and manage RISK.
Wednesday, 7th January, 2009 at 10:22 am |
VSTO has one major advantage; since it provides extensions to some Excel Interop objects (charts, listobject and NamedRange) we get the options to add and use datasource directly to these objects.
In my experience VSTO is demand driven by clients while .NET solutions like managed COM add-ins can be both driven by the clients or me. VSTO solutions can be targeting both the Office suite and SharePoint it attracts IT-departments.
.NET platform requires a uniformed desktop environment which is best supported by centralized and dictating IT-departments. In my experience IT-departments are “Server” driven.
The line-of-business is usually not aware of VSTO unless they have some individuals who tries to follow the “state of the art”.
Kind regards,
Dennis
Thursday, 8th January, 2009 at 2:03 pm |
Hi Simon,
My experiences are probably closer to Bob’s. I’ve work within the business in banking with Risk Managers and analysts.
The business’ perception of .Net often includes visions of the IT Dept taking control (or at least being dependent for software installations).
MSO development is perceived as providing the business with complete control over the development process with many business staff dabbling in VBA code themselves (let’s leave the soundness of this practice for another blog).
The other is time. The perception is that with .Net development comes a full SLDC slowing down the entire delivery process, as compared to the current RAD development process. RAD, as we all know is an acronym for ‘By The Seat of Your Pants’.
I’ve been in a couple of projects where .Net was proposed. Each was rejected based primarily on budget or time constraints.
Cheers – Marcus
Thursday, 8th January, 2009 at 6:56 pm |
Marcus,
Do You mean that .NET development requires more resources (money and time) then what VBA does? In my experience the first roll out of a .NET solutions will be a challenge but after that any .NET based project should not extend the resource requirements compared with VBA.
RAD is also doable on the .NET platform.
Kind regards,
Dennis
Thursday, 8th January, 2009 at 9:50 pm |
It is not a question of whether a .Net solution is faster than a VBA solution per se, it is a question of control. Business feel that they can do VBA quickly, whereas .Net would need to be centrall delivered. Rightly or wrongly, centrally delivered is seen as slow.
Friday, 9th January, 2009 at 8:38 am |
Hi Dennis,
I was referring to the way .Net is perceived by the business (not the reality).
One manager related .Net to Java; recalling a recent Java based project which ‘took months’. He lamented that the solution could have been built within a week with Excel, Access and VBA.
As Bob alluded, central – IT Dept controlled – deployment has a poor reputation in regards to expediency. It’s the business’ sense or perception of control and speed which affects their decisions, reality aside.
Regards – Marcus
Friday, 9th January, 2009 at 10:06 am |
OK, thanks for the clarifying. Since I work with the IT-departments for all the .NET solutions I ship I don’t get in contact with the businesses themselves.
Given these circumstances Simon’s comment makes sense that is no longer a question of technically issues rather internally culture barriers.
Kind regards,
Dennis
Friday, 9th January, 2009 at 1:27 pm |
Not just cultural barriers Dennis, don’t underestimate corporate politics and departmental agendas (are they one and the ame thing?). Even if the business was fully aware of central IT’s need to have structure and control because they have to implement cross-system, cross-department, etc., etc,; even if the business were aware of regulatory controls imposed upon central IT; even if the central IT were aware of the pressures on business to cut cost and increase income; even with all of that cultural understanding they would still not trust each other, would think that the other is not acting in their best interest, and would thinsk that the other is a bunch of cowboys (hell, I have spent most of my working life in central It, and I didn’t trust our support teams).
The only way it can work is by having an IT guy on the board, a finance guy, business reps, and a board that actually works well together in the interests of the company. And the board would be dictatorial to some respects, they would agree policy and push it down the line trough contracts, and each manager would be responsible for ensuring policy adherence. But I have yet to see a board capable of working that way, egos and politics get in the way.
Friday, 9th January, 2009 at 3:25 pm |
Bob, how did You manage to survive in an organisation like that?
When it comes politic etc I try to stay away from it as a much as possible. In some cases I have walked away from projects because of these aspects.
Kind regards,
Dennis
Friday, 9th January, 2009 at 3:37 pm |
Unfortunately Dennis, in my role and my level I just couldn’t avoid it.
The first years were great, I was younger, I enjoyed the buzz, and I worked in a part of the organisation that was ruthless but was very business focussed.
In my last few years, we were reorganising at least every year, and every reorganisation meant a new head honcho at some level, so one would have to manouevre oneself to be in the right place when the selection came, and even then because you might not know the new guy, you might have been snookered. It got to the point where I couldn’t handle this anymore, so I left.
Friday, 9th January, 2009 at 6:42 pm |
>>It got to the point where I couldn’t handle this anymore, so I left.
I believe more individuals would like to do it but the “safe” monthly salary and loans etc may keep them away from doing it. I did it when I was young and single but that does not imply that being a consultant is so much better… After all, our monthly bills need also to be paid.
The constantly reorganising must be exhausting for everyone who are involved. In the past corporates never changed their organizations or very rarely but still made some money.
Kind regards,
Dennis
Wednesday, 14th January, 2009 at 5:03 pm |
You might like to try ExcelDna (http://groups.google.com/group/exceldna) as a way of easily creating high-performance UDFs in .NET.
In recent versions I have made the loading of ExcelDna-based add-ins more robust, so that the user gets nice messages if .NET is not installed. But otherwise I have had no complains that .NET distribution is an issue.
My aim with ExcelDna is certainly to deliver on most of what you ask: “…UDFs that are as performant as the C API, but easier to learn, and safer to write, and supported on Excel services and realistic for business developers to deploy […] It would need to work (seamlessly) with more than the latest version of Excel.”
Give it a try ….
Thursday, 15th January, 2009 at 1:24 am |
You are right Govert I really should, and that day is getting nearer. I have a target client in mind so I have a bit more motivation. Mike is always signing the praises of ExcelDNA. It’s just stacked up behind some other things for me to look at.