If you’d have told me back in 2001 that I’d still be looking at VB6 code 10 years later I would have laughed in your face. But like the fabled hover skateboards I’m still waiting for (thanks a bunch Marty), the future has a habit of pulling out a few surprises when you least expect them. So having spent the last few years working on entirely greenfield projects I found myself part of a team migrating a large financial system from VB6 and PHP to a shiny new SOA based architecture.
Unless you are very lucky, when embarking on a major enterprise transformation you will have to deal with a significant base of legacy code. To you and many of your developers it’s probably seen as badly designed, poorly implemented code that someone else wrote and left you to maintain - or more commonly known as “not invented here” syndrome. It has probably been serving the company well and making it money for many years. Your options are either a complete rewrite or integration with the current code base – or somewhere in between those extremes. Of course, you could have taken on so much technical debt maintaining your systems that you’ve now become bankrupt and defaulted. Even then, Uncle Bob cautions on the big redesign in the sky.
The company (they are the people that pay your salary) are likely to have limited sympathy anyway for most suggestions which involve the wholesale rewrite of this legacy code. Of course you can always roll out the trite arguments that the system will be easier to maintain, it will be able to adapt to new opportunities and can meet changing needs of the business much more quickly, it will save money in the long run. And do you know what they may even go for it. But, don’t underestimate the risk you are taking before embarking on a complete rewrite.
So, before you pull the trigger on the nuclear option, take some time to consider how you can live with a staged migration of systems and components.
The first thing we wanted to do is ensure that where possible, any new components or services we create utilise our new solution design. This would be pretty straight forward if our new components lived in isolation. Yeah, right. Think of all those little features that any new business requirement needs – for example, cross cutting concerns like configuration, logging, exception handling etc. So you start thinking about migrating some of these as well. Then you realise that if you migrate these, then you’ll soon be migrating other dependencies or worse, duplicating config stores, log locations etc.
As soon as you start pulling at the edges of your code base to look at what can be migrated to the new solution you soon run into these difficulties. A web of dependencies. One strategy to deal with this is to get your new and old code to integrate in a way which doesn’t pollute your new environment but allows you to leverage your existing infrastructure whilst staging the migration. Thankfully, Microsoft have thought this through and have given us some great tools to get components talking together.
In this series of posts I’m going to look at how we could deliver that integration
- How COM components can call WCF services
- How WCF services can expose legacy COM components
- How well does .NET/COM integration perform
If you want to learn more about the integration between .NET and COM I’d strongly suggest getting a copy of .NET and COM: The Complete Interoperability Guide. Whilst it’s almost 10 years old, much of the COM complexities are covered in great detail.