ArtinSoft's Blogs

Software Migration Experts
Welcome to ArtinSoft's Blogs Sign in | Join | Help
in Search

Erick Nassar Blog

Thoughts and findings about the software migration world... plus the inevitable random rants and cogitations eventually.

July 2008 - Posts

  • Critical software applications and business continuity

    In the past, the concept of business continuity was typically associated with a company's ability to recover from natural disasters (fires, flooding, earthquakes, hurricanes). The events of September 11th changed the paradigm, ending the somewhat lax attitude towards business continuity planning and turning attention to those threats having an element of human intent. Moreover, business continuity planning began focusing not only on allowing an organization to continue functioning after and during a disaster, but on reducing its impact, hence minimizing the risk of extended disruptions.

    Undeniably, the traditional approach to business continuity requirements has shifted, driven by the demands of globalization and high-tech society. It has grown out of the response and recovery focus and into prevention strategies and techniques. Under this new paradigm business continuity emphasizes on managing mission critical business assets and processes to ensure continuous availability.

    Business continuity planning is a crucial part of an organization's overall risk management, and in a world where information is power and technology is a decisive business enabler, every analysis around contemporary threats with a potential of causing severe damage to the organizational infrastructure leads to the assessment of operational risk linked to information systems. This certainly recognizes the value of software assets in today's business infrastructure, taking into account the fact that significant investments in intellectual capital have usually been embedded in the systems over the years, comprising the back-bone of many companies. Therefore, a modern structured approach to managing uncertainty related to threats encompasses all the necessary averting to ensure reliability, correct functioning and scalability of business critical applications.

    Modern organizations must secure their continuity considering the increasing complexity and interconnection brought by the reliance on technology to accomplish their goals. Those with business critical applications will certainly realize the grave impact of system malfunction upon business continuity, and the implications for stakeholders of damage to the organization naturally deems it as unacceptable. Protecting the financial health and stability of an organization is an essential issue for management, and the high impact risk associated with vital software applications make this area of business continuity planning highly relevant on many companies.

    Risk avoidance or reduction strategies linked to information assurance have to deal with the applications' security, performance and other technical capabilities, with development and maintenance costs and support availability constituting critical issues to consider. In fact, governmental entities and organizations in the power, telecommunication, health, banking and financial industries are subject to regulations that aim to protect public interest, including systemic failure among its previsions to ensure information confidentiality, integrity, authentication and availability.

    But the concept of business continuity is not limited to regulated public utility infrastructures only. Of course, it's fairly obvious how some minutes of downtime can seriously affect a large financial institution, but losing access to information systems has consequences on any type of business. Business continuity is vital to business success, and in today's interrelated world, practically every aspect of a company's operation is vulnerable to fatal disruption. And the aforementioned value of software assets applies to any type of organization, making it an objectionable operational risk to maintain exposed, unsupported critical applications that may not run properly. And modernizing them through non-disruptive methods like automated software migration effectively contains the issues.

  • To VB or not VB. That is the question

    ... in fact, a very common question we hear out there when people begin considering upgrading from VB to .NET: “should I migrate my Visual Basic 6.0 applications to VB.NET or C#?”

    Well, Google on the subject and this seems to be an endless discussion, but let’s start by saying that Microsoft is entirely compromised with the future of both languages, and they have done great efforts to ensure that both VB.NET and C# provide the full-power of the .NET Framework. This was clearly stated during the last TechEd, where I went to both the “Meet the VB Team” and “Meet the C# Team” sessions. They talked about the future of both languages, and made clear that there are no riffs between the teams. They even have Tuesday dinner nights and work together when looking for common solutions. In fact there are several people working on both teams. Of course, each team has invested in different features, but this only result in advantages to developers, providing a better opportunity to opt for the language that better fits each particular job.

    The truth is both VB.NET and C# are first-class citizens on the Common Language Runtime (CLR) with equal access to the same framework features. So in the end the decision should be based on your specific needs, that is, your available resources and customer demands if we are talking about business applications. For example, if most of your developers have been working with VB 6.0 they will probably feel more comfortable with VB.NET. On the other hand, if you have a Java or C++ code base coexisting with your VB applications, it might be better to migrate your VB6 systems to C#, a language that is more comfortable for programmers exposed to some other object oriented languages due to its syntax, constructions and usability. However, the real work on a VB6 to .NET migration is dealing with the Framework and moving your mental model from COM to .NET, so the transition is not just about syntax and semantics issues.

    By the way, we’ve seen a few people suggesting a double path approach for those who chose to migrate their VB6 applications to C#. This idea mostly comes from those who offer a solution that only converts to VB.NET, and they even say it’s irrational to think about jumping from VB6 to any .NET language other than VB.NET. Well, the immense set of differences between VB6 and C# or VB.NET are accurately resolved by ArtinSoft’s Visual Basic Upgrade Companion tool, and about half of our customers can tell those unbelievers better. You’ll find detailed info about that here.

Powered by Community Server (Non-Commercial Edition), by Telligent Systems