This is my third and final post in a blog series regarding application portfolio modernization projects. Specifically, I have covered different approaches and processes for making smart application portfolio decisions.
As a short recap, in my first post I discussed the business costs of doing nothing, even in the midst of a largely flat or even lower budget cycle. I also addressed the risk associated with an aging and monolithic application portfolio stack.
In my second blog post, I talked about experiences shared by CIOs regarding the options taken, ranging from whole scale application overhaul projects to iterative approaches focused more on process improvement or quality improvement in the application.
In this last post, I will focus on the first option of migration approach, which is to undertake a full transformational project that takes the existing application workload off of a mainframe platform and moves it to a distributed platform on Linux, Unix, or Windows.
What are the options for approaching such a project?
It all depends on the application characteristics within the portfolio.To understand this requires a thorough assessment of technical complexity and associated risk, a process which helps determine the best approach to use in the migration.
The assessment is used to evaluate the application itself, including main COBOL code, other legacy language code components, the transaction processing environment (such as CICS), and batch processing. It is also important to review the application touch-points, such as how an application interfaces with other applications in regards to monitoring tools, batch interfaces, and reporting tools.Once the entire application and interface is fully understood, a migration approach and strategy can be developed. The assessment findings process also helps to determine the best way to stage the migration and line up the teams in the build, test, and deploy project stages.
In most cases, a strategy will involve an incremental approach to migrations and a careful design of the project based on business and technical requirements.One typical portfolio approach is to start with a re-host of an application that has the least risk and complexity.This approach allows the IT team to get comfortable with the entire migration process, build expertise, and boost confidence in the target platform’s performance capability versus running on the mainframe.Sometimes referred to as a pilot, it gives the organization a quick win to gain buy-in within the company.
Program management is the key lynchpin in any project, regardless of approach.Any migration will involve multiple teams across both the internal and vendor groups.It takes an experienced program manager with a strong background in computing platforms and complex technology projects to be able to orchestrate and execute the program.
Just as the quality of program management can make or break a project, organizational change management (OCM) presents a similar challenge and must be handled effectively. A common failure in most IT projects, ineffective OCM is also a culprit in our history of migration projects. Often, the most overlooked aspect of a project is the “human factor” of how a job actually changes from current platform to target after the migration is achieved.
One of my favorite approaches here is to have a skilled migration consultant expert lead a series of casual learning lunches in which he or she shares knowledge and experience at the work site. War stories and victories over a pizza go a long way in accepting change.
It all comes down to the basics of IT project management that has dogged our industry since the ’90s. Migration projects aren’t exempt from this basic tenant. While transformational projects are serious undertakings that deserve careful design and planning, the payoff is the hard dollar savings in operational costs that boost ROI better than any other technology project out there today.