Welcome to the first article in a series on moving enterprise systems from a mainframe-based platform to something else. That “something else” could be any number of things, but our default assumption (unless I say otherwise) is going to be a transaction processing system based on a platform like Microsoft’s .NET Framework.  While I expect that there will eventually be some technical content, the initial focus is going to be on planning, methodology, defining solutions and project management.  Moving a large system off of a legacy mainframe platform is very different from a development project that starts with a blank slate. Chances are that you’re going to be shifting paradigms for quite a few people in both your technical and business organizations — and for yourself, as well.

For my first post, I want to talk about the first thing you want to consider when changing one of your core system’s technology platforms. Specifically, you should define what the objectives of your project are going to be.  The obvious first answer may be, “I want to move the system from the mainframe onto a different platform.”  That, however, isn’t really your business objective, but rather the task that you’re going to perform to satisfy your objective.  What are some of the likely reasons for wanting to undertake such a significant development effort?

We want to move a major system to a less expensive platform.  The cost per transaction for mainframe-based systems has increased in recent years for a variety of reasons. Vendor licensing costs have been going up. Resources skilled in older technologies like COBOL are becoming harder to find and hire. Older technologies lack the coding practices and tools that come with newer frameworks, making it harder to modify and extend older systems. This is a fairly common motivation for wanting to move a system to a new platform for both private- and public-sector organizations. Reducing costs is of course a perfectly valid business objective, but there are some caveats to this that should be kept in mind:

• Cost/transaction is a long-term consideration. Adopting a new technology platform may increase your short-term development costs because of the need to train staff so that they can use both the new technology and the new system that you’re creating based on that technology.
• It may take some time to get the same level of reliability, availability and performance from your new platform after your new system enters production.  Even organizations with the best practices find it difficult to meet or exceed the capabilities of mature systems with a brand-new codebase. These factors can lead to unanticipated costs to the business during ramp-up.
• Even if your new technology is familiar to your development staff and increases their efficiency immediately, those are only a portion of the overall project cost. Planning and budgeting, staffing, acceptance testing, communication, documentation, training and compliance are all additional sources of cost that may not benefit as much (or at all) from the capabilities of your new platform.

So, cost may be a driving force, but it is easy to overestimate the short-term savings.  Your organization may be disappointed with the results if that is the only objective taken into consideration.

We want to rewrite our system because it is lacking some key capability.  In this case, you’ve already defined a solution to a known business problem, but discovered that your old system makes it difficult or impossible to implement it. This may be because of some limitation in the technology, but that is likely only if the technology is very old.  What is more likely is that the original system design for your legacy system made some key assumptions when it was created, and that initial premise is no longer valid. A good example of this would be a system that based its core data structures on a fixed set of product offerings. It may be impossible to diversify your product line without a rewrite of the core system. In this case, the change of platform is simply taking advantage of the opportunity provided by needing to rewrite the system anyway. This is one of the best drivers for change, as it is likely to result in the most satisfaction upon successful completion.

We want all of our systems to be operating on our new standard technology platform.  It is relatively common for organizations to standardize on specific technologies. No organization can be experts in every technology, as hiring and training staff becomes prohibitively expensive. There may also be an element of asserting control over an organization that is perceived as overly chaotic and inefficient. While both of these purposes can be beneficial to an organization, they are benefits that are very difficult to quantify.  Using this as a reason for embarking on a project to change a system’s platform is likely to result in trying to match a tangible cost to an intangible benefit, and may make it hard to justify the project to the business either in advance or in retrospect. It is generally preferred to use technology standards as a constraint on determining solutions rather than as an objective by itself.

We have three different possible objectives for changing a system’s platform:  improving functionality, lowering cost, and increasing standardization.  Whether or not a project is considered a success is usually not based solely on getting new software into production, but upon how well that project met its objectives.

[pullquote]It is better to prioritize functional objectives over cost objectives, and both of those over goals related to standardization.[/pullquote]Having objectives expressed in terms of new functionality is preferable because the result is easy to see.  Cost can also be measured, but by its very nature is more intangible and easier to debate.  Standardization is the least satisfying of the objectives, with benefits that are difficult or impossible to clearly illustrate and measure.  The consequence of this is simple:  It is better to prioritize functional objectives over cost objectives, and both of those over goals related to standardization. You are more likely to have your project considered successful using that approach.  Also, if your project doesn’t have any objectives associated with functionality, or even functionality or cost, then it would be prudent to change the scope of your consideration to include them.

It’s worth noting that new functionality isn’t really an objective in and of itself. Treat that as a placeholder for whatever variety of actual business objectives are intended to be realized by the changed system. For example, a self-service option for customers may be targeted at both improving customer experience and lowering business operating costs. In terms of your system, that translates into a specific set of features targeted at those business objectives.

Also keep in mind that I’m talking about prioritizing objectives based on post-project assessment. Cost and functionality are likely to switch places in priority when you’re attempting to justify the project before it begins. Before anything tangible has been created, cost savings are likely to be easier to visualize than potential system capabilities, and are therefore more likely to result in an agreement to commence work.  A sign of a potentially highly-successful project is that the interest of stakeholders shifts from cost to the capabilities of the product as it is built.

Having objectives and prioritizing them based on your ability to demonstrate success is going to go a long way toward making any project, including a platform change, a successful one.  Please feel free to contact me via e-mail with questions, feedback, or topic suggestions for this series.