WEBSPHERE STRATEGIES FOR ISERIES PROFESSIONALS
Insourcing beyond outsourcing
Jim Mason
08.05.2004
Rating: -4.00- (out of 5)
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 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:
A period of heavy up-front design with the customer to capture requirements
A long period of offshore development that may be phased for delivery of software modules
A period of integrated system testing with the customer
There may be a period of transition to an in-house administration team for support or the support of the application may stay outsourced.
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:
Skilled, certified Java developers
Knowledge on how to manage Java Web development projects
Experience delivering Java Web applications
Lower hourly programming rates
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:
A lot of hours could have been eliminated altogether as programming tasks
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.
Most of the development could have been engineered to use less skilled developers
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.
The reusability of software developed on future applications was lower than expected
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:
Meet the user requirements
Reuse existing software assets wherever possible
Create applications that are easy to use, maintain, administer and support
Minimize overall project costs from design through implementation
Create application components and modules that are reusable on future projects
Develop in-house skills to maintain and build e-business applications productively
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:
Requirements are defined with use cases again.
We use QuickWebWorkshops to build small, proof of concept prototypes that teach the in house staff how to do development and validate the user requirements clearly.
The custom application engineering for the company's project beats generic best practices solutions by lowering total development hours dramatically in many situations.
In design, we use all the company's existing software that can be reused along with IBM tools for iSeries such as JTOpen and WDSC and a wide variety of open-source and other third-party tools.
Instead of a few big code drops during the project, we have smaller, iterative drops for user testing and feedback with the in house staff providing tighter control to the project.
During the development stages, the in house staff is actively involved both in design, lending their application knowledge to our designers, and developing significant portions of the application.
With tighter communication, the company is involved in most of the engineering and design detail decisions even where we are building the frameworks.
Throughout the project, the in house staff that will inherit the application is involved in documenting and testing it using automated tools wherever possible.
Leveraging the broad market of open-source tools lowers the total project hours a lot and provides no-charge, flexible licensing for software components.
If we have large amounts of application coding that can't be done by in house staff we have the option of doing that with hourly offshore resources under the control of the insourcing team to keep costs low.
|
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:
Any project, insourcing or offshore outsourcing, can fail with poor management, lack of skills and the wrong resources.
It may not deliver a first application faster than current offshore outsourcing models although the project delivery dates are probably more realistic.
Subsequent applications should be faster with an insourcing model.
A first insourcing application may have similar overall costs to the offshore outsourcing model. While the overall development hours are usually significantly lower, the average insourcing team hourly rate is higher.
Subsequent applications should be less expensive with an insourcing model since many frameworks exist that are normally reused and the team may be more productive with better tools.
Without the right insourcing provider and the right in house staff and resource commitments, an insourcing project can fail, also.
Overall our insourcing model probably offers more value over the long term with less risk than the normal offshore outsourcing model.
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.
|
|
Rate this Tip
|
To rate tips, you must be a member of Search400.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
|
|
|
|
