Goto 100 - Development with Visual Basic : Interview

Interview with Richard Warnett of Financial Objects on their decision to go with Visual Basic .NET

Eric Nelson — Mon, 03 Nov 2008 17:38:32 GMT

A big thanks to Richard for taking the time to do this. I have known Financial Objects for many years and have been impressed with how they have successfully taken forward their VB6 investment onto .NET using Visual Basic .NET.

I would love to do a few more of these with UK companies who have happily made the switch from VB6 to .NET or have selected Visual Basic over C# for .NET development. Please do contact me if you would be happy to do this. Thanks.

Richard, could you just say a few words about your role in Financial Objects?

I am chief architect and product director for our Microsoft platform retail banking solution: activebank. I also provide architectural and technology strategy support to other product teams as well as advising the board on technology matters. I have worked with the activebank solution for 14 years now and have followed Microsoft’s enterprise technologies and more importantly, Visual Basic, through that period. In my role I am concerned with the entire development lifecycle, including post-deployment support, which I believe brings a healthy dose of caution and realism when considering the adoption of new technologies, methodologies and approaches. We operate an on-shore / off-shore model for the development and support of this product and this arrangement has provided me with fantastic opportunities to focus on the processes as well as the nitty-gritty day-to-day technology of coding.

I understand that many of your products started out using Visual Basic 6 and earlier. When you decided to move to .NET did you consider also moving to C#?

We certainly considered all of the dishes that were on the Microsoft menu at the time .NET was introduced. We were fortunate to be working with Microsoft under a Premier Support for Developers agreement (PSfD, now Microsoft Partner Advantage – MSPA) at the time, which gave us privileged access to those in the know and for us to be able to have frank and open discussions about the variances between the languages.

The demonstration of the MSIL generated out of the languages was enough for me to understand that we would not be making a technical compromise by choosing to stick with Visual Basic, and so we were free to make the decision on the basis of what suited our organisation best.

Given that we had a large and capable team of Visual Basic developers, a large repository of Visual Basic source code that needed to be supported, and a healthy backlog of work to deliver, the decision to move ahead with Visual Basic was a fairly trivial one for us!

Do you have any regrets about deciding to go with Visual Basic .NET?

I regret that Microsoft did not do more to make VB.NET appear cooler and sexier to developers than C#. The result has been years of developers jumping to the conclusion that C# is the more a able and comprehensive language than VB when that is so clearly not the case. For us, this meant that we had some casualties in the early days in terms of experienced developers jumping ship to work with C#.

But, other than that minor gripe, no real regrets at all.

What approach have you taken to moving Visual Basic 6 applications onto .NET? Did you create or buy any tools to help you?

We were fairly masochistic about it. We saw the re-engineering to .NET as an opportunity to make some worthwhile advances with our application architecture and development processes, rather than taking a sausage-machine approach to getting onto .NET. Consequently, we built a new application framework from the ground up; we re-designed our use of modelling in the development process; and we produced the patterns we needed to be able to integrate both new .NET components and existing COM component in the same deployment.

What would be your advice for a company with a significant investment in VB6?

“Don’t Panic!” I feel that there has been an growing amount of uncertainty perpetuating around our industry, and consequently among our customers, regarding the implications of operating a strategic solution that may be built in part or completely from VB6 code. This has resulted in some “from the hip” demands that software vendors immediately address the “problem” of supplying a solution that is built with an “unsupported” development product.

My advice is that anyone responsible for a strategic solution that is in part or whole VB6 must now set themselves a target as part of their product roadmap to engineer out the remaining VB6 components. They must not feel pressured into removing the VB6 code in any radical way, though. They have time to do it the way that works best for them, their team and their customer. The old adage “don’t bite off more than you can chew” applies here: deal with the re-engineering of the VB6 code as a requirement in its own right. Don’t be tempted to re-architect from the ground up right now (unless that was on the roadmap already and you can afford to put product development on hold for some time).

And finally, what new technologies from Microsoft are you most looking forward to using in the future?

Visual Basic 10. Visual Basic 11. Visual Basic 12...

Entity framework is looking like a ‘worthy of a prod’ type of technology, so I’m looking to get that at least into a lab environment to see what it can do for us in more detail, along with the associated goodies like ADO.NET data services. Team Foundation Server, while not really in the ‘new’ category, is still in the process of being adopted across all of the projects and so I am working to get that up and running across the board. As a distributed development shop it clearly has lots to offer us. The 2008s (Windows Server, SQL Server and Visual Studio) are all foundations of the work we have in the development shop now that will be deployed in the next product release. Business Intelligence is an area that we are interested in right now and can see that the current offerings from Microsoft in this area could help us to deliver some smart solutions. Lastly, we care keeping an eye on the ‘user experience’ space to work out what improvements we can make to our user interfaces without just adding bling for the sake of it.

There’s lots going on and it’s a good industry to be involved in as much as ever, if not more so.

Note: We did this interview several weeks back and for some reason it “escaped” my Inbox into a sub-folder without ever making it onto this blog. I only just rediscovered it whilst unsuccessfully trying to find it on this blog! Sorry.

Interview with William Morgan of Logica UK

Eric Nelson — Tue, 10 Jun 2008 18:59:42 GMT

William has been heavily involved in helping UK companies migrate their VB6 applications to .NET. William kindly agreed to a short interview. Enjoy.

William, could you just say a few words about your role inside Logica?

Hi Eric, I’m the Lead Architect for Logica’s finance business in the UK. The role is an interesting (and challenging) mix of client engagement – alongside strategy, proposition and organisational development.

Can you give us an example of the sort of scenarios you come across wrt to VB6 migration?

We see a real mix, ranging from business critical applications – front and centre on dealing desks, through to suites of dusty old utilities that hardly every change. The ease of use of VB6 was a double edged sword, particularly as institutions move to the .net platform – many have a large portfolio, with a very broad range of quality.

A typical scenario would include a suite of apps with code written in a range of VB versions, including those prior to VB6. The original version of VB is quite important in this context – apps developed in earlier manifestations can become more challenging to move across because the conversion tools target the “proper” VB6 ways of working.

Generally there’re quite a few OCX’s too and we see a number different databases (it’s not all SQL Server). Something else we’re very used to seeing is a complete lack of documentation and regression tests (maybe I should say “not seeing” :o).

These applications are becoming a real risk and some are increasingly costly to maintain. Regulators are uncomfortable about unsupported critical applications. Migrating into the .net platform, either to vb.net or C# contains the issue. Clients are keen to move to new technologies in the simplest and most cost effective way so that their teams can quickly focus on developments in newer technologies and build teams with up to date skills.

How can Logica help in these situations?

We can get involved in a number of ways, helping with an initial portfolio assessment and the decision-making process around which applications to migrate, retire etc. This is generally an assessment of cost, risk and business criticality enabling a clear strategy to be built.

Once the target set of applications are identified we bring a standard set of tools and techniques to assess an application and work out the costs of moving into the .net platform. Logica has built a pretty strong partnership with Artinsoft now, the people who built the Visual Studio VB migration wizard – though we use an extended version of their tooling; this is more productive and makes our life easier than the standard downloadable version.

We generally do migrations as fixed packages of development and testing – and where needed we can also package the apps for deployment. With sufficient volumes we can take this work through to remote delivery locations to keep the costs under control.

Some people want a measured approach at low volume as a background task; others need to go faster – particularly where an app is part of a business critical suite. Much of this depends on the degree of change around the application – it’s more difficult to migrate a moving target.

Is this something you see happening increasingly more often?

We’re definitely seeing more interest in sorting this out over the last 6-12 months.

There’re a number of triggers to the engagements we get involved with – a need to integrate within the wider enterprise, support costs going up, the difficulties in keep developers engaged on older technologies. But more often, an increasingly demanding business with accelerating rates of change. These can all drive a migration strategy

And now of course, there’s the fact that the VB6 development toolset is no longer supported. As well as it being good practice to use tools that are maintained, compliance regimes in Financial Services can often dictate it an unacceptable operational risk to run critical applications on unsupported software.

What would be your advice for a customer with a significant investment in VB6?

Understand what you’ve got to start with. You don’t use the same approach for the whole portfolio; particularly you need to understand the needs from the business point of view. For example, do you really know what processes are being supported, how many users depend on them and how often? Some things you may be better leaving to slowly wither away, others need immediate and urgent attention.

Another key point to consider is that applications written in earlier versions of VB may need a fair bit of refactoring before you run them through the automated tools. You need to understand the assumptions being made by the tool to minimise the amount of manual, post-conversion work. The appropriateness of what goes into the tools makes a huge difference to the reliability of estimates and overall cost.

There’s a lot at a detailed level we could talk about – but testing is the other big one that people don’t usually spend enough time on. We get test analysts involved very early, during initial assessment. The lack of regression testing around earlier VB applications seems rather systemic, and requirements built up over more than 10 years will inevitably be patchy.

And finally, I gather you have been working with Logica to build an offering to help similar companies. What does that involve?

Don’t want to do the big sell here, but we have done a fair bit of this work. The experience, toolsets and organisation is there and we have solid repeatable processes. It’s a learning curve that many don’t want, particularly since it’s not that useful once you’ve dealt with your local problem.

Doing these migrations isn’t rocket science. It can create a heap of work, a lot of it pretty mechanical – and you can distract your development team for quite a while doing things that your business hasn’t asked for. The real reason to talk to us is to contain the risk and keep your focus for the business and future strategy.

Thanks William – and best of luck.

You can contact William via me if you think Logica may be able to help your company.

Interview with Artinsoft CEO Roberto Leiton Garro

Eric Nelson — Tue, 10 Jun 2008 18:42:00 GMT

A little over a year back I first spoke to Roberto to see if Artinsoft could help me with a large ISV with a significant investment in Visual Basic 6. Since then I have had the pleasure to meet Roberto on a number of occasions and have seen Artinsoft do good work with UK ISVs migrating from VB6.

Roberto kindly agreed to a short interview. Enjoy.

Roberto, could you just say a few words about Artinsoft and your involvement with VB6 migration?

ArtinSoft has been in the software migration business for over 14 years. We developed the Visual Basic Upgrade Wizard for Microsoft. This product was intended to be distributed massively and therefore there are many migration scenarios it does not fully cover. We have developed the Visual Basic Upgrade Companion that incorporates the experience of migrating more than 10 million lines of code of mission critical applications. . We are able to customize our product to both decrease the manual effort and to address critical issues like the porting of 3^rd party controls. ArtinSoft has partnered continuously with Microsoft to solve complex situations in which time to market and business continuity are critical.

Excellent. Both you and I have spent time over the last two years working with companies with significant investments in Visual Basic 6. Can you share an example of the sort of scenario you have come across?

Most companies have begun a process in which they intended to rewrite and re-architect the whole application. During the process they realized how painful and expensive a manual rewrite is, and how disruptive this can be for the organization. Now that the clock is ticking with regards to the VB6 EOL, companies are realizing how an automated process is the safest and most economic way of evolving their applications. There is a lot of embedded knowledge that can be reused for the next version of the application.

And how was Artinsoft able to help?

We make the process faster and more productive. Usually we see a mix of application migration and some rewrite, this is where we team up with the customers so that we can focus on migrating the application and the internal team focuses on defining the evolution of the application. Through customizing our product we can reduce the manual work and also facilitate the next stage which is the evolution of the application. We can automatically address the replacement of 3rd party components to native .NET equivalents.

We also license our product to SI’s that execute the services part of the migration. In the UK we have worked very successfully with Logica.

Is this something you see happening increasingly more often?

Definitely. The VB6 migrations are just starting to happen, we have been seeing a big increase in the number of large VB6 applications that are being migrated or the strategy to migrate them is being formulated. The experiences companies are having with total rewrites are increasing the number of automatic migrations.

What would be your advice for a customer with a significant investment in VB6?

First to look at the real costs of a total rewrite and second to assess the impact of a delay in both project schedule and budget will have on business continuity and compliance issues.

I know you also offer migration to C# - is that proving to be popular?

This is one of the most important features of our product. Companies that have standardised on C# really value that we can take their VB6 investments straight to C#, avoiding the need to support both Visual Basic and C# applications. C# appears to be especially popular in the financial and insurance verticals.

Thanks for that Roberto.

For more information Visit www.artinsoft.com or email info@artinsoft.com