This chapter lays the foundation for building a successful first project, from inception to release. It begins by defining what a technical architect is and does and summarizes how the architect works with other team members. The chapter continues with a look at a few alternative approaches to the development process. Still a subject of considerable debate, the definitive process for building a successful project does not yet exist, leading many companies to adopt a hybrid plan.
All J2EE development teams need people with a wide variety of skills to fill numerous roles within the team. Among the many skill sets needed to make a J2EE project successful are:
Technical architect
Project manager
Business analyst
Layout designer
Presentation-tier developer
Business logic developer
Data modeler
Database administrator
Data migration specialist
Infrastructure specialist
Testing specialist
Although the book focuses on the role of the technical architect, this section defines the roles and responsibilities of other major players on the J2EE development team and describes the responsibilities of the technical architect with respect to those roles.
Some organizations use different labels for the roles. For instance, an infrastructure specialist may be called a system administrator, a testing specialist may be a tester, and some organizations may distinguish between a test team manager and individual testers. Regardless of the terms you attach to these skill sets, making all of them part of a development team greatly increases its chances of creating a successful J2EE project.
Further, it's possible for one person on the team to fill many roles and for one role to be co-owned by multiple people if the project is large enough. Some organizations combine the roles of technical architect and project manager. Some organizations have a senior developer double as a database administrator or as an infrastructure specialist. And some have the same developers work on the presentation tier as well as the business layer. I'm not trying to recommend a team organization but merely to communicate what skill sets are necessary, however they are organized.
The technical architect identifies the technologies that will be used for the project. In many organizations, some technology choices are made at an enterprise level. For instance, many organizations make hardware and operating system choices and some software choices (e.g., the J2EE container vendor) at an enterprise level. Commonly, choosing a language, such as Java, is an enterprise-level decision.
However, most applications have technical requirements that aren't explicitly provided in enterprise-level edicts. I make a distinction between technology choices made at an enterprise level and those made for individual applications. For example, a decision to use the Java language for all server-side programming might be made at an enterprise level, but a decision about which XML parser to use might be left to individual application architects. In many organizations, the people making enterprise-level technology choices make up a group separate from the J2EE development team.
The technical architect is commonly responsible for identifying third-party packages or utilities that will be used for a project. For example, the architect might identify a need for a template-based generation engine and choose Apache's Velocity.
The technical architect recommends the development methodologies and frameworks of the project. Typically, the architect makes these recommendations to the project manager. For example, a common recommendation is to document all analyses in use-case format and supplement with a prototype. Another common recommendation is to document the design in terms of an object model. Some organizations define the methodologies used at an enterprise level.
The technical architect provides the overall design and structure of the application. Each developer brings to a project a unique set of preconceived opinions, habits, and preferences. Synthesizing the input of this sometimes widely divergent group, the technical architect ensures that the work done by individual developers is complementary.
I liken the role of technical architect to that of an orchestra conductor. All musicians have differing opinions about how to interpret a given work. The conductor provides the interpretation that will be used and works with the musicians to implement it.
The technical architect ensures that the project is adequately defined. A project analysis must be detailed and consistent enough to form the basis for building an application. Typically, the technical architect works with the project manager and business analyst to define the project.
The technical architect ensures that the application design is adequately documented. Documenting the application design is a critical step in establishing sound communication with and among developers. The process of creating documentation forces the architect to think through issues thoroughly. And the final document enables management to add or change developers to the project without adversely encroaching on the architect's time. For developers, documentation allows them to proceed if the technical architect is absent from the project for a limited period and enables them to work through design inconsistencies on their own without consuming the time of other members of the development team. Documentation also helps to insulate the project against the effects of personnel turnover.
I've seen many projects that were not documented, and the result was that adding a developer was a major chore because the architect had to verbally convey the design to the newcomer. Having to communicate the design verbally negates some of the benefits to bringing on additional developers.
The technical architect establishes coding guidelines. Because individual developers have coding preferences, coding standards need to be articulated so that the individual pieces are more easily brought together. The technical architect is responsible for establishing project procedures and guidelines for topics such as the following, which are covered in more depth later in the book:
Exception handling
Logging
Testing
Threading
The technical architect identifies implementation tasks for the project manager. This role is especially important for J2EE projects because they encompass a much wider range of technologies than do other types of systems projects. Out of practical necessity, the technical architect also helps the project manager with project planning and estimates.
The technical architect mentors developers for difficult tasks. Typically, the architect is more experienced than the developers. When the developers run into a technical problem that slows them down, the architect is often the one to help them create a solution. For many projects, the architect is more of a mentor than an implementer.
The technical architect enforces compliance with coding guidelines. Being the one who establishes coding guidelines, the technical architect is the most likely to recognize when the guidelines are not being followed and is therefore the logical choice to enforce them. A project manager, who typically is charged with enforcement tasks, often does not have the technical experience to recognize compliance.
Code reviews are an excellent enforcement mechanism. It is much harder for individual developers to privately skirt team coding standards if other team members examine the code.
Code reviews are also an excellent learning tool for all members of the development team. The technical architect discovers holes in the design, and all participants learn tips and tricks from the rest of the team. Typically the most experienced member of the team, the technical architect often facilitates the code review. To be most useful, a code review should be held in a congenial, nonthreatening atmosphere.
The technical architect assists the project manager in estimating project costs and benefits for management. Although this is usually the project manager's responsibility, most project managers are less experienced with J2EE technologies and may not be aware of everything that needs to be done.
The technical architect assists management in making personnel decisions for developer positions. While personnel decisions are often viewed as a management function, the technical architect is in a good position to assess technical competence. Mistakes in personnel decisions can cause considerable damage to project timelines.
The project manager is responsible for coordinating and scheduling all tasks for all members of the project development team. The project manager must also communicate current project activities and status to management and end-user representatives. Further, the project manager acquires any resources or materials needed by the project or the team members.
The technical architect is responsible for providing technical advice and guidance to the project manager. The technical architect assists the project manager in identifying project tasks and the order in which they should be completed. The architect also helps the project manager identify needed materials and resources, including guiding the selection of other team members and validating their skill sets from a technical standpoint.
The business analyst is responsible for working with end users to define the application requirements—the detail necessary to design and build the application. Because end users and developers often use different terminology, the business analyst is responsible for translating communications between end users and developers. Often the business analyst has experience on both the end-user side of the enterprise and the information technology side.
As a project progresses, the business analyst's role diminishes but does not disappear. Developers typically have additional business questions that come to light during coding and testing activities. The business analyst works with the business side to get these questions answered.
The technical architect is responsible for ensuring that the application requirements determined by the business analyst are adequate. It's unreasonable to expect 100 percent of the analysis to be complete and correct. After all, analysis is to some extent subjective. However, the analysis needs to be complete enough to warrant proceeding with design.
Many applications, especially those that are publicly available, need professional graphics or layout designers. Most technical architects, left to their own devices, can produce functional Web pages, but those pages typically are ugly and hard to use. Graphics design is more art than science. Usually, the layout designer works primarily with the business analyst and other representatives of the business side to work out the design. But the layout designer may also work with the presentation-tier developer to create a prototype.
The technical architect is responsible for ensuring that the layout is technically feasible. I've seen many Web page designs that use text effects that are available in word processors but are not supported by HTML—for example, a design using text rotated 90 degrees. The architect is in a position to catch and correct these kinds of problems early.
The presentation-tier developer is responsible for coding all HTML, Javascript, applet/Swing code, JSPs, and/or servlets for an application. In general, anything directly involved in producing the user interface is in the purview of the presentation-tier developer. Typically in collaboration with the layout designer, the presentation-tier developer builds the prototype and develops the working version. And with the technical architect, the presentation-tier developer determines the structure and design of front-end navigation.
The technical architect is responsible for ensuring that design patterns can be maintained and extended. Navigation issues are often complex and can easily degrade into hard-to-maintain code. The technical architect is in a good position to identify and correct maintenance issues as well as other technical problems that arise.
The business logic developer is responsible for coding all invisible parts of the application, including enterprise beans, Web services, RMI services, CORBA services, business objects, and data access objects. Some people refer to these invisible parts as the server-side components of the application. The business logic developer is often a Java specialist who works closely with the technical architect and assists in performance tuning as needed.
The technical architect provides guidance for the business logic developer. It's common for technical issues and problems to arise in server-side components, which are usually the most complex pieces of an application. Thus the technical architect often acts as a mentor to the business logic developer.
The data modeler uses information from the business analyst to identify, define, and catalog all data the application stores in a database. Data modeling typically involves documenting application data in entity-relationship (ER) diagrams. The database administrators then uses the ER diagrams to produce a physical database design. Thus it is common for the roles of data modeler and database administrator to be combined.
The technical architect is responsible for ensuring that the data model is adequate. As with business analysis, it's unreasonable to expect the data model to be 100 percent complete. If the data model is largely complete and in third normal form, future changes in the model (and thus the database) are likely to be minor.
The database administrator is responsible for formulating a database design based on the business requirements for the application and for creating and maintaining database environments for the application. Typically, the database administrator assists with performance tuning and helps the business logic developer diagnose application development issues regarding data access. Sometimes, the database administrator doubles as a business logic developer or data migration specialist.
The technical architect works with the database administrator to resolve any issues or problems involving database storage. However, the database administrator primarily interacts with the data modeler and the business logic developer.
Some applications, such as those for data warehousing, depend heavily on data migrated from other sources. The data migration specialist writes and manages all scripts and programs needed to populate the application databases on an ongoing basis. When an application has few migration requirements, this role may not be necessary or may merge with the database administrator's role.
The technical architect defines data migration requirements for the migration specialist. Working with the data migration specialist to solve any technical issues or problems that might arise is another aspect of the technical architect's role.
The infrastructure specialist is responsible for providing all development, testing, and production environments as well as the deployment methods. A formal infrastructure for development and deployment saves time and effort. The idiosyncrasies involved in administrating containers, writing deployment scripts, and assisting with other developers diagnosing problems with their test environments represent a unique and challenging problem set.
The technical architect defines infrastructure requirements for the infrastructure specialist. The architect works with the specialist to determine the number and nature of the environments needed and what level of support is required for each environment. Many projects need at least one development, testing, and production environment. Some organizations combine the role of infrastructure specialist with that of technical architect.
A testing specialist is typically a detail-oriented person who makes sure that the application produced matches the specification and is reasonably free of bugs. Typically, a testing specialist has at least a basic knowledge of the business area.
The technical architect works with testing staff to identify any infrastructure requirements and support needed. The project manager and the business analyst usually establish the content of test plans and the testing methodology. Therefore, the architect's role in testing is usually support.