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

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.