J2EE Project Management: Critical measures when beginning a J2EE project

Java Development News:

J2EE Project Management: Critical measures when beginning a J2EE project

By Ed Roman

01 Jan 2000 | TheServerSide.com

 

Executive Summary

To be successful with a J2EE project, you must plan and understand a great deal beyond the technologies themselves.  There are a wealth of project management challenges you must overcome, such as designing the object model, dividing up your team, and educating your team.

This white paper is a brief collection of J2EE-specific project management best practices, along with links to external resources that you should be considering in your J2EE project.  They are taken from real-world experiences, and are intended to help you build J2EE systems.  As you read the white paper, you may find project management issues that you may not have considered in the past.  If this happens, you should consider weaving these issues into your project plan, or highlight the issues for future reference when you begin a J2EE project.  And while we may not be able to answer every question, for each issue, we will point you towards external resources to help you find your own answers.

Get the business requirements down

Before embarking on a J2EE project, you should try to lock down as many of the business requirements as possible.  A suggested process is as follows:

         Build a complete list of requested features.  This is the phase where you should be asking questions about user interface requirements, legacy integration requirements, use-case analysis, and so-on. If your feature list is incomplete, then you should consult with any subject matter experts you can access.

         Weight each feature based upon corporate and business goals, as well as anticipated time to implement.  Prioritize the list by ordering the list by feature weight.

         Gain stakeholder support for the feature list to avoid future bickering.

         Secure a committed project budget from stakeholders.

You should now have a fairly complete basis for designing an object model.

 

Decide whether J2EE is appropriate

Once you have the business requirements down, you need to settle on an architecture.  J2EE may be appropriate, and then again, it may not be.  It behooves you to spend the time to do the appropriate research up-front about the various alternatives.  Table 1 lists external resources to help you make that decision.

 

Table 1. Resources to help you decide whether J2EE is appropriate

Resource

Description

TheServerSide.com

 

Keeps you up-to-date with various news bulletins and articles about the J2EE space.

Mastering Enterprise JavaBeans

by Ed Roman

ISBN 0471332291

Chapter 1 compares EJB, COM+, and CORBA Components.

EJB vs COM+ business & technical whitepapers

by Ed Roman and Rickard OBerg

http://java.sun.com/products/ejb/ejbvscom.html

Compares EJB and COM+ at a business level

EJB vs COM+ Debate

http://www.middleware-company.com

Live transcript of a debate between Roger Sessions and Ed Roman

COM+ and the Battle for the Middle Tier

Roger Sessions

www.middleware-company.com

Complete comparison of EJB and COM+.

 

Staff your project

When you are building a J2EE project team you will often find that you do not have a sufficient number of people in-house, if any at all, with experience developing with J2EE technology.  Dont despair; many organizations are in the exact same position.  You have several options at your disposal:

1.       Hire full-time experienced J2EE employees.  Full-time experienced employees are the most cost-effective way to staff a development team.  However, candidates for full-time employment, particularly those with significant J2EE skills, are often difficult to find.  To achieve this, you must have a solid recruiting process.

2.       Educate existing developers on J2EE.  For organizations with existing development teams, a much easier alternative to hiring full-time J2EE experts is to educate your existing staff on Java and J2EE.  You can fill-in holes in your staff by hiring Java developers who are eager to learn J2EE, or by hiring computer science majors from college who are eager to learn J2EE.

3.       Hire short-term consultants.  Consultants can often be hired for several days or weeks to help you with specific issues such as choosing a J2EE application server; selecting tools, standards, and guidelines; resolving internal debates; providing an unbiased architectural review of your project; aiding project initiation/planning; and mentoring in a specific technology.  Short-term consultants are a bit pricy, but will provide significant benefit to your project when used effectively for that expertise.  Because of their associated cost, you should be engaging these experts for short-term only.  All project teams can benefit from bringing in one or more consultants at the onset of a project

4.       Hire long-term contractors.  Long-term contractors are a happy medium between full-time employees and consultants.  Theyre paid more than employees but often significantly less than consultants, are often easier to hire because contracting is perceived as being high-paying yet low risk by most developers so therefore more people choose this career path, and typically have the experience that you require (todays J2EE contractor was yesterdays full time J2EE employee somewhere else).  Contractors are an effective way to fill out your project team when you find that you dont have enough full-time employees with J2EE experience and dont want to pay consulting rates for a significant portion of your staff.  Skills that you should demand of your contractors is expertise in the specific application server that you are using, experience on one or more projects of similar scope, and ideally experience on one or more projects of a similar nature.

Table 2. J2EE Related Service Vendors

 

Vendor

Service Focus

The Middleware Company

www.middleware-company.com

Provides training, consultants, and contractors for Java, EJB, J2EE, and XML projects.

Ronin International

www.ronin-intl.com

Provides consultants and contractors for object-oriented and component-based architecture and software process development. 

 

Design your complete object model

Once your team is assembled and has a good level of J2EE understanding, you are now empowered to flesh out your object model.  Ideally you should minimize risk by working hand-in-hand with an external J2EE expert who has built such systems in the past.

Whenever you inject a new object into this object model, all layers should be considered.  Ignoring the user interface, the business layer, or the data layer could lead to false assumptions that bite you down the line.

Table 3. Resources for building your J2EE object model

 

Resource

Description

TheServerSide.com

 

Design Patterns section is invaluable resource for building J2EE systems.

Mastering Enterprise JavaBeans

by Ed Roman

ISBN 0471332291

Has a chapter devoted to building J2EE object models.

J2EE Blueprints

http://java.sun.com/j2ee

Best practices guide for J2EE systems.

 

Reuse of J2EE components

In our experience, it is a myth that J2EE components achieve high reuse across projects.  Components are often times copied-and-pasted, but not reused in the true OO sense.

For large organizations building complex J2EE systems, we recommend investing in a J2EE best practices task-force.  This task force enforces coding standards across all projects, enforces that all teams speak the same vocabulary for objects in their system, and enforces that correct design patterns are applied in projects.  The benefit of this task-force is to ease communication between projects, and to enable developers to easily transition between projects with minimal rampup time.

Implement a single vertical slice

Once you have an initial architecture defined you need to start building to that architecture.  We recommend beginning by implementing an initial vertical slice of the system. A vertical slice is a subset of the use-cases in your system.  For example, if youre putting together an E-Commerce site, you might have the vertical slice be the search engine, or perhaps the product catalog.  A vertical slice should demonstrate usage of all the J2EE technologies in tandem.  For example, you would want to be able to show that a browser can connect to a web server running servlets, which in turn interacts both with EJBs that access your back end database and with JSPs to generate HTML to return to the browser.  There are several reasons why you want to develop an initial vertical slice:

 

1.       Gain experience developing J2EE software.  By developing an end-to-end vertical slice you learn how to work with all of the technologies, tools, and techniques that you are going to apply on your project. You have to start somewhere, and its better to discover and then address any problems early in your project as possible.

2.       Gain experience deploying J2EE software.  The first time that you deploy a J2EE application can be confusing.  You have several types of nodes to potentially install and configure web servers, application servers, database servers, security servers, and so on.  You can safely gain this experience by internally deploying your initial vertical slice into your staging area.

3.       Reduce unsoundness risk.  By developing an initial vertical slice you show that the technologies you have chosen all work together, thereby eliminating any nasty integration surprises later in your project.  Remember the old saying: Everything works well in management presentations, but not necessarily in reality.

4.       Prove to your project stakeholders that your approach works.  At the beginning of a project your stakeholders may support you because they have faith that your team can deliver what you have promised, but their support will be even stronger if you can actually show that you can deliver.  Furthermore, developing and then deploying (at least internally) an initial vertical slice can be incredibly important to your project politically because your detractors can no longer claim that it isnt going to work. 

5.      Answer the question: Will it scale?  The vertical slice is a real working piece of your system, and should demonstrate how well your design scales under load.  You can stress test this slice before building the rest of your system.  This reduces risk, especially in situations where you may have questions about whether your object model will work (for example: will EJB entity beans scale?).

6.       Get the design patterns right early-on.  Building the vertical slice will give you experience with what works and what doesnt work with J2EE.  For example, youll have an opportunity to compare and contrast different model-view-controller (MVC) paradigms.  This leads to discovery of a common technical vision.  Once youve locked down that framework, you can apply those best practices to other vertical slices, and enable developers with fewer skills to implement them.

Do You Start Fresh or Evolve Your Initial Slice?

Once you have developed your initial vertical slice you need to make an important decision: do you throw it away to start fresh on future vertical slices or do you continue to evolve it into your system?  The answer depends on the quality of your work if it is poor quality, either because you rushed or simply because you were new to several of the technologies or techniques and therefore made some fundamental mistakes, then you should consider starting fresh.  Theres absolutely nothing wrong with starting fresh because you still benefit from the major advantages listed above.  On the other hand if the quality of your initial vertical slice is good enough for you then you can and should consider keeping the code (or at least applicable portions of it) and use it as a base from which to develop your system.  This is something that the RUP refers to as building the skeleton first.

 

Choose an Application Server

The choice of an application server is an important one to your project.  Although your J2EE applications may be portable between vendors, you will find that the differences make it painful to switch vendors.  So while it may be tempting to go with the current market leader, it behooves you to spend the time to research whether the vendor youre thinking about using is right for you.  This is applicable for both large and small projects.

1.      Our recommended process is as follows:

2.      List the features you would want in an application server.  A consultant can help you build this list.

3.      Weight and prioritize the feature list.

4.      Eliminate all vendors that dont meet the majority of your criteria.

5.      With the 2-3 vendors left, download and deploy your initial vertical slice into those application servers.  You can then measure how well these application servers handle your specific business problem, as well as general usability.

Table 4. Resources for choosing an application server

 

Mastering Enterprise JavaBeans by Ed Roman

ISBN 0471332291

TheServerSide.com application server Reviews section

www.theserverside.com

Selecting a J2EE Vendor by Simon Blake

www.theserverside.com

EJB Portal Product & Vendors Directory

www.ejbportal.com/products/vendors.htm

Enterprise JavaBeans Supporters (Sun Microsystems)

java.sun.com/products/ejb/tools1.html

Flashline.com Application Server Comparison Matrix

www.flashline.com/Components/appservermatrix.jsp

App-Serv Central Contenders List

www.app-serv.com/contend.html

 

Divide up your team

Dividing up your J2EE team is one of the most critical decisions youll make.  When assembling a J2EE project team, you have two basic choices:

Horizontal approach.  Have folks specialize in different technologies.  For example, youd have a JSP team, a servlets team, an EJB session beans team, and an EJB entity beans team.  Members of your team become specialists in specific technologies.

Vertical approach.  Have folks specialize in vertical business use cases.  For example, youd have a search engine team, a product catalog team, and a payment processing team.  Each team would become generalists and gain experience with all the J2EE technologies involved in that domain, such as servlets, JSPs, and EJBs.

You can also go for a hybrid approach, which is a combination of the above.  Table 1 describes the vertical, horizontal, and hybrid approaches to team organization and indicates their advantages and disadvantages.  Table 2 lists several recommended resources for building project teams.

Table 1. Team Organization Strategies

 

Strategy

Advantages

Disadvantages

Vertical Your team is composed of generalist developers who gain experience with every J2EE technology.  They focus on a specific problem domain, or use-case.

         Smooth end-to-end development on an individual use case basis

         Parallel development is easy if use-cases are separated well.  Each developer works on his own use-case.

         Developers have a concept of ownership of a use-case.  They gain a wider range of skills.  Good for retention.

         Good for educating developers on different technologies used in your system to give them a broader picture

         Generalists need to know many technologies, and are typically high-paid and difficult to find

         Generalists typically do not have the specific technical expertise required to quickly solve detailed problems

         Subject matter experts must work with several developer groups, increasing their burden

         Design patterns, paradigms, and frameworks used may change between use-cases.

         If use cases are interdependent, it is difficult to partition the team

Horizontal Your team is composed of specialists in particular J2EE APIs.  Each developer works on several use cases using that API.

         The same team uses the same API across all vertical use-cases.  This ensures consistency in design patterns, paradigms, and frameworks used.

         Specialists become proficient with their API, yielding rapid application development.

         Specialists do not gain exposure to other APIs, resulting in disconnects between layers.

         Requires strong planning to achieve parallel development.  Need to define rock-solid interfaces between layers.

         Retention issues arise.  Specialists do not have a concept of ownership of a use-case.  They only understand a single part of J2EE, and so their skills grow more slowly.

Hybrid Your team is made up of both generalists and specialists.  The generalists have authority over one or more use-cases.  They support API specialists who work on many use cases within a particular API.

         The same team uses the same API across all vertical use-cases.  This ensures consistency in design patterns, paradigms, and frameworks used.

         Specialists become proficient with their API, yielding rapid application development.

         Individual use cases are implemented consistently

         Requires planning and structure early-on in project

         Requires an understanding and buy-in from the team that the generalists have authority within their use-cases

         Must still spec out interfaces between layers for specialists to develop in parallel

So which approach is better?  The answer depends on the goals for your project:

If your goal is to get your project completed quickly, and in a consistent manner our experience has shown us that the horizontal or hybrid approach is superior.  Design patterns, paradigms, and frameworks are kept consistent across the board.  Specialists build a core competency in their API, yielding rapid application development.

If your goal is to invest in the education of your developers to reduce retention issues or to give them a broader long-term skill set, then the vertical approach works well.  Developers gain experience with every technology in J2EE, with the downside as consistency of design patterns across use cases.  In a day and age where good software professionals are hard to find, let alone keep, this is an important consideration.

Table 5. Recommended Resources for Building a Project Team

 

Resource

Description

Peopleware: Productive Projects and Teams, 2nd Edition

Tom Demarco and Timothy Lister, 1999, Dorset House Publishing

This book is the defacto classic within the information technology industry for how to build and manage a software project team.

Constantine on Peopleware 

Larry L. Constantine, 1995, Yourdon Press

This book presents a collection of writings about the software aspects of software development, including developer productivity, teamwork, group dynamics, and developer personalities.  This is a good book to read for anyone trying to understand how to organize and then manage a bunch of software geeks.

Organizational Patterns for Teams

Neil B. Harrison, 1996, Pattern Languages of Program Design 2, pages 345-352, Addison-Wesley Publishing Company.

The paper describes a collection of patterns for building a software development team, including Unity of Purpose, Diversity of Membership, and Lock Em Up Together.

The Unified Process Inception Phase

Scott W. Ambler & Larry L. Constantine, 2001, CMP Books, www.ambysoft.com/inceptionPhase.html

This book describes a collection of activities and best practices for the RUP Inception phase, including advice for building your project team.

 

Next Steps

With your initial vertical slice in place you are now in a position to continue your construction efforts by developing additional slices of your system.  For each vertical slice you will effectively run through a miniature project lifecycle fleshing out its requirements, modeling it in sufficient detail, coding it, testing it, and internally deploying it.  By taking this sort of an approach you reduce your project risk because you deliver functionality early in the project, if you can deploy your system internally you can easily make it available to a subset of your users to gain their feedback.  Furthermore, your development team gains significant lifecycle experience early in the project, giving developers a significantly better understanding of how everything all fits together.

We hope this white paper has been helpful for you.  There are a whole host of other challenges for you to consider as well, such as testing tools, IDEs, performance tuning, upgrading live systems, and so-on.  Please look towards   for links to these and other resources.  And feel free to contact us at http://www.middleware-company.com to setup an initial assessment if you would like help with any area your project.

PRINTER FRIENDLY VERSION
© 2001 The Middleware Company.