|
|
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.
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.
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
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).
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 coding 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. |
Another decision involves allocation of responsibilities to developers. There are two common models here:
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.
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.
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.
|
|