Q&A with CEO Günter Hofmann

Günter Hofmann, fecher CEO

This works so well because we have a number of branches in the German-speaking region, Eastern Europe and the U.S., so our specialists are never very far from our clients. And, for example, if help is needed due to bottlenecks or special expertise is suddenly required, the team can be expanded at any time with colleagues from other branches. Our nearshoring team in Romania can also be seamlessly integrated remotely via internet and cutting-edge collaboration tools.

Your company's technical focus is Application Modernization. Is it even necessary to modernize software that a company's team has developed and optimally supported over many years?

There are still many good, fully developed applications out there that, for example, were written in Gupta Team Developer or VB6. We estimate that there are more than 1,000 such commercial applications just in the German-speaking region alone. It is quite sad because innumerable developers invested many years of work in these applications and it is especially their technology platform that is now at the end of its life cycle. Companies need to realize that maintaining such software is like maintaining a very old car. Maintenance becomes increasingly expensive and unreliable. Moreover, modern infrastructures and resources can't be used. If you objectively analyze the situation, you'll quickly see that your software has been in a cul-de-sac for quite some time.

When developers decide they want a new platform for their legacy applications, wouldn't redevelopment be their first choice?

In fact, the initial plan does usually go that way. Redevelopment does seem like the best route: the technical platform is .NET and VB.NET is the closest relative to the old programming language. The development department has to be trained and additional staff hired. The old application is still being maintained at the same time that the new application is being implemented in VB.NET. The stated objective is to finally get rid of all of the old "toxic waste" and to "properly" implement the new application. External help might be brought on board to deal with bottlenecks or for start-up support.

In practice, however, this plan rarely works. In the rare cases when it does work, the actual time and cost involved are multiples of what was budgeted.

In your opinion, why does redevelopment take so much more time and money than expected?

Quite often, the team has to first acquire expertise in the new platform. If external specialists have been brought on board for the redevelopment, they aren't able to efficiently provide support from the get-go because there is a lack of application-specific documentation. Internal resources have to be integrated with the external specialist team to provide them with this information.

The expectations of users, who have worked with the legacy application for years, are often also underestimated. Users will need to undergo intensive retraining to work with the redeveloped application. For the developers, the redeveloped application may be shiny, bright and new but the users' acceptance level is often lower than the developers' expectations. Toss into the mix that a redevelopment is rarely, if ever, error-free. End users are asked to get involved, they test the new software and find bugs. This takes a lot of time and is nerve-wracking.

Redevelopment always comes at an enormous cost. It is hard to calculate the associated risks, which are often underestimated. The challenges start when the technology to be used has to be picked from an unmanageable number of options. Without extensive, deep technical knowledge about these technologies and the application itself, any decisions made will be sub-optimal.

Is having an application modernized by fecher really less laborious? You'll certainly also need information in order to successfully implement the project.

Whether Gupta, VB6 or Access, all of the information and definitions we need for a successful Porting Project are contained in the old application. The only basis we require for the automated migration is the source code. The primary goal however isn't to migrate every single line of old application code, rather it's the definitions comprising the application's overall picture that are ported. fecher uses a rule-based tool to perform this task, which generates the corresponding .NET code. Nearly all of the basic controls that have ever been used have equal or equivalent controls in .NET. If there is an exception or a third-party control, we apply defined rules to achieve an identical presentation in .NET. Using the tool, the feature framework is created and the interface is mapped one-to-one.

Could you describe the end result of a Modernization Project?

The deliverable the client receives from fecher is their old application translated into C# or VB.NET migrated to the .NET platform. The new application works the same as the original application, except that it is on a new platform and among other things, works with 64-bit technology, multi core processors and service models. By modifying the migration process, it is also possible to generate a web interface as the presentation layer.

The highly structured procedure and the high degree of automation ensure the result will be of very high quality. Conceptual formulations are logically and uniformly solved across projects. Inline documentation is fully retained and standards have even been added. The code is as well-structured and formed as in the reference project.

Ultimately, is what you have after the porting exactly the same application, but on a new platform? Is this investment worthwhile?

At first glance, it seems like the one-to-one migration doesn't provide any technical added-value. The natural temptation with a porting project is to simultaneously use it to remove "toxic waste" or add new functions to the software. There is however a huge risk that you will get bogged down in details.

Ideally, in our experience, you should first start with the finished, working solution on a new platform. After fecher has completed the Application Migration, the software can then be further developed and individual components swapped out. The application can expand, yet it will continue to work.

In our Standard Migration Procedure, the source code is substantially modernized. Following translation to the .NET programming language, outdated structures are replaced and an object-oriented syntax is introduced. The UI looks modern even though only minor optical changes have been made. The user experience and the menu navigation remain the same. This is often the best method from the user's point of view: Using the ported application doesn't involve much of a learning curve, so little time is lost and the acceptance level is high. It is possible, however, to make changes to the user interface during a project. For a migration that involves redesign, we jointly work out a suitable concept together with the client. Our most recent project of this type was for our client, Amtech Software.

With redevelopment you could very well end up with a repeat of the same difficult introductory phase you had when the legacy application was first implemented. With the way fecher conducts Application Migration, this will not happen. Users do not require any re-training and the transition to the new application is smooth. As the developers gain expertise with .NET, they can focus on new possibilities for the application without the risk of failure. Because the data back-end remains transparent, in the introductory phase, it is often even possible to run both the old and the new applications in parallel.

How high do the costs run, in terms of time and money, for an Application Modernization by fecher? What should a client expect?

A realistic cost estimate for the Migration Process by fecher is around 15 to 20 per cent of a redevelopment. The project duration is even less than that. However, it's impossible to make a generalized statement as it depends on the number of lines of code, among other things. A rough guideline: Most of the projects we handle take between two and six months.

In step one, we use a tool to obtain a rough estimate of a project's time and costs. There is no charge for this to the client and the estimate accuracy rate is about 80 per cent. At this stage, we are already taking special features and potential hurdles into account, such as third party components, which will make the migration more time-consuming.

If the Rough Analysis parameters are suitable, a Detailed Analysis is performed in the next step. A mutual confidentiality statement (non-disclosure agreement) creates the necessary legal framework. After we've examined the source code, we develop a detailed concept and create a prototype that focuses on the individual requirements and contains the main mask with representative functions. This makes it possible to get a good idea of the performance and quality that can be expected.

If the client selects the All-inclusive Project type, we also prepare a fixed-price offer with a one-year guarantee, from the date of acceptance. We also offer a project plan and a comprehensive analysis document. So, you see:  Nobody has to buy a pig in a poke. Before a client orders, he has already evaluated a prototype of his migrated application, knows the exact costs and has received a binding timetable. And fecher takes on all the risk. We couldn't make it any fairer!