ISVs and Porting Applications to OS/390: Project Experiences

This roadmap of the technical and non-technical activities involved in assessing porting new applications onto OS/390 represents some "lessons learned" in managing over 20 ports to OS/390, through both technical and non-technical activities.

• 01/01/2000

Editor’s Note: IBM Server Group S/390 Application Enablement Specialist, Chuck Calio, has established a roadmap of technical and non-technical activities involved in assessing porting new applications on to OS/390. This represents the "lessons learned" by Calio in managing more than 20 ports to OS/390, and a further body of knowledge from his IBM colleagues. Both technical and non-technical activities will be described with the intent of producing a roadmap on "how to get started."

In my work at IBM as an S/390 Application Enablement Specialist, I get to meet with independent software vendors (ISVs) and IBM customers that are considering moving new applications onto OS/390. Many of these companies call on IBM to assist in the decision process, with the request initially focused on the technical issues. As a result of these engagements and lessons learned over the years by IBM, I’ve developed a "roadmap" that represents a set of coordinated activities you’ll need to go through when exploring the possibility of adding new workload on OS/390.

As further background, these observations represent lessons learned from my experiences, and also represent further input from my colleagues at IBM who collectively have helped port or modify more than 1,800 applications onto OS/390.

Key point: I stress at project startup that close coordination between the business case, management sponsorship, project management and technical considerations are key to ensuring that the porting effort moves forward in an optimized manner. Much of this entire process is not unlike managing almost any other project, whether it is IT and software related or not. Many of the steps I’ve noted here should be familiar to project management at most any level, and what I have tried to do is to add that "porting" twist to put this in perspective and add specifics where they can help anchor your view of such a project. Let’s explore each of these steps and how they are all related.

A business case and management sponsorship are required to objectively evaluate a new project, "push" a project toward a "go" or "no go" decision, and gain momentum if started. The business case details the reasons and logic behind why you are proposing to devote company resources to this project. In conjunction with the project plan and technical considerations, the business case should also detail how risky the project will be. You’ll need management sponsorship in order to obtain initial project funding and staffing, and the management team will require an objective business case that makes sense to support this project. You should assume this project would compete with other ideas from other people in your company – view this as motivation to do a good job. The business case is something that usually requires input from multiple people in your enterprise, so allow time to gather their input, suggestions, and listen to the issues they raise. Components of the business case include project benefits, project costs, and variations on return on investment (ROI) analysis.

Project benefits should include, at minimum, a three-year outlook for anticipated financial benefits to your company for doing this work. Benefits can take the form of: new licenses or sales of this application on the OS/390 platform (for ISVs), or how this new OS/390-based application can help your company or other companies decrease the cost or problems of doing business, or improve current problematic areas like application availability, reliability, security or scale.

When summarizing project costs, you will need, as input, the project plan, which we will discuss below. This is a detailed document; for the business case, you will need to net out a summary of the project cost items (such as funding and staffing), and should review the project risks and risk mitigation plan with management.

For ISVs, the business case should always address how you intend to market and sell this application in a new market once ported. Address this at the very beginning of the project. Involve your company’s finance team and ask them to objectively input to the business case, especially when it comes to the variations on how your organization needs to calculate and present financial ROI.

Assume your organization is already resource-constrained, and build into your business case a concise recommendation based on project financial metrics. Even if the project has already been "blessed" by management, make certain you have a robust marketing, sales and ongoing support plan in place. Identify key decision makers in your company and, if appropriate, schedule focused reviews to get an early sense of what education or information they might require prior to a decision checkpoint.

Failing to gain the support of the management team and establishing a good business plan can manifest itself as a series of problems, ranging from failure to obtain initial project funding, proper staffing, or at port completion, not being able to properly market, sell or support the product. You will need to close on the business case and management sponsorship to get the project moving, but you will need a sound project plan to continue to guide you through execution.

Approach the startup phase of an OS/390 porting project as a distinct, measured set of work activities – a project – with a clearly defined scope, and proposed start and finish milestones. After the initial project of bringing a new application onto OS/390 comes the ongoing process of marketing, selling and supporting a new product once it’s brought to market. Focus your efforts and considerations early on in planning and sizing for both activities as you roll up results into the business case.

Project plans list the scope of the effort, tasks and milestones, schedules and resources needed, dependencies, and a clear deliverable at the end of a defined time frame. You can quickly translate a project plan into the cost equation needed for the business plan. The technical team will be key to your task and resource analysis. Build into the project plan some considerations for the level of skills needed – experience levels required is a key component of your skills and time estimate.

When detailing project tasks, and milestones you should include: initial education for everyone who needs more information on OS/390, project porting and architecture reviews, and documented closure of the final target architecture on OS/390. Account for time and resources for systems setup and configuration, the porting effort itself, testing and optimization for performance on OS/390.

Also add in, if appropriate, resources to manage a customer beta program, and completing skills transfer over to marketing, sales and the support team. The project plan you build will structure a team around this goal, so don’t forget to include team startup overhead. As a strategic consideration, it may be beneficial to structure a project with activities that allow you to demonstrate some small success early on in the project.

For example, in project porting efforts to OS/390, you may want to visit one of the IBM Solution Porting Centers, located throughout the world, to work with IBM to port a small, representative section of an application to validate your project plan and technical assumptions.

Also, in the project plan, clearly define at a lower level of detail:

• Every risk you can think of with this project, and for each risk, list a set of actions that can mitigate each risk. This will be input to the business case and as part of the process of obtaining management sponsorship.
• Project staffing details: List exactly what resources are needed and when. There’s nothing worse than complaining about lack of staffing only to turn around and be asked "what skills do you need and when" and not have an answer! Assume from a skills perspective that each team will need a project manager, porting engineers, performance skill, test skill, system and database admin skills, and the eventual need to turn over the port at some period of time to the ongoing product support teams.
• Project communication and change control plan – being careful to address how change requests will be handled.

Some ports to OS/390 will eventually hit some type of technical "gotcha." As part of a normal risk mitigation plan, include education on how to contact IBM and other third parties involved to ask questions, report defects and apply service to products you’ll be using on this project.

I’m frequently asked "How long does it take to port an application to OS/390?" Usually, once I get past the "it varies" speech, I indicate most well-run ports I’ve seen make significant progress within the first six months of the actual port startup. If not, you are either porting a very complicated product or something else is wrong. I’ve also recently observed well-run C and Java ports to OS/390 that are completed in the one-to-three month time frame. Keep in mind, non-technical issues or the process required in your company to startup a new project can be a significant source of perceived lengthy elapsed times for bringing a product onto OS/390. Also, as I stated earlier, differentiate in the project plan between education and the porting effort. Management will want to know (from the project plan and technical sizing) what this project will cost, and what skills are needed and when. The project plan is input into the formal business case, and you will need the help of the technical team to properly complete this effort. See how all of these items are related!

Usually, I like to conduct a first pass porting review on the technical side with the intent to size, at a high level, the degree of difficulty of the effort. I assume (technically) at the start of the evaluation that most software could be ported to OS/390, unless I identify what I call a showstopper. Key technical issues I usually investigate early on in my assessments include:

• What is the current experience level of the ISV with the OS/390 platform and with porting to other platforms in general? If it’s low, you’ll need formal OS/390 education prior to port startup. Existing customers familiar with the traditional mainframe legacy environments might need to formally educate their staff to become more familiar with the newer environments, such as OS/390 UNIX Systems Services, Java environments, or C/C++. Existing UNIX personnel might require more familiarity with OS/390 and its components.
• What language(s) is this software written in, what APIs does the software depend on, and are those languages and APIs supported on OS/390?
• What is the current architecture and what will be the target architecture post port completion? You will have to spend some time and settle on this before you can fully size a port. Evaluate how much of the existing code will remain the same and how much will change or be re-architected to take advantage of OS/390 platform nuances and strengths, such as the OS/390 security model, workload manager, parallel sysplex clustering, and performance optimization specific to OS/390. As part of this port to OS/390, investigate if the application database access logic (native SQL, OBDC/JDBC, stored procedures) or the database support itself will have to be modified.
• What are the co-requisite third party products, from other companies, that also are "defacto" requirements for a complete solution to exist on OS/390? Do these products also have to be ported to OS/390? Or, are they already available? Who on the project is in charge of this? Be careful here, as this list can easily grow rather quickly. It’s not uncommon for the list of third party co-requisite software to exceed 10 "other" products required for a complete solution.
• What are the testing, performance, scaling and customer support needs for this new solution? Many people forget to properly size the test efforts required to ensure a product moved on to OS/390 will install, run and perform up to enterprise customer expectations. Build this into the early assessment.

Whether you do or do not find any showstoppers, report this to management and the project manager. I recommend you then use the technical analysis of the application and post-port architecture as input to the project task list, sizing and staffing considerations in the project plan.

A good deal of highly detailed technical guidance is available from IBM in this area. Check out the IBM S/390 Porting Guide for more details at www.ibm.com/s390/unix.

Once the business case and project plan are finalized and the project is approved, many tasks quickly have to proceed in parallel, such as: education, environment setup, staffing and "team forming," obtaining and installing third-party products, setting up the proper development and porting environments, etc. The project plan should have accounted for all of these activities in the task list. Flag any potential problems to the project manager if that is not the case.

Consider approaching porting efforts to OS/390 as a combination of business, project management and technical activities that all have to proceed ahead in a parallel and closely coordinated manner to get a project started and to insure its success. I’ve summarized experiences from many of the past ISV and customer engagements I’ve worked on in the OS/390 environment as a "Roadmap to Success." Visit IBM’s PartnerWorld for Developers S/390 Web site at www.ibm.com/s390/s390da for more information.

About the Author: Chuck Calio is an IBM Server Group S/390 application enablement specialist at IBM (Poughkeepsie, N.Y.). He can be reached at ccalio@us.ibm.com.