Migrating An Old System To A New Platform
by John Stout
At Stout Systems, we create custom systems for our clients, including developing the specifications when that has not already been done. One of our most frequent requests in the past two years we have had is for the migration of old custom systems, including databases, to new platforms using current technologies.
If you have a similar need, there are a couple of alternatives for doing this. The first is to have a company such as ours gather requirements, create a spec, then design and re-implement the system; requirements gathering is vital, and often includes interviews with staff because, almost invariably, these custom systems are not well documented and frequently the original developers are not available. The second alternative is for you to purchase a commercial system package that approximates your requirements. Then have the vendor that wrote the package make custom modifications to meet your needs; this is often perceived as a cost-saver since the commercial system is "complete."
I have seen that second approach work very well and have also seen it fail most dramatically. When it works, the vendor really did their job up front by studying the existing system, gathering all requirements and not making assumptions. When it failed, a five-figure quote made without the aforementioned up front work ballooned into a half million dollar multi-year project through repeated "discovery" by the vendor of "new requirements" resulting in repeated time and materials billings.
If you go with the second alternative, I would strongly recommend that you get at least one reference from one of the vendor’s customers who has had custom modifications made to the vendor’s product. Find out about the quality of the work, the vendor’s responsiveness, how well the vendor really understood your requirements, the billing rate for change requests and the quality and cost of support.
Any vendor will initially have to do a thorough review of your existing system in order to accurately scope the project. You should suspect any quote that you receive that does not take into account a full system review and requirements gathering. Part of that review should require complete analysis of your existing database, and a method of migrating that data to a new database.
It is more efficient, and therefore less expensive, to have requirements gathering completed at the beginning of the job, rather than have it done incrementally and be billed for it on an ongoing basis. This is the path to a shorter implementation schedule. It also gives you the opportunity to ensure that the vendor understands your system and requirements.
However you decide to implement your new system, ensure it is well-documented for future change requests. In addition to user documentation, it is vital to have documents describing the code modules, test plan and the structure of the database. Ensure that your vendor agrees to provide these.
John W. Stout is the founder and president of Stout Systems. He has twenty-four years experience in the software development industry consulting for many companies on a wide variety of projects. He is also sought after as a technology speaker, presenting sessions at developer conferences and user groups. Email
.
-back to top-
After Working With .NET
by Dave Sweeton
I’ve been programming with Microsoft’s .NET platform for a little over a year now. I’ve used it for a variety of projects from large ASP.NET sites to Web Services and desktop applications. While there are many aspects I like about it, there are also things that need improvement which I discuss below.
ADO.NET
Before .NET, Microsoft created ADO, an ActiveX framework for database access. ADO was/is a great technology and a vast improvement over its predecessors (DAO, RDO, direct ODBC), and it enabled you to write code that easily accessed a variety of databases.
The real problem with ADO.NET, and the biggest departure from ADO, is the fact that each database provider uses separate classes. You write code using either a SqlConnection (for SQL Server), an OleDbConnection, or one of the other providers. Far from ADO, where you change providers using only a connection string (aside from difference in SQL syntax among databases), ADO.NET requires you to code with knowledge of what database you’ll be using (you can use the OleDbConnection for everything of course, but this gives lower performance). Each provider throws different exceptions (without a common "DbException" base class), and most have different methods and properties. While there are generic interfaces (IDataReader, IDbConnection), it’s not uncommon to need to use the provider’s specific class for some functionality.
ASP.NET
ASP.NET is far and away a better technology than old ASP. Instead of using scripting with minimal framework support, ASP.NET is now compiled and has a rich framework to support writing good code. Visual Studio.NET provides a "code behind" methodology that keeps your source code separate from your HTML front end and the WebForms framework gives you an event driven UI model that is very usable. ASP.NET is one of the best frameworks for quickly and cleanly writing complex sites (insert your own JSP/J2EE/PHP/Python/perl/etc. rant here).
That said, deployment of ASP.NET sites needs some improvement. Aspx pages are easy to update because they are compiled automatically whenever they change. However, when using code behind, you need to compile and upload the code files manually. This works okay, except when you’re working with multiple developers, each working on code separately. One developer will build without another developer’s latest code, and parts of the site will break. Remote building on the web server is one possible cure, but it’s hard to set up, and requires installing Front Page Server Extensions on your web server. We really need ASP.NET to build code behind and other support classes automatically.
Multiple Inheritance
This item is going to mark me as a C++ programmer, but .NET really needs multiple inheritance. I know the Java (and now C#) party line that multiple inheritance is not needed and that Interfaces are just as good, but it’s simply not true. There are many cases where a class needs to implement an "IS A" relationship with multiple base classes in order to combine functionality or be used polymorphically in different ways. Interfaces give you the polymorphic aspect, but don’t let you reuse implementation. Without multiple inheritance, you end up with code duplication or ugly inheritance trees.
Templates
I really want a full implementation of templates. Like multiple inheritance, templates are a language feature that some programmers say is not needed. I disagree. While templates can be complex, they are also powerful. There are many code patterns that can be implemented very cleanly with templates, and Generic Programming creates new ways to reuse code.
The next version of C# will have a less powerful (at least based on the previews so far) implementation called Generics. Generics will give us better, type safe (and in the case of value types, more efficient) containers. They will also help avoid the common occurrence of casting variables to the global base class System.Object which sacrifices compile time type safety, and is only marginally better than casting to a void * in C++. It remains to be seen how powerful the Generics implementation will be, but that’s better than nothing!
Dave Sweeton is a software engineer specializing in Web and application programming. He is a member of Wintermute Software, a contract software development company is southeast Michigan. Email
.
-back to top-
