1. Projects can leverage proven best practices.

2. Projects can be delivered with a greater degree of confidence, reducing risk and costs.

3. Risks involved in a project can be mitigated by employing accepted shared practices.

4. Technical competencies and skills can be developed through practicing consistent approaches.

However, most organizations fail to recognize these benefits. It is essential for organizations to possess internal communication mechanisms that can easily cross-fertilize information and promote best and worst practices across the spectrum of active IT projects. Two organizational frameworks that have proved invaluable in the support for enterprise J2EE software development efforts are Communities of Practices and Technical Centers of Excellence for J2EE Architecture.

Communities of Practice

Communities of Practice is a term used to define a forum of people, who can be extended across an organization, who share a common interest. Communities can exist for multiple topic areas, just like public user groups; the only difference being that their existence must contribute in some manner to the success of the organization.

In most organizations, J2EE solutions need to swiftly proceed from concept to prototype to production, and continue to evolve even after they are deployed. As a result, Communities of Practice need to be involved in developing the most practical, flexible, and efficient approaches for the J2EE software development efforts, especially in the areas that require business analysis, such as project inception and requirements gathering. Communities of Practice will derive best practices and techniques for assisting J2EE software development projects in a manner that will be supported and governed by the culture of an organization.

NOTE

In most cases, the best practical approach is the most culturally supported approach.

Communities can be technical and non-technical in nature. What is important is that they understand how they can contribute to the success of J2EE software solutions.

Non-Technical (End-User) Communities

This community represents the advocates for the end users within an organization, and primarily supports the Requirements and Analysis phases of a J2EE software development methodology. End users, just by the nature of their roles in an organization, do not typically have insight to how information systems are developed. Hence, they will not understand the activities or processes they will be involved in, or the implications of documenting or changing business processes.

This aspect of their interactions with IT projects always consumes their concentration over providing valuable information and knowledge to the business analysts. However, they are the primary information resources for nearly all IT projects.

Business analysts need to apply an investment in educating end-user communities on the Requirements and Analysis phases to ensure they understand the informational value they posses and how they can effectively articulate that information.

Such communities require sponsorship and need to be championed by a well- recognized and respected member of the end-user community. A strong marketing effort is also required to promote its existence, since there is no point in building a Community of Practice if no one knows it exists. It is extremely important for them to gain exposure and be utilized by the organization.

Technical Communities

Technical communities are more prevalent than the non-technical end-user communities within an organization, and are usually composed of representatives from an organization's technical workforce?technical architects, software developers, and testers.

These communities generally exist for technology platforms, development languages, and their respective integrated development environments. Hence, technical communities have established themselves as developing the suite of technology criteria for the deployment of successful information management systems within an organization.

Examples of the concentration of such communities include

1. Programming languages (Java, C++, and Visual Basic)

2. Databases (Oracle, Sybase, DB2, and SQL Server)

3. Technical vendors (Oracle, BEA, Microsoft, and IBM)

There should always be an entity that sets the technical directions and standards within the organization, but the technical community should not be that entity. The mission of technical communities is to develop how those technologies can best be applied or practiced, not by theory, white papers, or technical paraphernalia, but through actual hands-on experience.

By creating and sponsoring technical communities, organizations will over time develop consistent approaches to software development that will possess a high degree of quality and success.

Technical Centers of Excellence?The J2EE Architecture Group

A Center of Excellence is a formalized group of people who are focused on a specific technology or software platform which their organization utilizes in its software development efforts. Their roles are to be experts, practitioners, and mentors on the technology domains they represent. This group must also wear the business hat to continually monitor business drivers that affect them, as well as the areas within an organization that could potentially be affected by the technology they represent.

If your organization is going to transition its software development platform to one that employs the J2EE architecture, there will be an expectation, after the completion of the first few J2EE projects, that subsequent J2EE project efforts become more efficient through the reduction of time, cost, and risk. With major updates occurring to the J2EE architecture almost every six months, a Center of Excellence is the means to realize those goals.

The J2EE Architecture team must collectively define how they are going to publish their information and knowledge to the organization, to ensure that the J2EE value proposition is comprehendible. Hence, they will need to represent technical ideas and the business implications of J2EE solutions, without needing to explain the intricate underlying technology. Business leaders view technical architecture as a winning gamble?an investment today with the optimism it will reap huge benefits in the future.

NOTE

The J2EE Architecture team must learn to talk in relation to user implications, as all technical choices should ultimately be linked back to business strategies and drivers.

The work that the J2EE Architecture team conducts should be in a level of detail that can be achieved within a set timeframe, typically no longer than the duration of the next release of the J2EE specifications. The longer they take to establish compliance on how J2EE solutions should be implemented, the less productive their mission and existence becomes. The litmus test for how successful an organization is with a J2EE Architecture team can easily be measured by the number of projects that adopt J2EE as the platform for the solution and have a successful deployment.

J2EE Architectural Guidance to IT Projects

The biggest payoff of having a J2EE Center of Excellence within your organization is the ability for their members to get involved with J2EE projects right from the beginning, and ensure that a J2EE solution is valid and best suited for the solution domain. At a minimum, it should provide the appropriate technology guidance.

However, the biggest mistake that IT projects make in selecting a platform for their solution architecture is they see both the Requirements and Analysis phases of a software development lifecycle as the building blocks for producing the overall design of the system.

In reality, the role of the Requirements phase is to identify the functionality of the system, not how the functionality will be implemented. The Analysis phase, on the other hand, provides essential information contributing toward an understanding of the solution domain, and not what the solution system will look like?that is the role of the Design phase.

It is also important to note that an IT solution's architecture should not be confused with its design. The focus of the architecture is on how the system will be deployed, and not its granular implementation details. The architecture of a system should capture the elements of design, which provide a clear vision and guidance for the overall design of the system.

The J2EE Architecture Center of Excellence should ensure that when they get involved in projects, the due diligence for the technology solution does not take a J2EE bias. If J2EE is selected as the appropriate platform, they should provide an architectural blueprint for the following:

1. How the J2EE services can be implemented

2. How existing organizational J2EE business components, such as EJBs, JavaServer Pages, and Servlets, can be reused

3. How the system can evolve and scale over time, resisting any stress placed upon it by the business

4. How and who to hire for project augmentation

5. How newly created J2EE business components can be harvested into a central component library

Another area where the J2EE Center of Excellence will be very valuable is in systems integration. J2EE is a relatively new technology platform for most organizations. Although much of an organization's data will have been collected by existing applications, the value will not be in the replacement of these existing systems, but in how they can be interfaced into new J2EE solutions, hence commoditizing their value.

The term methodology is one of those terms that can mean different things to many people. In the context of developing software, however, there should be one simple interpretation?"A Methodology provides a methodical roadmap, framework, or guidance for developing software solutions derived from business needs."

The term Software Development Lifecycle (SDLC) sometimes gets confused with a methodology. The two terms are interrelated, but have different implications. A Software Development Lifecycle describes a defined set of phases or events that occur in the development of software solutions.

The Software Development Lifecycle has several distinct phases.

A methodology encapsulates an SDLC, and describes a general philosophy for developing the software solution, as well as what is expected from each of its phases in terms of inputs, outputs, and the respective coordination of any activities.

Methodologies are not technology-bound, and in essence, they cannot afford to be. Methodologies are engineered to be open frameworks that can apply to a variety of business and technical challenges. However, with the explosion of Web-based n-tiered applications, as represented by the BEA WebLogic Server 7.0 united with the J2EE platform, methodologies have become driven by the following three factors: