Migrating to RTC for Application Development on z/OS

Authors: Tim Feeney, Stephane Leroy, Jorge Diaz, Tim Wilson
Build basis: RTC 4.x

THIS PAGE AND ALL CONTENTS ARE WORKS IN PROGRESS AND UNDER CONSTRUCTION

This topic refers to mainframe based customers that are migrating from current mainframe SCM and development systems, and migrating their data and process to an Rational Team Concert based solution. This section gathers information meant to help to both the entire solution adoption process, and the change that the organization needs to face: from deployment planning considerations to usage tips and practices recommendations.

Planning RTC Deployment

Whether this is your first installation of Rational Team Concert or you are expanding your existing deployment to consider System Z development practices in your organization, there are some adoption planning typical questions to face. This section provides information on that regard, with special focus on deployment planning and architecture.

CLM Deployment Topologies and Solution Architecture

The place to begin is the standard CLM deployment topologies for the enterprise, as well as the E5 and E6 topologies captured in the original standard deployment topologies article on Jazz.net. These two topologies are quite simple, and because of that, they are the easiest to deploy and maintain.

RTC Sizing and Performance

Installing and Upgrading RTC

Perform Migration assessment

The first step toward a successful modernization/migration process is an assessment of the best projects/applications to be migrated first. In this step, the ISSR and client team leads talk through the migration process and what kinds of decisions must be made going forward. The initial set of applications to be migrated should be simple enough to enable a relatively clean migration but robust enough to exercise the decision-making that must occur during migration in terms of project area, stream and component strategy as well as build, promotion and deployment scenarios. In addition to identification of the actual source code to be migrated, the migration strategy must take into account requirements as we move clients to this new environment. This is a process discussion and a set of use cases to be supported in the new environment must be produced as part of the assessment.

- Assemble the team including appropriate stakeholders

- Identify candidate projects for initial migration

- Identify scenarios to be supported in new environment

- Establish requirements, document differences between old and new environments

Analyze mainframe applications

In this step, an analysis of the applications to be migrated must occur. This step is intended to identify the structure of the applications and details about the location of the component parts, the number and type of files, etc.. The output from this step will be used to define the RTC structure and migrate the source code.

- Analyze set of applications to be migrated to understand components, structure, languages/technologies used, gaps in available source and/or knowledge about applications

Define RTC structure and practices

The next step in this process is to develop a straw man of the RTC structure for migration: project areas, streams and components to be defined; developer scenarios walking through this structure; the build definition artifacts, including language definitions based on the set of files identified earlier and their associated translators if required.

Create project area

Choose a process

Configure process

Customize process

Define SCM structures and practices

This subtopic talks about the definition of the SCM structure (components, streams and so) that you need to face when preparing the migration to RTC, along with some development practices in which the SCM structure is a clear influencing factor.

Factors influencing the SCM structure and practices

Before talking about the structures and practices definition by themselves, it is very important to discuss the factors that influence the decision and which we recommend to review carefully during your deployment planning.

• Application Structure: the structure of the applications may determine not only the componentization you will define, but it can also impact your process specification; e.g. definition of teams and application ownership.
• Project Organization: what is for you a project area? how will you structure teams? The structure of projects and teams will have influence in SCM.
• Release and Delivery Process: how you plan to release and deliver software will have to fit with the SCM structure that you specify, so your release process is leveraged by it.
• Software Development Process: whether you are Waterfall and want to keep this process as much as possible in RTC; planning to work Agile or a mixed approach it will have a reflect on how you develop and deliver software in RTC.

The rext of this topic will try to discuss each of these elements in detail.

Application Structure

The structure of the applications is key element study when you plan your migration. The abstract "structure" concept encapsulates different areas you should work on:

Applications

At the very basic level you have to consider an inventory of the applications you are to migrate to RTC. These applications are to be studied in the migration process to determine the different factors that are discussed in the rest of this subtopic: their componentization; the dependencies; and the security constraints. It is also important from these applications report to determine which teams work on each application and the Business Units that each team belong to. This kind of map will help you figure out the network of teams and applications that you will have to keep in mind to define the team areas, and the ownership of components and streams. A weak consideration of this area may influence your process design or increase the complexity of process permissions and roles.

Typical questions you may face:

• List of applications to migrate: identification of them
• Teams that work on each application
• Business Units that relate to these teams working on the applications (note that depending on the organization maybe not both but just one of Business Unit or teams make sense).
• Any known dependency between applications

Components

Rational Team Concert structures the code around components. Therefore, defining the componentization of your applications is a key step in the process of planning their migration to RTC. Components are made up of zComponent Projects (type of Eclipse projects for RTC for z/OS development); which in turn contain mainframe-based artifacts (source files, link-edit files, and so forth) and build metadata that are used when you perform builds on a z/OS system. Therefore, it is not necessary to separate your components by source code language or technology.

In planning the components layout you have to take into account:

• How your identified applications may decompose in components: logical areas of application development.
• Application ownership: how these components would relate to owner teams or business units. You usually don't want to mix in a component programs with mixed ownership that may result in complex process design or permissions configuration.
• What pieces of code are shared: these are candidates to be placed in "common" components for reuse purposes

Some additional recommendations:

• Try to keep the components small (in terms of number of files). While not a product restriction, it will ease their management as well as build operations.
• Components should ease developers work: easing the task of locating and loading code relevant for their work. While developers can load individual elements, it is desirable to have logical grouped the programs in a component basis to avoid introducing complexity in daily tasks.
• Components names should be meaningful

Regardless of these considerations and recommendations, you should plan to test the component layout design in test project areas to make sure it makes sense to end users, as well as process and organizational restrictions, before deciding on a design and migration.

Dependencies

Rational Team Concert provides features to ease the work with applications and their dependencies such as Dependency Builds to automatically build impacted programs as result of changes, Impact Analysis and Source Code Data queries. However, application code dependencies should be taken into consideration when you are planning the layout of your code for the migration to RTC. While most of influencing factors have already been discussed, it is worth explicitly calling them out again:

• Understanding the applications dependencies will help you design the components layout: your developers may need to modify code in different programs due to these dependencies
• Dependent applications and the componentization will also impact your stream strategy, and the process design: how ownership and visibility is to be achieved.
• It is desirable to put shared code in "common components" that ease reusability
• By default, a modification with a dependency will trigger a rebuilt of the dependent program: bear this in mind in case there is any concern in your organization when considering application ownership, and to help in the granularity of your developers' work

Scope/Visibility

Related with the concept of program ownership, components in RTC can be owned by the Project Area or a Team Area, or by an individual; thus allowing you to restrict the visibility to the code these components hold. Keep in mind this combination when defining your components layout, and its relationship with the team areas definition.

Project Organization

One of the first decisions you have to face when migrating to Rational Team Concert is the organization of your projects. A project area defines the project deliverables, team structure, process, and schedule; and group all of the related artifacts together. What is going to be a Project Area in your organization? This decision is influenced by different factors, and when you are migrating your Application Development for z/OS to RTC you may have already established your project areas layout. The structure has, among others, the following considerations for this discussion:

• Teams distribution: depending on how clear is the separation between teams and the applications, this structure can result in a cross network of teams that may need to develop different applications for which ownership is not clear. While this is not strictly a SCM related problem, but a process one, it has implications in the ownership of SCM artifacts, as well as how code sharing strategies can reusable assets can be defined.
• Reusable code: where your the reusable code is placed and how is consumed by other teams/applications.
• SCM assets ownership: the ownership of the different assets will depend on the structure of projects and teams that you set up.

Anyway, we will describe some of the typical layouts as influencing factors for the SCM structure.

Application

One common approach is organizing the project areas per application. Therefore, each Project Area represents an application on your enterprise and the items and plan it contains represent the work to evolve that application.

Business Unit

In this schema, each project area represents a business unit within your organization. Team areas usually represent departments within each business unit, although other times the team areas are development team within a certain business unit. It will depend on your particular organization and how your development teams are organized, but you typically consider:

• Applications are scoped within a Business Unit which owns it and is responsible for evolving it: otherwise it would make difficult the maintenance of such applications and its tracking and planning.
• Team areas: they may be departments or development teams, depending how your organization is structured, how it makes more sense and how SCM assets need to be articulated in your organization.

There are some other considerations, however they are more related with process and planning specificities; therefore are not considered here.

Feature

Each Project Area represents the work on a feature or, better said, feature group. Different applications belong to that feature group and is common to define one team for the individual applications. In such a structure the applications in a group are very tight related and have dependencies so such a structure helps in the collaboration. It is also common to "isolate" shared code in feature(s) project area(s) on its own, but this ultimately depends on the dependencies and how this code can be isolated.

Hybrid

Regardless of the common patterns discussed, given the variety of needs that each situation exposes, there are common cases where there is a mix of concepts of project areas defined within your organization.

Release and Delivery Process

Test Environment

Frequency

Emergency

Defect

Governance

Software Development Process

Waterfall

Agile

Hybrid

Define Components

Define Stream Strategy

Common practices and scenarios

Define Builds structures and practices

Defining System Definitions

Define Build Definitions

SCM and builds, usage recommendations and considerations

Migrate source code

This step involves migrating the set of applications identified. In this step the source is physically moved from the host-based SCM environment to the RTC SCM environment. This may involve moving the source from a mainframe to a distributed system. It will involve defining the zComponents, zFolders, and zFiles that will hold this migrated source code. Finally, a validation of the production scenario end-to-end is performed on the migrated environment.

Perform the Migration

Create RTC zComponents, zFolders and zFiles to hold migrated source

Move source to RTC

Prime the Production Stream

ROIs for Rational solution for Enterprise Modernization

This section provides links to resources discussing the ROI of Rational solution for Enterprise Modernization (RTC EE, RDz, RD&T, etc.)

• "Value and ROIs of Rational solution for Enterprise Modernization" blog post from S. Leroy (March 2014)

Learning about using RTC for Application Development on z/OS

This section has links to relevant reference and learning materials for help in understanding and migrating to the Rational RTC solution.

Getting started

A landing page for starting up is the "Rational Team Concert for z/OS Recommended Reading List" blog post from T. Feeney.

In addition, the following resources reveal useful:

Learning roadmap, upskilling yourself:

• (devWorks Community) CLM for EM Learning Circle

Videos:

• (Youtube) RTC EE channel
• (Youtube) Search by topic "Rational Enterprise Extensions" note: returns more results than the link above.

RETT team blogs:

• J. Diaz's blog
• S. Leroy's blog
• T. Feeney's blog

Related topics: Deployment web home

External links:

• IBM

Additional contributors: None