IBM's Premier Business Partner
 

Incorporating Java

by Scott Chalmers, Arkay Computer Consultants

Summary:
What are the issues and solutions that iSeries/AS400 IT managers face as they attempt to introduce Java into their IT shop? What is the best strategy to successfully transition COBOL and RPG developers into the world of Java and eBusiness technologies?

Java. This one word has had a huge impact on our industry. The mere mention of it brings an acknowledgement from even the most technically un-savvy. Back in my mainframe days I read a spy novel that mentioned COBOL and I was excited that my specialty was in print, even if it was a cheap paperback. Today my 11-year-old daughter knows that Java is the language of the Internet. Business today is calling for eCommerce and the web. The problem for midrange technical management is that most of these managers know about as much about Java as my daughter.

We cannot blame the business users for pushing the issue. There are tangible benefits to using the web. There are also tangible benefits for integrating Java into your shop and this is the challenge faced by the technical manager: How do you best take a staff of “legacy” developers and indoctrinate them into this new world of objects, classes, exceptions and bytecode. It is not an easy task but one that when done correctly will have a large positive impact on your company. It calls for a commitment of time and money. My guess though, is that for every RPG/COBOL development team that is successful in the transition, there are at least ten failures.

Why so many failures? Well, failure is relative. It is based on the goals set at the start and my experience is that most projects fail the second the Project Scope and Goals document is written. The poor tech manager hears his users, he sees IBM touting Java, he hears how great the 400 is as a web platform, he hears the pleas from his developers about wanting to “learn cool stuff”, and he wants to please the boss. So he gives them what they want to hear. He promises to have application X (usually a mission critical app) rewritten in Java with a web interface and web administration done and in production in 6 months. (I don’t know why but it seems every project of this type I have seen is promised in 6 months.) He also requests a budget for next year without having a clear idea of the path the team will take. This just causes more problems and more pain down the road.

I’ll give you a real world example of this without using any names so to protect the innocent. This occurred at a large company with a huge app running the key piece of business. The development team was made up of over 25 developers. The app was implemented worldwide. An external resource provided an estimate to the manager of 2 years to develop the staff and have some of the key backend services rewritten in Java. During that time, web based clients would also be completed. Implementation was to be phased country by country. The manager went with his own estimate though and promised full staff development and a first release in that magical time frame of six months. Failure. It never happened, and to my knowledge has still not happened.

Why? The biggest reason is that there is a lack of understanding of the real requirements and costs. The thought is that you load Websphere on the 400, send your staff to Java training and start coding. Failure. My experience is that you need time, you need training, you need expertise, and you need to accept short-term setbacks to reach your ultimate goal. Java, through its OO support, is extremely effective at capturing your business domain. And its ability to tackle the implementation of the most complex requirements makes this investment one that will prove profitable. Below I detail an implementation strategy, highlight some key points that managers must keep in mind when planning a move to this new platform and address some of the more popular myths about Java and eCommerce.

Staff Development
There is a real difference between the "legacy" developer and the Java developer. I don’t mean to define stereotypes, but the world of Java development can come as quite a shock to RPG or COBOL coders. The world of RPG and COBOL is established, structured and clean, much like Felix Unger. The world of Java has Oscar Madison written all over it. There is very little structure. Code can be dirty and ugly. Everyone has their own choice of tools, style, and implementation. In my COBOL days we prided ourselves on the structure and readability of our code. Java coders pride themselves on seeing how many function calls they can get onto one line of code. The first challenge in training your staff will be setting your own expectations and understanding that getting over this hurdle is not easy. In fact, some of your people will never do it, opting instead to remain where they are.

Step one in the development of a good Java programmer is introducing them into world of object-oriented principals. The last time I looked, RPG and COBOL were not object-oriented languages. Assuming this is still the case, staff development is not accomplished by simply going to a Java class. Java is an intricate language that is truly object-oriented meaning it implements the so-called “pillars of OO” which are encapsulation, inheritance and polymorphism. A developer needs to understand these principals to gain a solid working knowledge of Java to fully utilize the language. When researching the training for OO, don’t sign-up for a 5-day all encompassing course that goes through concepts, modeling, UML notation, etc. While this is a must for your OO analysts, your developers only require concepts. As mentioned below, it may be advantageous to bring someone in-house to impart this knowledge.

Step two is getting the developer close to some code. I believe the best way to learn a new language is exposure followed immediately with hands-on project development. Too often programmers are sent to learn something new and when they return they are put right back where they were. All of the new concepts just learned evaporate into the air. Eventually the manager writes off the training as a motivational tool and blames the developer for not using his/her free time to use the new skills. This is wrong. It is the responsibility of the manager to have project work ready. If the projects did not exist, why would you have set up the training? Below I talk about the process of building your first Java development team and phasing the technology into your shop.

Where do you find the training? There are plenty of tech training groups around the country more than willing to take your money. If you want to use this method make sure the instruction comes from an actual Java developer, not a professional trainer who has the Java course material handed to him. The professional trainer will only understand syntax. Good developers no matter what their background will sit in a course and come up with a lot of style questions. Actual Java developers teaching a course will understand syntax and style. They will be able to handle the questions not just about the language but the development environment as well. And they relate real world experiences to the lessons.

A better route than the training group is to bring the trainer into your shop. Find a Java developer who is willing and able to teach the language, and then act as lead on your Java team. The first reaction to this approach is always negative. The question is always, “How can I find someone to not only lead the team, but that can teach as well?” It is tough, but not impossible, and the benefits clearly outweigh the training group approach.

Look to your own company first. Perhaps Java is being used in another group. This has been the case for me a number of times. The midrange group solves its problem without leaving the company, and the existing Java group gets to do what all Java developers love to do and that is spread the word and bring more people into the fold. There is also the ego thing, and maybe the bonus thing (which is far less than the $2000 per head most training groups are getting for a week of so-so training). And once training is complete you have the teacher on payroll already to help in the start of the first project.

If you cannot use internal resources, than you must look outside either through hire or contract. Every company has different opinions about this, but the goal is to get a good person with solid background in-house. This is where Java certification comes in. Sun has a great idea by offering certification for Java. There are two levels and any person certified, as either a “Java Programmer” or a “Java Developer” will have proved a thorough knowledge of the language. Obviously, you must also look for the communication and organizations skills to teach and lead, and don’t forget web and OO skills. Look to the person’s project background. If they have done server-side web development than they should understand HTTP, servlets, JSP, sessioning, etc. Client side skills such as HTML and JavaScript are also needed.

Step three in the development of your staff is already accomplished if you hired or contracted a Java resource to teach and work with your team. Java developers must be exposed to experience not only with the language but also with the environment. This is a tremendous key to success that is always overlooked by new Java shops. It is not enough to learn OO and language syntax to prepare for a project. The set up and use of a Java development environment is completely different from RPG or COBOL. Even if you follow IBM’s lead and go Visual Age and Websphere, you will face issues that are best addressed with experience.

The First Project
Okay, so we know how we will train the masses, but whom and when? You can’t just close shop and send everyone, and outsourcing current production maintenance and development seems like a tough sell. So the obvious solution is to phase Java in.

When choosing the first team, the manager has some tough choices. The process of phasing in new technology that I have used involves the building of one key team and than dividing and spreading the knowledge to others over the longer term. The manager has to take an unbiased look at his people and choose the three or four best, the ones that are the most adaptable. The wrong people will lead to failure, and failure this early in a project usually spells doom. So don’t choose a person because they deserve it based on a past project. And don’t choose someone because they are between projects. And do not put yourself on the project team unless you are the Java lead. Make this the team of your best and do not expect them to do anything productive until this first phase is complete. Remember, the short-term cost of removing your best people will greatly reduce the risk of failure. Keep in focus the long-term goal and benefits of integrating Java.

This first team will go off to train. As described above, a true Java expert hopefully joins them. Once they complete initial training, you as the manager assign them their first project. This project should be meaningless, a throwaway. You as the manager guard the timeline as with any other project, keeping in mind that delays will occur. The key is to apply a certain amount of pressure while allowing the team to experiment. The Java lead will be responsible for guiding the developers. The key to this first project is not what is built, but exposing the team to all phases of project development. This means that they learn design, coding, testing, promotion to production, documentation, etc. As a deliverable date is reached, it may be necessary to call an unfinished item complete so that the team can move forward. The goal is not to have a finished piece of software, but a team that has experienced the full lifecycle of a Java project.

After this first team is done, the manager has some options. You may take the team and work on an actual production project. You may also add new team members who started training towards the end of the first, throwaway project. If your goal is to transform most if not all of your shop, than you can split your first team and now they act as Java leads. Your original Java lead will now be called upon to train others and act as a lead architect. He/She should let the first team members handle the lower level Java issues. You may also hire or contract more outside Java expertise to work with your existing staff.

Java/eCommerce Issues
Below I address the issues that always come up when managers new to Java either interact with their management or start to size up eCommerce projects. Their knowledge is usually based on marketing or trade magazine summaries. Clearing these issues up helps to build accurate expectations.

1. Java is an easy language to learn.
This is the number one comment I hear from managers. They underestimate the learning curve and expect way too much way to early. The source of this misconception is found in every piece of marketing from Sun and IBM. The most common is how easy it is to extend Java services for customization (remember San Francisco?). The other common misconception is that development tools like Visual Age and Visual Cafe provide wizards that produce most if not all of your code. These tools do provide skeletons based on your options or screens you paint, but a lot is left out and a good deal of coding must be done. Java is a complex tool that is getting bigger every release. Java is leading the technical acronym race by a healthy margin. And as mentioned above, midrange managers underestimate the complexity of the development environment.

That being said, Java is the best tool on the market for integrating the web and eCommerce services to your company’s backend. The combination of Java’s OO capabilities, its support and extension for web based protocols such as HTTP, and its emergence as the standard server side language in the industry make all the pains worthwhile. Your shop’s productivity will dramatically increase. And if you think Java is complex, try and sell C++, Java’s chief server side competitor, to your developers. There is not a C++ trainer out there that does not have nightmares about the days he has to stand in front of COBOL developers and start the chapter on pointers and memory management.

2. The web and app servers on the market will handle all transaction processing logistics.
Industrial strength web/app servers like Websphere and Netscape Enterprise Server are wonderful tools in building an eCommerce infrastructure. But integration of these tools can be time consuming and costly. Developers will find that services like thread support, load balancing and backend integration of the company’s databases and resources will become an issue as projects grow. Managers cannot expect new eCommerce developers to excel in this area. It is a good idea to look to third party support.

3. Java is cross platform.
This is the original selling point of Java and it is true that porting Java to a new platform is possible, especially server side. In the world of midrange development, the idea of writing and testing code on NT and than moving it to the AS/400 is popular. In reality you must allow for detailed testing, system performance appraisals, and possibly some recoding. One-day project plan tasks for promotion to production have caused projects to go from on time to days or weeks behind schedule. Java’s cross platform capabilities are very powerful, but not immediate. So build some time into the project plan.

4. OO languages will provide tremendous reusability.
One of the great strengths of OO technologies is the reusability of classes. This is partly true. The reuse of your Java classes is something that is always talked about but rarely implemented. I don’t mean to say there is no reuse out there. The import of Java packages into your code is reuse, and your use of third party libraries will provide tremendous savings. But to achieve reusability of code written within the organization, the development process must be geared toward it. You must have design and code reviews with a "reuse guru" that has the big picture in mind. It is this person that has to develop and enforce reuse standards and protocols. Managers have to be careful on how they determine their longer term ROI and make sure that they have a realistic estimate of cost savings from the reuse of their current work.

5. If I train my people in Java, they will leave and get another job.
I hear this all the time. And my response is that if you think this may happen, it will. I then ask them if they are running a development shop or a jail? A development shop would want to invest in its staff to better service the needs of the company. If the company calls for eCommerce and Java is the answer, don’t hold back. A jail would try to keep its developers from leaving by withholding knowledge and keep their market value low. And like a jail, your developers will want to get out. When they do leave, your reputation as a shop that offers nothing will cause you to get less and less interest from top talent.

6. Java is a flash in the pan. It is slow and unreliable.
I address this to those managers on the other side of the Java fence who feel that Java cannot integrate with the AS/400. Well, I think that what is happening in the market today is proving otherwise. Java is becoming the standard on the server. While I paint a somewhat dark picture at times, if it makes sense to the business than the integration of Java, if done correctly, will prove profitable. Java is a powerful tool that can run eCommerce. It is the best solution for the integration of web and backend services. And it has the support of the industry (except of course Microsoft which is bagging Visual J++ for its new C#, but that is another issue for another day).

Summary
Integrating Java into the midrange, AS/400 development shop is quite an undertaking that is well worth taking. To avoid failure take things slow, recognize the real cost and time required, and get expertise in-house. When done correctly, the transformation of your development team to this new platform will have tremendous impact on the production of your staff. Java is fun, challenging and rewarding. Good developers want a challenge and they want to learn. This is a chance to provide your people with the environment they desire while better gearing your team to meet the needs of the business in the short and long term.