Managing J2EE Risks

It’s been six years since the Java 2 Platform, Enterprise Edition (J2EE) changed the face of multitier application development. Based on Sun Microsystems’ open specifications, J2EE comprises more than 10 different technologies, among them Enterprise JavaBeans (EJB), Servlets, Java Server Pages (JSP) and Java Message Service (JMS). Applications built using J2EE depend on the execution of a fairly complex product—the J2EE application server that’s generally supplied by such vendors as IBM (WebSphere), BEA (WebLogic), Sun (Sun ONE Application Server) and Oracle (9IAS). These products include the containers that actually execute the application components along with tools for development, assembly, deployment, administration and monitoring.

Since its inception, J2EE adoption has mushroomed, attracting teams building Web-based applications with stringent integration, scalability, reliability and security requirements. But enterprises that are J2EE novices have a long and risky row to hoe from tool acquisition to successful application deployment.

In 1993, the Software Engineering Institute assembled a hierarchical catalog of risks along with a 194-point questionnaire for identifying them (“Taxonomy-Based Risk Identification” by Marvin J. Carr, et al.). Other lists of common risks can be found in Steve McConnell’s Rapid Development: Taming Wild Software Schedules (Microsoft Press, 1996), Barry W. Boehm’s article “Software Risk Management: Principles and Practices” (IEEE Software, Jan. 1991) and Capers Jones’ Assessment and Control of Software Risks (Prentice Hall, 1994), but I recommend that you evolve your own list, incorporating the issues found in your projects.

I’ve taken my empirical observations of small to large J2EE projects as well as the conventional wisdom from such experts as Humphrey Sheil, Ed Roman and Tom Mulvehill to create a quiz derived from the original SEI questionnaire, to help project managers cope with J2EE-specific risks. But first, let’s look at the most basic problems you’ll face: the learning curve, the technological scope and the training conundrum.

The Knowledge Barrier

When using a new platform, be prepared for a fall in productivity for a period of time. If the schedule doesn’t accommodate a learning curve, the project is more likely to be late and less likely to be high quality. Indeed, most risks are related to platform knowledge (or lack thereof), including the language, tools, inherent architecture and procedures. One way around this is to shorten the learning curve to reach the positive phase sooner.

R. Fichman and C. Kemerer delved into this very process in a study of 608 IT departments at medium-to-large U.S. companies that were adopting an object-oriented programming language. In The Assimilation of Software Process Innovations: An Organizational Learning Perspective (Management Science, 1997), they revealed that success in absorbing a new technology is directly related to an organization’s ability to overcome the knowledge barrier. Further, such organizations also possess prior knowledge related to the innovation, and hence have a shorter distance to travel. They also have a greater “learning-related scale;” that is, they extensively apply the newly acquired knowledge in several projects, thus spreading the learning costs and creating a faster return on investment. Finally, these organizations have worked with a variety of technologies and so have a greater probability of finding in-house experience closely associated with the new technology.

Fichman and Kemerer’s results resonate with organizations adopting J2EE. In particular, the challenges loom largest for those migrating from mainframe and non-object-oriented languages, whereas the transition is smoother when the team has experience in using OO languages (for example, C++, Delphi), Web technologies (Servlet, ASP, CGI, Perl), or multitier architectures and distributed systems. In fact, according to a September 2000 Gartner article (J. Feiman’s “Migrating Developers to Java: Is It Worth the Costs and Risks?”), the probability of failure when migrating to Java is 60 percent for Cobol developers; 40 percent for Visual Basic, PowerBuilder and other 4GL developers; and only 5 percent for C++ developers.

Part—or Whole?

J2EE is already a mature platform and numerous projects have been successfully deployed using the full extent of the technology. Moreover, despite the competition with Microsoft .NET, analysts clearly believe that both platforms will coexist in the long run.

In the J2EE arena, the alternative of starting with part or a simpler version of the technology can be accomplished by building a pilot project using JSP, Servlets and standard Java classes, and accessing the database through JDBC. The pilot project should be simple enough not to require integration with other platforms, distributed databases or messaging systems, nor development of too many core business components. In a subsequent project, other technologies—notably EJB and Web services—can be introduced.

Train—or Hire?

Four years ago, a Gartner report suggested that it was roughly twice as cost-effective to hire a Java developer as it was to train a C++, VB or Cobol programmer in Java. Java professionals cost 20 percent more than legacy developers, but the cost of training existing staff is even greater, varying from $23,000 (C++ developer) to $57,000 (Cobol developer), including training expenses, loss of productivity during training, loss of productivity during the first 10 months and compensation increases. Cost factors are accentuated with full-fledged J2EE developers. That said, most computer science curricula now include mandatory Java courses, so there will be an influx of professionals in the near future.

Combining training with specialized consultants is effective. Consultants can help project managers identify major risks and prevent technical issues that impede development progress. They will provide developers and system administrators with guidance in best practices, shortcuts and resources. The great challenge, of course, is to select a consulting firm that balances affordable rates with quality service. Look for those with hands-on experience and vendor partnerships, and you should be safe.

But don’t take my word for it. Evaluate your team’s readiness with this 50-point test of your J2EE project success factors.

The J2EE Risk Quiz

Programming Knowledge—16 Points

1. Are the developers familiar with OO programming?

2. Has the team used distributed component technologies (CORBA, RPC, RMI, COM+, Web services) before?

3. Do the developers know Java?

4. Do the developers know JSP programming?

5. Do the developers know Servlet programming?

6. Do the developers know EJB programming?

7. Does the application require asynchronous invocations or integration through messaging systems? If yes, do the developers know JMS?

8. Will you develop Web services? If yes, do the developers know XML and how to use J2EE APIs for Web services?

9. Do the developers understand Web services capabilities and limitations?

10. Do they understand J2EE transaction support?

11. Do the developers know JDBC?

12. Do the architects understand how J2EE components work within the application server?

Rationale: Not understanding the technology is probably the major risk in the project. Java is much more than just a language syntax; developers need to know the potential of the platform and be able to find the right solutions quickly. Symptoms associated with lack of knowledge include misuse of encapsulation and inheritance, reimplementing functionality already in the framework (a common example is security), choosing the wrong EJB type, oversized EJBs, oversized Java classes needing refactoring and JSPs overloaded with Java code.

13. Are the architects familiar with design patterns?

Rationale: J2EE development requires extensive use of patterns such as session façade, value objects and model-view-controller.

14. Are the developers and administrators trained in the use of the various tools?

Rationale: Different products offer a wealth of tools. Training sessions enable the team to exploit their full power.

15. Is there a plan to learn about unfamiliar technologies?

Rationale: Ideally, developers will fill knowledge gaps prior to embarking on the project.

16. Are there mechanisms to share knowledge and promote cooperation and communication?

Rationale: J2EE adoption involves much new information that must be disseminated throughout the organization.

Deployment and Configuration Knowledge - 9 points

17. Is the J2EE platform new in the company? If yes:

17a. Does the operation team know how to install, configure and administer the J2EE application server?
17b. Are scripts for easy assembly and deployment of components available?
17c. Is there an infrastructure of configuration management, version control, backups, security and so forth for the new platform?

Rationale: The environment setup isn’t a trivial task. In some cases, simple installation of a product takes days because of configuration problems.

18. Is there an infrastructure to favor testability, from design decisions to automated tools?

Rationale: Testing and debugging a multitier application is usually more difficult. Tools such as JUnit and log4j, and IDEs may be of great assistance.

19. Does each developer have access to a separate instance of the application server (perhaps on his/her local machine) for development? If yes:

19a. Is the hardware adequate to run the complete development environment?

Rationale: A typical J2EE development environment requires a reasonable amount of memory—512MB at a minimum.

20. Are the same product and version used in development, testing and production environments?

Rationale: Having development and QA environments that faithfully duplicate the production environment can prevent unexpected problems when the system goes live.

21. Do all developers use the same version of compiler, libraries, drivers and components used in the application?

Rationale: Incompatibility problems are common when programmers use different versions of Java SDKs, the XML parser package and so on.

Specific Requirements—13 Points

22. Are there requirements for integration with Web services, legacy applications, ERP systems, mainframe or other environments/applications? If yes:

22a. Are the strategy and tools for the integration defined?
22b. Does the target environment have a well-defined
interface to integrate with external platforms?
22c Are there success stories of similar integration implementations?

Rationale: Despite the J2EE specification’s rich integration support, in practice such needs are a major challenge, involving multivendor adapters, connectors, different protocols and the like. For example, you may be the first to integrate a J2EE app running in Oracle 9IAS with a transaction system running on an IBM AS/400, and that represents a technical challenge.

23. Does the old version of the application to be rewritten using J2EE have performance problems?

24. Do your applications have stringent performance requirements? If yes:

24a. Was the architecture of the application analyzed for performance factors (throughput, latency, concurrency)?
24b. Does the chosen application server offer performance monitoring tools?
24c. Are third-party profiling and monitoring tools in place?

Rationale: The J2EE platform offers myriad mechanisms to enhance performance and scalability: objects cache, connection pools, load balancing and so on. But if you’re migrating from a centralized (mainframe) environment or straightforward client/server, multitier architecture in general and J2EE in particular introduce some overhead via remote invocations, intermediators that handle security, transactions, lifecycle and so on.

Look at performance from an end-to-end perspective, not just as fine-tuning the final product; early architectural assessment can correlate to quantifiable performance improvements across multiple layers of components.

25. Do the developers understand J2EE security support?

26. Will the application use an existing security domain to authenticate users? If yes:

26a. Do the developers know how to integrate the J2EE server security domain with the existing domain?

Rationale: J2EE offers a raft of security services, and third-party products make administration and programming even easier. In spite of that, many J2EE developers implement homegrown authentication and authorization solutions when off-the-shelf J2EE security support could have saved time.

27. Are you designing business components for reuse?

Rationale: Reusability is the Holy Grail. The EJB component technology purports to embody software reuse, but components must be designed and built with that goal in mind.

Software Process—6 Points

28. Are code conventions and best practices defined for such processes as logging, exception handling, code documentation, data validation and refactoring?

29. Are code reviews performed?

Rationale: If J2EE is a new platform—and Java is a new language—for the developers, code reviews are of capital importance to ensure adherence to best practices and conventions from the beginning.

30. Does the process emphasize specialized roles?

Rationale: In J2EE development, separation of technical roles in the team is key. Typical roles include Web user-interface designer, Web user-interface developer, business component developer, application deployer and administrator.

31. Do you create dynamic models of the application?

Rationale: Dynamic views of the architecture and design are crucial to comprehending the flow of control and data in multitier applications. UML sequence and collaboration diagrams are very helpful.

32. Do you clearly document problems and solutions?

Rationale: In a complex, multilayered execution environment, finger-pointing is inevitable: “The problem is in the client-side!” “No, it’s server-side, and it’s probably the entity bean!” Problems will be recurrent, and should be clearly identified and documented to form a repository of solutions.

33. Are schedule and cost estimation influenced by marketing promises or results obtained by other organizations?

Rationale: A common mistake is to believe that a new technology will deliver good results in its first usage. Nonetheless, schedule and costs must be set a priori. In a monolithic, waterfall software process, schedule slips can hardly be addressed. A better approach is to use spiral or incremental models because unexpected problems can be managed in each iteration; if a delay occurs in the current milestone, it’s still possible to reduce features for the next milestone to meet the overall schedule.

Staff Retention—1 Point

34. Is there a policy to retain staff members who acquire valuable technical skills?

Rationale: Companies that adopt leading-edge technologies often see their freshly trained star employees poached by their competitors.

Vendor Selection—5 Points

35. What criteria were used to define the J2EE app server?

36. In addition to the J2EE application server, does the vendor offer add-in products (portal server, workflow and process management, personalization) that meet your needs?

Rationale: The J2EE market offers a broad array of products, from open source solutions to advanced products that cost tens of thousands of dollars. It’s important to clearly state your requirements and ponder the trade-offs of the different alternatives: cost, installed base and market share, technical support, technology, add-in products, Web services support, clustering support and so on. Not many organizations can afford to run benchmarks and conduct proof-of-concept projects with several different products to test performance, scalability, fail-recovery and so forth. Most often, the sources of information driving a decision are published reviews. The bottom line? A thoughtful decision depends on well-defined criteria and trustworthy, unbiased information.

37. Does the product support the version of J2EE and contained technologies that you need?

Rationale: The specifications are continuously evolving, and each vendor implements the new definitions at its own pace. Sun provides a certification test suite so that vendors can get their products certified for compliance with the specifications.

38. Does the vendor provide efficient technical support?

39. Are there discussion lists, user groups, newsletters, on-line documentation and other resources that can be used if the project reaches a roadblock?

Rationale: When the project is active, developers constantly search for answers to technical questions. One of J2EE’s advantages as a mature framework is the availability of consolidated knowledge. However, sometimes the developer seeks answers to a specific issue with the product in use. In that case, the organization is better off with a vendor that has a significant installed base—many others may have faced the same issue and posted the answer somewhere.

TOTAL: 50 Points