Building a Team

J2EE projects require a wide range of skills and good communication. J2EE developers must not only possess strong Java skills and J2EE knowledge, but must be able to liaise successfully with experts in software they use (such as DBAs and mainframe systems) as well as presentation-tier developers.

Due to the complexity of enterprise (not merely J2EE) projects, attempting to save money on cheap personnel is likely to backfire. It's vital to have at least a core of experienced, highly skilled professionals from the beginning of the project. This allows for mentoring junior developers to supplement investment in training courses.

When it's impossible to obtain first-class skills in-house, it may be worth considering short-term consulting early in the project lifecycle from organizations or individuals with proven expertise – for example, to deliver an architecture document or a proof of concept. This is relatively expensive, but may prove to be a prudent investment if it helps avert future problems.

Again, it's vital that the project begins well. The quality of personnel available in the project's inception and elaboration phase will be especially important. These phases can either establish sound architecture and practices that will see the project through smoothly to successful completion, or result in ongoing problems that cannot be solved by throwing more and more personnel at the project as it begins to miss milestones.

Team Structure

Assuming that your organization has staff with the necessary skills, there remains the problem of organizing them into a team. Again, there is no single right answer, as situations differ. However, there are some common issues that deserve thought.

Who Owns the Architecture?

One of the most important decisions is whether or not to have a "Chief Architect" who will have the final responsibility for design decisions, or whether to do things more democratically.

Having a single chief architect has several advantages:

• Clarity of vision

• Quick decision making

• A single person who can represent the project team when necessary (this may be very important in large, bureaucratic organizations, when liaison with senior management is required)

The success of this strategy will depend largely on the personality and skills of the architect, who must have a deep overall understanding of J2EE and who should be able to command the respect of all project personnel.

However, the following risks must be considered:

• Excessive dependency on one individual, who may leave the company (which will mean that others need to be involved in their work anyway).

• The likelihood of unilateral decisions that may be resented by developers. This approach isn't based on consensus.

• The potential that the architect may become divorced from the coalface. It's essential that an architect is sufficiently hands-on to understand all the practical issues that developers encounter. The architect must be able to focus downwards and upwards in the organization, as a key conduit for project communication.

Another approach is to have a committee with overall responsibility for design. This is more bureaucratic and may slow down decision-making while delivering few advantages. Its success is likely to hinge on an effective chairperson (not necessarily the most senior technical person).

Practitioners of Extreme Programming (XP), a democratic programming model, argue against the notion of a Chief Architect (some argue against the notion of software architecture itself). XP uses collective code ownership, where any programmer can change any line of code in the project. This may work in small projects but is not so well suited to large projects since it could be at the mercy of reckless developers. In my experience, a larger project requires a greater level of formality.

Important 

Regardless of who "owns" the system architecture, it's vital that it's clearly expressed and that the whole team buys into it. It seldom helps to impose a design on developers.

Vertical or Horizontal Responsibility

Another decision involves allocation of responsibilities to developers. There are two common models here:

The Vertical Approach

This approach gives the responsibility of implementing entire use cases (from markup generation to interaction with databases and legacy systems) to individual developers or small teams. This approach requires all developers to have expertise with the complete J2EE technology stack.

One advantage of this approach is there is no communication overhead between groups of specialists. The vertical approach also works well with an XP-influenced development process, using collective code ownership.

However, the vertical approach may lead to loss of efficiency and uneven code quality. Even a good developer may waste time dealing with issues they are unfamiliar with, compared to a specialist in that area. Lack of experience may result in poor solutions along with wasted time and effort.

The Horizontal Approach

This approach allocates developers to specific areas of expertise such as JSP or EJB.

The horizontal approach is a more traditional and potentially bureaucratic approach to software development. It can foster efficiency, as developers spend all their time honing their skills in a small area. On the other hand, it makes good communication essential between developers working with different technologies, as several developers or small teams will be required to cooperate to implement each use case. However, forcing understanding that would otherwise exist inside the heads of developers to be communicated (and better still, documented) may be a good thing. Using the horizontal approach doesn't force developers in one team (such as JSP) to wait until the work of another team (such as Business Objects) is complete: interfaces should be agreed early, meaning that simple dummy implementations can be used before real integration is possible.

Possible divisions of responsibility in the horizontal approach are:

• Markup developer
  This will encompass HTML/XHTML development and possibly JavaScript.

• Presentation developer
  Responsible for more technical presentation-tier work, rather than designing good-looking HTML. They will deliver JSP pages, XSLT stylesheets, Velocity templates, and other web templates, given the required markup. In an MVC application, JSP pages will contain little Java code, so may even fall into the province of markup developers. In GUI applications such as Swing applications, presentation developers will be true Java developers expert in the windowing library used.

• Web-tier Java developer
  Responsible for MVC framework action classes, JSP tag handlers, and web-tier helper classes.

• Business object developer
  Responsible for implementing application business logic. Business object developers will use EJB where appropriate, and should have a sound understanding of EJB. Web-tier developers and business object developers must work together early in the project lifecycle to define the interfaces that enable communication between their classes to ensure that they can work freely in parallel.

• Data access specialist
  Java developer responsible for efficient DBMS access. Often this role will be taken on by business object developers. Specialist tasks may include configuring and working with O/R mapping products such as TopLink or JDO implementations and making advanced use of an EJB container's entity bean CMP implementation. Such developers are often a bridge between the Java and RDBMS worlds.

• DBA
  Specialist in the underlying database. DBAs can provide valuable assistance to J2EE developers in vital areas such as ensuring good performance and correct locking behavior.

The smaller the team, the more of these roles each developer or group of developers is likely to take on.

It is possible to mix the two team structure models. The following guidelines may prove helpful:

• A good design makes it easy to apply either approach, as it results in clean divisions between technologies.

• Some developers are happiest working with the range of J2EE technologies; others hate leaving their pet areas. Thus which strategy is appropriate may depend on the personality of valued team members.

• Decoupling markup authoring (or GUI presentation) from middleware coding is one of the areas where it almost always makes sense to use the horizontal approach. Java developers seldom make good HTML coders, and many good HTML coders lack a basic understanding of system architectures. The whole point of designing a web application is to separate presentation from business logic; team structure shouldn't reverse this accomplishment.

• The larger the team and more formal the development process, the more attractive the horizontal approach is likely to be.

• In the horizontal approach, it will always be necessary to have a group of senior developers who have a feel for the entire product. These developers will understand the whole architecture and will be able to mentor other developers. Likewise, in the vertical approach it will be necessary to have developers with specialist expertise who can mentor other developers in particular technologies.

• In the horizontal approach, developers may be rotated through different technologies, while still ensuring a high level of confidence in each group of developers.