 | |
|
|
| Jim Mason | |
| |
In this article, we'll take a brief look at the value, risks and issues of offshore outsourcing for iSeries Java Web development projects. While any project can have challenges, there are some that appear more often with offshore outsourcing projects. We'll look at a new model that can address some of those risks and issues: insourcing.
Why offshore outsourcing looks good
In reviewing how any project management approach delivers results, there are usually examples of great successes, great failures and many projects with mixed results. Offshore outsourcing fits this pattern, also.
The model for an offshore team is to create a large pool of low cost developers billed on an hourly or fixed price basis -- depending on the project definition done up front. This offshore team designs and develops the application and the documentation.The offshore development team usually
Requires Free Membership to View
Register today to access targeted resources from our editorial writers and independent industry experts including news, tips, and advice to help you do your job more efficiently and effectively. Stay informed on the hottest topics and biggest challenges faced by IT professionals working with iSeries products and services.
has a small, onshore team that directs their work on projects. Usually this results in a part-time account executive, a part-time project manager and a part-time analyst. Sometimes the analyst will be on site at the company for long periods of time.
There are many variations, but the life-cycle of a typical outsourcing project may look like this:
Compared to local consulting companies, the offshore outsourcing team has a significantly lower hourly rate in most cases making them attractive for larger projects.
Compared to using existing, in-house teams trying to learn Java on their own, the offshore team has many advantages:
Usually offshore teams follow many standard IBM Best Practices models and solutions. IBM services teams have implemented many types of e-business solutions. As a result, they promote the theory that the pattern for a solution they've done for one business should apply equally well to your business.
There a wide number of examples where offshore outsourcing has delivered Java Web applications that meet the customer's requirements and cost less than many traditional in-house development options.
Issues with offshore outsourcing
Sounds good so far. What are some of the issues with offshore outsourcing?
It's a significant effort to setup an offshore outsourcing project in most cases so smaller projects are rarely outsourced overseas. They're either done in-house or, if the skills don't exist in-house, they're done by local consultants.
Recently I was hired as a technical project manager to rescue an offshore project gone bad. Forget the normal problems that can crop up in ANY project: poor design, poor project management, poor coding, poor testing, and poor documentation and so on. I found other, specific problems more common with offshore development. Auditing all the hours that were billed by an offshore team on a recent project, I found that:
There wasn't a strong incentive to do better than standard J2EE Best Practices so many items were programmed that could have been other ways: by users, by better tools, by better engineering.
As skilled Java developers, the offshore team didn't worry about engineering a simplified software architecture that could easily be built and maintained by developers new to Java. Lowering the required skill levels needed, supplying beans that simplify development and using tools like WebSphere Development Studio Client (WDSC) that can generate, visually edit and script Java code make it a much easier task for existing iSeries developers to learn enough Java to make real contributions on projects quickly.
While Java offers much greater potential for reuse than RPG or COBOL can, it isn't automatic. On this project, many Java applications were hard-coded for a specific purpose, much like RPG is today. Like many Java projects, there were a wide variety of subsystems to be completed on the project. Most of them could have been built as powerful, generic utilities that would be reusable on many projects instead of the hard coded approach used by the offshore team. In many cases, this could have saved hours even on this one project!
|
Work item |
Issues |
|
Requirements |
Requirements were done with users as use cases following standard procedures but never validated |
|
Engineering |
Best practices were really an excuse not to spend sufficient time engineering an optimal solution for this company |
|
Design |
Design practices meet current standards. Struts and hibernate frameworks were used. The database model was a rich, well-normalized model |
|
Development |
The coding was generally good, consistent and reasonably tight in style. While some tools were used to help productivity, more could have been used that weren't
|
|
Testing |
Testing was really unit testing although the offshore team insisted it was system testing |
|
Documentation and training |
Truly an after thought. When I arrived near the end of the project, none had been done |
|
Administration |
No real thought toward this deliverable |
|
Maintenance |
The offshore team assumed they would do all maintenance so there was no need to document the system or make it easier to maintain |
|
Support |
No real thought toward this deliverable |
|
iSeries expertise |
This wasn't the first iSeries project done by the offshore team. They claimed they understood the iSeries well. They knew nothing about how the iSeries works differently than other platforms. The database access methods were wrong. The processing of batch applications was wrong and so on. |
Work item Issues Requirements Requirements were done with users as use cases following standard procedures but never validated Engineering Best practices were really an excuse not to spend sufficient time engineering an optimal solution for this company Design Design practices meet current standards. Struts and hibernate frameworks were used. The database model was a rich, well-normalized model Development The coding was generally good, consistent and reasonably tight in style. While some tools were used to help productivity, more could have been used that weren't Testing Testing was really unit testing although the offshore team insisted it was system testing Documentation and training Truly an after thought. When I arrived near the end of the project, none had been done Administration No real thought toward this deliverable Maintenance The offshore team assumed they would do all maintenance so there was no need to document the system or make it easier to maintain Support No real thought toward this deliverable iSeries expertise This wasn't the first iSeries project done by the offshore team. They claimed they understood the iSeries well. They knew nothing about how the iSeries works differently than other platforms. The database access methods were wrong. The processing of batch applications was wrong and so on.
Beyond the technical issues, the project manager failed in many basic areas. When I got involved, the project had already taken almost twice as long as originally promised and development was only about 80% done.
While clearly a lot of the problems listed above aren't repeated on many offshore projects, the basic challenges of minimizing programming hours, better user integration in the project, better engineering, better reuse and better design for maintainability and skills transfer are critical for many offshore projects.
Insourcing model for Java Web development
The goals for insourcing are really the same goals you have for any development project:
The insourcing model we use for managing iSeries Web development projects meets these goals by bringing project control back in house. As an insourcing provider, we meet the goals listed by supplying the skills sets and staff needed for this project after first reusing a customer's resources (developers, staff and software) wherever it's cost effective. Our consolidated insourcing team approach effectively brings project management, training, engineering, application development and testing under in house control.
In the ideal model, the company has a highly skilled project manager available in house. Our company supplies technical project management, application engineering and design, custom training workshops for in-house developers. Our goal is to use your developers and administrators wherever we can make them productive on the project. Our insourcing team uses our staff for the balance of the more advanced development and administration tasks.
To subcontract as much development to your staff as possible, we:
1. Engineer the application to require simpler development skills
2. Use better tools and frameworks to simplify development
3. Create custom training workshops to get your staff up to speed quickly
Of the five Java development skill levels, we train in house staff to use level one to three skills ( wizards, visual editing and Java application scripting). We engineer the application, design it and build the key components and frameworks needed that allow the customer to do more of the work themselves. On some first projects, we've been able to get the customer to build as much as 70% of the first real application themselves. This, of course, depends on the specific application, our engineering and components and the workshop training the customer developers go through.
Insourcing benefits over offshore outsourcing
With the insourcing team managing the overall and technical project issues, the project life cycle is different:
|
Work item |
Insourcing
Improvements |
|
Requirements |
The use case model is validated with simple mockups or working prototypes on key items. It takes longer BUT helps prevent the discovery of requirements during system test |
|
Engineering |
With strong iSeries, e-business engineering support involved in detail project design with the users and using a wide variety of tools, there are great opportunities to eliminate and cut programming hours, lower development skills required, increase productivity, create reusable routines and drive solutions to fit the company's real needs well instead of defaulting to generic, Best Practices models are only a starting point here. |
|
Design |
With better engineering, validated requirements designs are simplified in many cases. Additional frameworks and tools would be added to those that were chosen at the time making designs even easier. |
|
QuickWebWorkshops |
Our QuickWebWorkshops are used to build small, proof of concept prototypes with in house staff to validate requirements accurately, train in house staff on development tools and get user feedback avoiding larger design mistakes that occur in projects |
|
Development |
Development productivity would be much higher. The only place where hours wouldn't be reduced significantly is on some of the subsystems. For instance, the 6 weeks spent hard coding a few data migration programs could have generated a user-driven utility to convert any data files. No reduction in hours here. Just a powerful conversion utility that would pay off many times |
|
Testing |
With the project locally controlled, the system test plan was really just an extension of the validated requirements use cases and scenarios. The problems of having 2 different testing models, offshore and local, is easily eliminated. |
|
Documentation and training |
Instead of doing all documentation by hand and then creating HTML pages, the new model was to capture user documentation during system testing, edit it and then publish it into the application. The model is to have users, not developers, do this because documentation will always need to be updated. |
|
Administration |
Key issues beyond setup and configuration are troubleshooting procedures, tools and performance management |
|
Maintenance |
The new focus is to structure the application for easier maintenance using better tools and lower skill requirements. In addition, the application models will be documented offering the option of moving maintenance to another team if needed |
|
Support |
There are a number of enhancements we've been adding to help improve support. For instance, we added an audit feature making it easy to tie a user's Web session to the database job servicing it at any point for easier troubleshooting on database access issues. |
A couple of summary points on insourcing benefits:
Ultimately your opinion matters more than mine on this. Let me know your thoughts and experiences. Send me an e-mail.
About the author: Jim Mason, president of ebt-now, is an iSeries WebSphere architect, trainer and developer. ebt-now provides iSeries WebSphere, WebFacing engineering, development and training services. You can reach Jim at jemason@ebt-now.com.
Jim's creating a self-study course for iSeries programmers that teaches "hands-on" rapid visual development with WDSC for all types of iSeries and e-business applications -- without the need to become a Java expert. The course will be published by Rochester Initiative this year.
This was first published in August 2004