I had a bit of an unusual assignment from a client last week. I had to find a copy of Visual Interdev. Yeah, that one.
The client in question has system that exports information from their common data model into a specialized one depending on client and purpose. Basically it dynamically crates an Access database from scratch and then copies data into it. The problem is that it does all this in VBScript. It's a ton of processing, and it all occurs in the pages life cycle. Understandably, this causes issues when the client has either a lot of data to export, or a complex destination schema. They are running into the inevitable problem now; processes are timing out.
The application is a ASP Classic web application written in notepad. For the time it was written, and the tools that were available to the developer, it's a pretty well designed and built application, but it's definitely showing its age.
The client wants to convert this to .NET, which I am 100% behind. The problem comes when a client with a system based on old technology wants to simply "convert" the application from one platform to another. The client in question hasn't indicated that this is their mind set, but I've had several clients in the past who have felt I should just be able to run their ASP Classic application through a conversion wizard and be done with it, so I'm mentally getting my ducks in a row if this turns out to be the case.
Not only does technology change, but architectural techniques and practices evolve. A design which may have made sense even five years ago can easily be rendered obsolete by changing business needs just as much by advances in technology.
The key problem with the current application is that the majority of the heavy lifting takes place in the page life cycle. Doing a "one-to-one" conversion from ASP Classic to .NET will make it run a bit faster, but you still have the underlying problem; the wrong part of the application is doing all the work. Sure, the increased performance may help for a while, but eventually there is going to be more and more data as their client base increases and they are going to have the same problem again. By performing a conversion like this the client is just reinvesting in the wrong architecture.
In this case, it's clearly time for a ground-up redesign of the application. Clients can often balk at this as on the surface it can present a larger investment; discovery must be done, a design phase is required and it's likely that nothing from the previous version can be salvaged.
But this situation also presents a lot potential positives that may sway a client as well. For one thing, the promise of a system that will grow with the business, not require the business to grow around it. An opportunity to overhaul the user experience may be a way to increase productivity. Perhaps your client have been clamoring for services that your current architecture can't support. Now is the time to look into including these and perhaps introducing new revenue streams. There are lots of ways to find ROI (besides just "Oh, it will work better") in situations like these, and it's very important to find these to make the redesign attractive to the client.
Subscribe
5 comments:
I know it's not as sexy as a rewrite, but can you just split out the DB creation and run that asynchronously?
Clients are often reluctant to fund development projects that duplicate existing functionality, even for gains in performance.
But new development techniques and improved data structures usually give expanded access to the data. So sell the client not only on the performance improvement, but on new functionality that may benefit their bottom line or their relationships with their customers.
I should point out that the client in question realizes the perdicament they are in, and has resigned themselves to the fact that there is going to be a re-write of some kind. I was just attempting to point out that clients in general need to understand the difference and benefits of a "re-write" as opposed to a "simple port." We've all been there before... :)
d.:
We've looked into that as far as creating DTS packages and stored procedures. The problems come from the fact that the data structure on the Access (destination) side is so dynamic that it's difficult to write a package that can give the flexability needed.
We also thought about putting the process either in a COM component or behind a service, but there are issues with that, and the client would rather put that money towards a re-build.
I a BIG fan the asynchrons idea (WCF makes it super easy!) and the client was very excited a couple weeks ago when I pointed out that doing it that way would allow his employees to keep working while these exports are running. More ROI!
blindman:
Isn't that kinda what I said... You know, towards the end? ;)
If the db is really dynamic, just build it from scratch. ADO makes that pretty easy.
d.:
Using ADO to create new database now, the big problem is move the large amount of data during the page load event. It's causing timeouts.
Post a Comment