Posted on 06/22/2002 12:48:53 PM PDT by Dominic Harr
Microsoft .Net software's hidden cost
Sat Jun 22,11:11 AM ET
Joe Wilcox
Companies planning on moving their old programs to Microsoft's new .Net software plan had better prepare for sticker shock: Making the conversion could cost roughly half of the original development cost, Gartner says.
More Newsletters (CNet/ZDNet Privacy Policy)
|
|||||||||||||||||||||||||
That may come as a blow to penny-pinching information systems departments in big companies, even those very familiar with Windows programming.
Typically, moving to a new software release isn't so costly. But, warns Gartner's Mark Driver, .Net isn't just a new release of Windows.
"People mistakenly assume the cost of upgrading will somehow be the same as going from one version of a well-established product to another. That's definitely not the case (with .Net)," said Driver, who devised the cost model.
Ari Bixhorn, Microsoft's product manager for Visual Basic.Net, disputed Gartner's conclusions. He said most conversions to .Net are about 95 percent error-free, meaning they can be completed at a cost much lower than what Gartner estimates.
Gartner, however, considered factors other than code conversions in its analysis, such as training and lost productivity. Bixhorn said he didn't see either training or productivity problems as much of a concern.
Microsoft's .Net plan includes new releases of the company's Windows operating system and other server software, along with development tools and infrastructure to make programs more Internet-aware. One new technology supported by .Net is Web services, which promise to make linking internal computer systems, and systems residing in multiple companies, far easier than current methods.
What's unclear is whether the additional cost of moving to .Net will slow Web services releases. Several technology buyers told News.com this week that they are waiting for additional standards and better compatibility before they commit to large-scale projects.
The most prominent piece of .Net released so far is Visual Studio.Net, a new version of Microsoft's development tool package, which debuted in February.
Visual Studio.Net includes new versions of familiar tools such as Visual Basic and Visual C++. But the tool bundle is radically different than predecessors. It includes a new development language called Visual C# (pronounced "see sharp"), and introduces the .Net Framework and Common Language Runtime, which are technologies for managing and running programs.
The new development tool package also ushers in ASP.Net, a specialized type of software called a class library, replacing an older technology called Active Server Pages (ASP) for creating Web applications that support new Web services technology.
Still, long term, Driver predicted that making the switch to .Net for building new programs would help lift productivity and create more efficiency within companies.
"Over the course of the lifetime of an application, .Net might give you 20 percent cost advantage or more over using the older technologies," he said. "You will be able to recover that migration cost over the course of three to five years."
Companies making the switch could do so all at once, but most will likely make the change over a longer period of time. Either way, the cost of migration stays the same.
"It's an issue of paying the 60 percent up front or over the course of three years," Driver said.
The largest cost is code conversion. Because it is difficult to calculate, the 60 percent estimate in some cases could be too low.
The cutting edge can hurt
Gartner based its migration cost estimates on Visual Basic.Net and not on its cutting-edge, Java-like Visual C# programming language. One reason: Cost. A forthcoming study will say the migration cost associated with C# would be even higher than the standard Visual Studio .Net tools, Driver said.
"Some clients have asked about going directly to C#," Driver said. "For the vast majority, going from Visual Basic to Visual Basic.Net may be painful, but it's going to be the least painful of the strategies."
C# is seen as a crucial programming language for advancing .Net. Use of the language doubled in six months, according to a March study by Evans Data.
Without a doubt, companies switching to the new tools and migrating software applications over the long haul will find the switch over the easiest, but even they face difficulties in planning. Driver used the example of a developer running the older version of Visual Studio and Visual Studio .Net over a protracted period.
"That becomes untenable at some point," he said. "You've got to make the switch. So even if you go with a hybrid model, you've got to remember that you're spreading your resources thin over two different platforms."
There are other concerns about making the switch to .Net. At the top of the list is security, Driver said. Following a January memo from Chairman Bill Gates ( news - web sites), Microsoft cranked up emphasis on security. But problems have still surfaced in recent months.
"Some people are hesitant to put Internet Information Server (behind a public Web site) because of security issues. Well, .Net doesn't really address those problems," Driver said. "IIS is still just as vulnerable with .Net running behind it as the older ASP (Active Server Pages) code running behind it."
IBM and Sun also are pushing hard into Web services, advancing their own technology strategies and tools.
Security will be an important part of that emerging market. Market researcher ZapLink said on Thursday that the Extensible Markup Language ( XML) and Web Services security market would top $4.4 billion in 2006.
In my experience, trying to pay a vendor like MS instead of paying for training and in-house expertise will burn you every time.
As I said, in my experience there are better, cheaper solutions available that will involve less risk and fewer unknown product defects (which are *ceratinly* in .NET right now). MS has burned you already. Ya'll don't know it, because you don't know the alternatives.
IIS isn't "free", nor is SQLServer. I wouldn't use stored procedures for data input, I would seperate that logic out into code (it will run faster, and won't be a 'single-db' lockin).
I'm always amazed that MS's sales pitch of "use our solutions, you don't even have to be an expert to use them!"
Yes, you do. Or else you pay for it in the end, every time. If you're paying MS instead of developing your own tech expertise in-house, you will get burned. You'll pay more, and end up beholden to that single vendor. You have to use IIS (which is *very* inferior). And SQLServer, which is adequate but far over-priced (even compared to Oracle, because Oracle is a better far, far better DB as far as scalability is concerned).
Don't get me wrong. Java is not for everything. It is slightly slower to execute, so if you've got a flight-sim or something that has to number-crunch a million policies overnight, then use either C++ or Cobol on a mainframe.
But for web work, it is absolutely the very best, cheapest, fastest technology going. You are paying more for the MS solutions, and you're getting an inferior product. If you're "MS-Only", you might consider doing an analysis of non-MS techs and see if you really want to stick with the single vendor lockin.
Just a suggestion.
I was being generous, in fact.
If the ASP code just has a web form that takes parms and then kicks off an SP, then spits out links to the screen, it likely would have taken me less than a day to do.
Assuming he wasn't too experienced with Java, I allowed a week.
That's pretty basic functionality.
I've written a similar reporting system here at CSC, for our HR dept and 'Program Office'.
I have to pull data from the 'MARS', 'RequisitionRequest', 'PIC' and 'Status' dbs in Lotus Domino, the Oracle db that accounting uses and the 'Hawk' SQLServer db to build reports.
The front-end is an applet, so it can do full data validation. The middle-tier is a servlet (we call it 'SQLServlet') that takes SQL calls and routes them to the correct DB, then builds the report data before returning the data to the applet -- which then formats and allows them to print the data.
.NET can *not* do that.
If he isn't very familiar with Java, then his estimate at how long it would take in Java is suspect.
I have a lot of recent experience building *exactly* that type of tool, and I would think that *my* estimate might be a little more accurate.
But who knows? I could be wrong. I'm just giving you my best guess. You disagree with pretty much anything I say anyway, so I imagine that this discussion is moot?
Please. There is no way that database statements embedded in code (which make programs harder to maintain, BTW - since you have to touch your code every time there is a database change) will run faster than compiled stored procedures.
But that's all beside the point. You just have a grudge against Microsoft, and I'm not going to help you indulge it any more this morning.
Ciao...
He completely described the app.
Ah, well. You disagree with me. I can live with that.
I once thought so too. But test it side by side.
And now that I've looked into it, it makes perfect sense.
A DB is not optimized for number-crunching. It's only optiimized for data storage and retrieval.
As you know, there are a hundred ways you can code the number-crunching part of report building. You often have to try it a half-dozen different ways to get the best performance. The DB will not do this.
Having the DB "build" a report is going to be slower than having a programming language build the report. The SP will have to build temporary tables, and the like, and that stuff is *slooooow*.
Try it. Try just doing simple SQL calls and bringing back the raw data as much as possible, and then building the report yourself. If you're MS-only, try C#.
And you do *not* have to touch the code when the db changes -- unless they change the names of fields, which would also disable the SPs.
In fact, you have a much *easier* time both writing and maintaining the code if it's in a language other than SQL.
Programming a complex report in SQL is a nightmare, compared to Java or C#.
And then there's the portability thing -- with SPs you're going to have a major problem migrating to other DBs. And with your architecture, if you have to add into that report some data that comes from another DB you're dead in the water, and need an entire re-write. That architecture will not scale.
I'm sorry you're closing your mind to non-MS solutions. I suppose if you work for an MS-only shop then that's sort of where you started, so I guess that's why you see me as just someone with an axe to grind.
Oh, well, good luck on your work.
Hello again.
We've been thru this. Even Bush2k has admitted that there is no .NET equivilant of an applet. Web Forms are *not* even close. But whatever.
Altho I'll ask you, since I can't get any details from anyone else --
I'm looking for a success story of .NET deployment similar to the one I just posted.
You must know of at least one successful .NET implementation of a major production system?
Actually, a developer would be encouraged to share their opinions and experiences with new technologies, especially one like this that is trying to gain acceptance.
I talk openly here about the projects I work on, and give as much detail as you'd like. My company loves that, in that it means I'm out here learning 'best practices' and exchanging and gaining knowledge. All the developers I know are the same. We *talk* about what we build.
In my experience, only a salesman would claim to know about great things they won't talk about.
And -- I thought that the 'WinForms' I read about didn't run in the browser, but had to be downloaded to the client and ran locally as a local application. Very, very different technology, more akin to a java application without the 'Java Web Start'. Am I mistaken?
"Paid"? Microsoft PAYS Partners??? I want my check!
The 'Windows Forms' are more akin to the 'Java Web Start' tech. Downloading an app that executes locally on the client as a local app.
Very, very different from an Applet executing only in a browser, with no ability to affect the local machine.
You've never done any DB work, so you probably don't realize that the delay is the actual processing of the data. The DB has to build temporary tables and does all the number crunching in a very, very inefficient manner, processing data relationally.
In an language like C# or Java, you do number crunching in an OO manner, optimized to the specific report to be churned.
For any complex report, the DB will be the absolute slowest way to number crunch possible.
Where is your proof?
Harr, listen, guy, you make such accusations and then claim that "everybody knows it", but Microsoft and millions of people have the benefit of success. Plus, I don't know it, and after 20+ years developing systems, and 23 years using Microsoft products and technologies, I totally disagree with you, so I guess it is "everyone but PatrioticAmerican"?
If Java is the only thing going that works, why are there so many people benefiting from Microsoft products and technologies?
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.
