Either you control these vendors or they control your server. Pick one.
Here's the background:
A vendor we'll call Schmuck and Putz, LLC has built a business critical application on .Net 1.1.
So client has problems with server. While consultant is trying to rebuild and make everything work, Schmuck (owner of Schmuck and Putz, LLC) uninstalls .NET 2.0 and installs 1.1 cuz his stuff only runs on 1.1.
We go round and round. We explain that 3.0 has been released and Microsoft shows no sign of abandoning the technology, so there will probably be upgrades beyond that.
We communicate to all involved that Business Critical Software needs to join the 21st Century. If not, then this server can't be on managed services unless this application is moved to a different server. Our general advice is that Schmuck should upgrade his business critical application.
Then we get this communication:
According to our engineers, .NET 2.0 is an extreme change and we do not anticipate supporting it. To make this change, the entire code set will require changing. Also, every one of our clients would require an update to .NET 2.0. . . . The major concern is that with Vista, now, and Longhorn on the horizon, we are waiting to see what changes lie in the future for Microsoft's Component services. So, for now, we are continuing to use Microsoft .NET Framework 1.1.
And you write software for a living?
Did I mention that this product costs client THOUSANDS of dollars a month?
It is beyond my comprehension that these people are out there taking other peoples' money. But it happens every day in every line of business.
Businesses are literally crippled by their commitments to business critical applications that are written by amateur hacks and never upgraded because they don't want to learn the latest tools and techniques.
We've all seen it: One application will only print in a DOS box to a mapped printer on LPT1. Another only works on NT 4.0. Thank God it wasn't 3.51! Some require hard coded shares because . . . that's how the writer figured out how to make it work. And they all have to run as administrator so Mr. Schmuck doesn't have to figure out the security implications of his code.
Truth be told, some of these amateur hacks do some cool stuff.
But a software development business should have a never-ending process of updating their software to keep up with the changing technology. Microsoft WILL replace Longhorn with something else. They will replace Vista. They will replace C# and .Net and every other thing in their basket of goods.
Lessons for SMB Consultants:
- If you can get in on the decision process, help your client find products based on standard technologies, with a track record of updating their stuff.
- If you come in after the fact, get permission to manage this relationship, then force the application vendor to start practicing modern, standard business practices.
- Learn what you can about this line of applications and be prepared to make recommendations about alternatives.
- Make it very clear to the client that the current system is costing real money. Keep in mind that they have paid tens -- or hundreds -- of thousands of dollars over the years. Moving to a new, modern, well-written, program with a future will be expensive.
Your job is not to save the client pennies today. Your job is to help the client make the correct long-term decisions down the road. What's in the client's best interest over 3 or 5 years?
Your role is Trusted, Educated Advisor. Not "computer guy/computer gal."
Consider the lifetime value of this client. Three years from now, you want this client to look back and say "I'm sure glad we took your advice." You don't want to hear "Why didn't you warn us about this? That's what we pay you for. We rely on you to help us make these decisions. We still printing in a DOS box!"
This is one of the more frustrating issues that we have to deal with. I do want to thank Microsoft for Vista however. Stuck in the mud software development companies have been outed and we're taking the opportunity to educate clients that its time to move on toward a more agile and "alive" application.ReplyDelete