Exploring WebSphere Studio Enterprise Developer V5.1.2

48 Exploring WebSphere Studio Enterprise Developer V5.1.2

3.1 Types of development

Although we focus on two types of development, many more variants of these two types exist.

The main contrast between remote development and local development is that the remote

scenario depends on another platform where the development takes place, while the local

scenario uses the environment where WebSphere Studio Enterprise Developer is installed,

which means the workstation, the LAN environment, or both.

There are variations of these types, for example, local development where the data resides on

the host. This data can be accessed using DB2 Connect™ when the data is stored in DB2

databases. The other way around is also possible, where remote files are maintained and a

local database environment is equipped.

3.2 When to use remote development

Reasons to use remote development are, for example, being able to hire developers who can

work within the Microsoft Windows environment, but are not trained in the mainframe world. It

takes a lot of time to educate people with no mainframe experience, but they can adjust very

quickly to WebSphere Studio Enterprise Developer, because Windows is most likely an

operating system with which they are familiar.

We talk about hiring people, but it is also a means of keeping people at the site, because the

toolset is modern and attractive to many users.

In the near future, it will be more and more difficult to hire the right people when it comes to

mainframe development. It is also fair to say that the mainframe COBOL and PL/I applications

are far from disappearing. Many business-critical applications run on z/OS and OS/390®

machines, and these applications need to be maintained. New applications are still being

developed in these environments as long as the alternatives are not providing the key

features that both the languages and the mainframe itself are providing. It is a proven,

long-lasting environment. Recent developments indicate that new life and investments are

pushing the mainframe, and therefore its applications, to new heights.

Another factor in deciding to work with a mainframe and COBOL and PL/I programming is

that this environment is already in place. Most sites with mainframes develop applications that

should run on the mainframe. This means that the complete development, test, and

production stages have existed for a long time and have proven their reliability.

Remote development uses the existing infrastructure on the host, which implies that a

relatively small effort is needed to make the remote scenario work. The installation of the

z/OS components of WebSphere Studio Enterprise Developer on the mainframe does not

take much time. After the installation is in place and the testing is successful, the training

does not take much time either.

During the testing (or proof of concept), it is important to have various developers from the

development department involved in the testing phase. They know exactly what the product

should be capable of doing and they can test the product accordingly.

These are all good arguments, but perhaps the most important reason to use the remote

scenario has to do with the target platform. It is a best practice that development should take

place in the environment where the eventual application has to be executed. If applications

have to run on the mainframe, they should be build on the mainframe. Every environment has

its own peculiar characteristics that should not be underestimated. Even if the testing

environment on another platform approaches the environment on the mainframe, the

application needs to be fully retested to make sure that it does work on the mainframe.