What "enterprise modernization" means for mainframe developers
Enterprise modernization can mean different things, depending on your perspective. If you are a software developer, it might mean using modern technologies to implement solutions, such as web services or source code generation tools or leading-edge programming languages. If you are a software architect, maybe it is about adopting model-driven development techniques or adopting service-oriented architecture (SOA). These perspectives consider the technical aspects of enterprise modernization. There is also the business perspective related to driving business value through IT implementation by ensuring complete traceability end-to-end across the application development lifecycle to map development activities to business goals and priorities.
All of these perspectives are valid, and rely on what I consider to be at the core of enterprise modernization: to even start, to even claim that you are "doing" modernization, you must first modernize the way you "do" development. You need to ensure that your multiplatform applications are designed, developed, and built by teams that collaborate throughout the project lifecycle. It generally isn't difficult to agree on this point, but wanting to do it and actually doing it are two different things.
To even start, to even claim that you are "doing" modernization, you must first modernize the way you "do" development.
IBM® Rational Team Concert™ (often referred to informally as RTC) was developed as a multiplatform development environment that enables mainframe and distributed teams to work together throughout the software development lifecycle. It provides the capabilities that distributed development teams have been using for years, takes advantage of the best practices and patterns of development that have proven invaluable in that environment, and also considers the unique requirements of the mainframe environment that have existed for decades and that host the mainframe-based applications that continue to run businesses today.
Now, before you jump to conclusions, the idea is not to make mainframe developers use distributed tools; that would not work, nor should it be the goal. The idea is to provide a modern development environment that takes the best from both worlds, unifying the teams that do development on multiplatform applications, providing the ability to collaborate easily and consistently, and establishing repeatable patterns that have proven successful in producing and maintaining high-quality applications.
You might be wondering how that is even possible, given the huge disparity in the tools and processes used today by distributed and mainframe developers. To be sure, it is a challenge, but one with great rewards. In this article, I provide specific guidance on developing your Rational Team Concert structural design for multiplatform development, focusing on the establishment of project and team areas, as well as streams and components to organize your software applications and the development of them. Although the design strategy and considerations outlined here will not be applicable in every environment, they serve as guidelines that you can use to develop an initial Rational Team Concert setup for your own project team.
Example of a multiplatform development environment topology
Before we get into the details of the Rational Team Concert structure, let's look at an overview of what we're trying to accomplish. Figure 1 shows the simple initial setup of a software project for multiplatform development in Rational Team Concert that I propose.
Figure 1. Initial topology for Rational Team Concert multiplatform development
In this simple illustration of a development project topology, mainframe and distributed developers work virtually side-by-side, making changes to software artifacts as part of a multiplatform software project. Isolated changes can be made, built, and tested at various levels:
- At the developer level, developers can commit their own isolated changes to their private repository workspaces, as signified by the Check-in path. Developers can initiate personal builds and perform unit testing.
- At the team level, multiple developers' changes are committed to a team stream (for example, the Mainframe Dev stream) and made available to all team members, as signified by the Deliver path. Builds at this level might be scheduled to occur regularly at which point changes are ready for an integrated test.
- At the project level, a development lead could accept changes from the individual teams into the Integration stream, ensuring that integrated changes build successfully and can be made ready for formal testing.
Managing multiplatform build requests
In this multiplatform development environment, developers can initiate personal build requests, and team leads can drive the more formal builds, integrations, and, ultimately, promotion to a formal test environment. All of this can be done seamlessly through Rational Team Concert build requests, as shown in Figure 2.
Figure 2. Flow of a build request through Rational Team Concert
Based on which repository workspace or stream holds the source code to be built, Rational Team Concert determines where those builds must be performed and handles the complexity of initiating the build requests on behalf of the requestor. In this way, it provides a unified, truly multiplatform development environment with an interface that is consistent, regardless of whether you are a distributed or mainframe developer.
Now let's look at the details of each of the elements shown in the high-level overview.
Project areas and team areas
A project area is Rational Team Concert's representation of a software project. It defines the project deliverables, team structure, process, and schedule. A project area is stored as a top-level, or root, item in the Rational Team Concert repository. It references project artifacts and stores the relationships between these artifacts.
Project areas can be simple or complex in terms of their product deliverables, process, and schedules. An established project can have multiple active lines of development, such as:
- Maintenance for one or more shipped releases
- Development of a new release
- Exploratory development for a future release
Complex projects can have a hierarchy of team areas. Typically, one or more team areas are assigned to each line of development. Users might have multiple assignments that require them to work within more than one team area. Some members, such as the project lead, might belong to the project area, but not to any specific team area. For a multiplatform software application project, it would be typical to have (at least) two team areas, one for mainframe development and one for distributed development, although separate team areas are not required.
For simple or initial development, a project can start with a project area, but no team areas. As the project grows in complexity, team areas can be created to isolate development along logical boundaries, such as functional lines, new releases, maintenance, and exploratory development. When deciding whether to create a team area within a project area as opposed to creating a separate project area to isolate development activities, it is important to consider that a team area inherits the process and timeline of the parent, which can be either the project area or a parent team area. Team areas can customize the aspects of the process and, when allowed, override all or portions of it, or they can also simply inherit the characteristics of the parent area. A team area can also share common components defined in the project area. Therefore, if your goal is to organize a project structure among a large set of developers, the project or team area hierarchy makes sense.
A project process (the collection of practices, rules, and guidelines that you use to organize and control the flow of work) is defined in a project area and can be further customized in team areas, timelines, and iterations. Team areas are necessary when separate groups within a process need to use different processes.
Project and team area design strategy
Each major software project can have one or more Rational Team Concert project areas. This makes it easier to plan the project scope, gauge risk, and manage resources and deliverables. Some clients equate a software project to an application or set of applications, such as Online Retail or Accounts Receivable; others might equate a software project to a functional area within the organization, such as Retail or Payroll. In any case, think of a software project as a set of functions under development. Exploring how you do that development within your organization now will help you develop the strategy for project and team area design that provides a good starting point. For example, consider answers to these questions:
- How is development done today within the organization?
- What is the logical breakdown of development work?
- Are there development resources that perform activities across different software projects? Or within the same project, but across different application areas?
- What do the "pockets of development activity" look like?
- How are releases managed?
- How are deliverables introduced into production?
Next, define project areas that map to functional areas, decomposed into team areas that map to applications within a given functional area. After you have done this, you can proceed to define other structural elements of your Rational Team Concert environment, including components, streams, workspaces, and system definitions. Keep in mind these characteristics of project areas and team areas:
- Each project area contains a set of software artifacts or common components, such as copybooks, that are used across the team areas.
- Each project area will have its own set of development streams for each release, including a production stream, to manage application artifacts in various phases of development.
- Project areas can use the system definitions from the main Rational Team Concert System Definitions project area and can create additional ones that override or are specific to that project.
- Each team area will own and manage a set of components for a particular application within the software project.
- Each team area will have its own development stream.
- Team areas can potentially access components in other team areas in read-only mode.
Streams and components
A stream is a collection of one or more components. A component is a collection of related artifacts maintained under change control, such as the code for a plug-in, or the group of documents that are used on a website, or a set of source code artifacts that can be compiled to build a deliverable. Artifacts under source control are grouped into components, which can be included in zero or more streams.
A third element, the repository workspace, is an area where you can view or modify artifacts. Development changes occur through a repository workspace, which flows to a stream. The workspace contains one or more components of that stream. Artifacts from repository workspaces can be loaded into local (Eclipse-based) workspaces on the client machine, where they can be modified. Repository workspaces are generally created for development and build purposes.
Stream design strategy
The Rational Team Concert stream structure is fundamental to managing the overall change cycle. Although the stream structure ultimately defined is dependent upon your own site's unique requirements, we propose a basic stream structure that serves as a starting point for any multiplatform project. In this is example, we have a BankDemo multiplatform application with a mainframe capability identified by Bank Dev and a distributed capability identified by Web Services Dev. The flow of changes from development into the integration streams is managed by Rational Team Concert and denoted by the arrows. The flow of changes into formal test and production streams is initiated by Rational Team Concert promotion or packaged and deployed, so the arrows are not present.
Figure 3 illustrates a proposed initial stream structure.
Figure 3. Proposed initial stream structure for multiplatform development
Component design strategy
The concept of a component is consistent across nearly all source code management systems on IBM® System z®, for example:
- Serena ChangeMan requires you to define artifacts based on an application structure.
- CA Alchemist has five management fields and recommends that you use the first two to organize your applications logically.
- CA Endevor recommends that you group your artifacts into a system and subsystem structure to logically organize them.
In Rational Team Concert, components help you control access, manage and consolidate changes and builds, and enable collaborative development. You can split large applications into several smaller components to reuse code between streams and workspaces and to make it easier to build subsets of a system. Components are made up of Eclipse projects (zComponent projects in the case of mainframe-based artifacts). These, in turn, contain artifacts and build metadata that are used when you perform builds. When you create a component, you can put related artifacts together (for example, components that are built together or form a subsystem). For a specific platform, it is not necessary to separate your components by source code language or technology. The recommendation is that you separate source code and other artifacts into components that are based on team structure, access requirements, and build requirements.
To develop your component strategy, follow these basic steps:
- Decompose the software project (project area) into applications (team areas). This process was described previously in the Rational Team Concert project and team area strategy section.
- Identify the shared source code that is common within and across applications. As a result, you might have a project area common components and team area common components for each team area.
- Decompose each application into logical areas of development. As a result, you will have one or more team area components for each team area, in addition to the common components for each team area, as well as the project area, as described previously.
As you develop the component strategy, there are a number of considerations:
- As a guideline, component content should not exceed 500 source files. This is not a product limitation but a best practice to enable collaborative development and build activities. If the client has source code that rarely changes, it could be contained in a component, and you could exceed the 500 source file limit. In addition, if some components are slightly larger, that is fine.
- There might be source files for which application ownership is impossible to detect. In this case, automated analysis might be useful.
- Developers can load source code by component, so it is important to logically group source files into components so that developers do not have to load an entire stream to be able to do work.
- There might be controls in place that limit which developers or teams can update source code. Components control access, so consider access controls when devising the component strategy.
- Component names should be as short as possible while still conveying meaning.
- Component names must be unique within the context of a project area.
To summarize, there is no single right way to set up Rational Team Concert for multiplatform application development, but there are several best practices that provide initial guidance as you begin to design your Rational Team Concert environment. In general, you will define project areas for software projects containing team areas that represent the functional areas in your project. You will organize your software applications into streams that represent a specific state of the application content in various phases of the life cycle. You will also consider how to decompose those applications into components that enable team collaboration while minimizing the amount of source code each developer might need to deal with. Componentization also considers the need to limit access to certain areas of the application.
By considering how your development team will use RTC to develop and maintain multiplatform applications and using that knowledge to design the structure of your projects, teams, source code streams and components, you will have the foundation for a modern, multiplatform development environment in which team members can collaborate both within and across functional areas to implement changes, perform unit testing and debug issues through a unified interface.
- More about Rational Team Concert:
- Find Rational Team Concert articles and links to many other resources on IBM developerWorks, and check the product overview page, features and benefits, system requirements, and the user information center.
- Check the Rational Team Concert page on Jazz.net.
- Watch the Using Rational Team Concert in a globally distributed team webcast or a demonstration of the Dashboards and reports, or listen to the podcast about IBM Rational Team Concert and Jazz.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the developerWorks weekly email newsletter, and choose the topics to follow. Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the “Getting Started” ones are free.
Get products and technologies
- Download Rational Team Concert from Jazz.net and try it free on up to 10 projects for as long as you want (requires registration).
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the Rational Team Concert forum discussions on Jazz.net.
- Rate or review Rational software. It's quick and easy.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. Find out what makes a good developerWorks article and how to proceed.
- Follow Rational software on Facebook, Twitter (@ibmrational), and YouTube, and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Get social about thought leadership. Join the Rational community to share your Rational software expertise and get connected with your peers.