ColdFusion Article

Considerations in Developing ColdFusion Applications in Enterprise and Government Organizations

As Macromedia ColdFusion continues to mature, it is increasingly being used at the enterprise level of federal, state, and local governments. Obviously, when ColdFusion MX moved to the J2EE platform, it took a major step forward. The introduction of other complementary Macromedia enterprise class products, such as Macromedia Flex, and new features in the upcoming release of ColdFusion (Blackstone), such as reporting capabilities, enhanced printing, and enhanced ability to use gateway protocols beyond HTTP, also helps make ColdFusion a more viable option in enterprise and government organizations.

As more and more developers start building applications for these large organizations, the need to develop new skills increases. In this article, I discuss skill building and standards that ColdFusion teams should consider if they are creating ColdFusion applications within a government or enterprise organization. While few of these ideas are new or revolutionary to ColdFusion developers, they may be new to those developers who find themselves, for the first time, sitting at the larger enterprise table within a government agency.

An Overview of the Project

In the following article, I describe some of these issues our team encountered while working with the Nuclear Regulatory Commission (NRC) and other federal agencies both on the Department of Defense (DoD) and civilian sides. Several years ago, the NRC commissioned a Gartner study that recommended the agency standardize on ColdFusion as its preferred web application development scripting language and suggested the commission adopt a three-tier application architecture.

The study also recommended that the Commission build complete development, test, and production environments that teams would use to develop, test, and deploy applications. As federal, state, and local government move increasingly from single-machine deployments into enterprise-level deployments, in which multiple business units share solutions, such sets of environments become more common. These types of environments raise a whole host of issues that one ColdFusion developer, working for one department, does not usually face, such as:

• How to manage multiple development projects on a single machine
• How to deploy those projects
• How to maintain code across projects
• How to develop, validate, and encourage use of reusable components
• How to adopt coding and architecture standards
• How to coordinate use of agency data
• How to schedule simple and routine activities, such as upgrading or patching ColdFusion

In short, a development team needs to have a certain set of skills to interact with new or existing enterprise class environments. Like any other complex engineering system, enterprise web application development environments require management and oversight. Done right, they provide an excellent opportunity for an agency’s CIO to offer a very needed and important service to the rest of the agency: a flexible, scaleable and developer-friendly environment to work within.

Within the NRC, initial discussions made it obvious that there is a large pent-up demand for this kind of service: Many of the commission’s offices are engaged in their own development projects that could potentially benefit from a centrally managed, standardized environment.

The rest of this article describes some, but not all, of the issues and considerations common to federal government projects.

Standardizing Code

Once the NRC decided to standardize on ColdFusion, it needed to standardize coding practices. To accomplish this, the NRC issued a contract responsible for developing ColdFusion and general web standards. Standardizing coding conventions was the first task on the list. Fortunately, a set of ColdFusion coding conventions already exists and is maintained for the Macromedia Web Technology Group, available at:

www.livedocs.macromedia.com/wtg/public/coding_standards/contents.html/

We found that this was a great starting point for general ColdFusion conventions and adapted it as it was for the NRC. We added some localized database conventions, mostly to accommodate the existing conventions and procedures that in-house DBAs already used. Having to work through a DBA outside the development team can be a dramatic change for small development teams who are used to controlling their own database.

After addressing basic coding conventions, we addressed framework. Fusebox is one framework available; it has the advantage of being well known and well documented. But selecting the Fusebox framework involves a more detailed decision: Which version of Fusebox to use? We determined that for the NRC, Fusebox 4 and Mach II were too advanced for the average developer to start with. We used Fusebox 3 as the entry point for developers to come up to speed on Fusebox concepts, although more advanced developers used Fusebox 4.

Another alternative is to put together a set of common design patterns implemented as ColdFusion components (CFCs). Whichever framework you adopt, it is particularly important when working with the federal government to ensure it is well documented because:

• The federal government lives and dies on documentation. In some cases, documentation is even mandated by statutory or regulatory fiat. As covered later, this is not just developer or user documentation, but also includes documented business cases that justify the IT expenditure in the first place.
• Within the federal government it is not unusual for one team to develop an application and another to maintain it. When you try to move applications between teams, documentation becomes vital.
• Applications developed for one agency are often available for sharing with other agencies. In this case, the code you write may find its way to another part of the federal government. Although you as the developer won’t get paid twice, you may be called upon to integrate or extend your original work by any other agencies who want to use your original work.

The bottom line is that you must standardize and document the code and architecture. With ColdFusion components, documentation is much easier because of their ability to self-document. To leverage this, part of the coding conventions should require that developers include help attributes in all CFCs and methods.

Implementing Section 508 Standards

Section 508 is the law that mandates that the federal government purchase electronic and information technology that is accessible to those with disabilities. A great deal of information is available online about Section 508 and its implementation. A good place to start is:

www.section508.gov/

The official sources are not enough, however; it is common for agencies to have their own version of applying Section 508 standards. Usually, an agency has one or more Section 508 coordinators. It is important that you become well acquainted with the Section 508 coordinator(s) and spend the time to understand what they expect and what they will require for an application to pass Section 508 requirements.

In some cases, agencies determine that they will not enforce Section 508 compliance for web application administrative interfaces because doing so would be prohibitively expensive. With Macromedia’s growing support for Section 508, you may be able to help extend accessibility to the applications that were previously problematic.

Macromedia helps by putting a great deal of attention on Section 508 compatibility by building Section 508 features into its products. Macromedia Flash, for example, now has hooks to make it Section 508 compliant. And the ColdFusion administrator in ColdFusion MX 6.1 is Section 508 compliant. For additional information on ColdFusion and 508 accessibility, see:

www.macromedia.com/macromedia/accessibility/mx/cf/

Ensuring Privacy

The federal government is also constrained by regulations relating to privacy. Thus, most agencies likely have an assigned privacy officer responsible for overseeing and enforcing privacy regulations. ColdFusion developers might encounter these issues in ways that often don’t surface in the commercial world.

For example, we deployed a survey application in ColdFusion at the NRC. Just before launch, the privacy officer raised a concern about it tracking the users' IP addresses even though we were only using the IP address to lessen the chance that one person might post more than one response. Since the privacy officer considered it technically possible to trace the IP addresses back to individual workstations, we had to strip out the IP code at the last minute. This wasn’t a large problem, but you can avoid issues such as this by talking to the privacy officer in the planning stages so that you are aware, from the beginning of each project, of possible privacy constraints.

Additionally, the federal agencies we’ve worked with also prohibit permanent cookies. To work around this issue, we created code to ensure that our applications only use session cookies.

Standardizing Processes

While the previous topics relate mostly to developers' code, there is another level of standardization that applies to managing code and the code environment.

Typically, our team writes and unit tests code in one environment, moves it to a testing environment, and finally moves it to a production environment. But, it is also not unusual in departmental groups to find ColdFusion developers changing code on the production server. However, at the enterprise level, this is no longer possible. In fact, it is uncommon for a mere developer to even touch an enterprise production server.

This means that in the enterprise environment, you must develop processes for moving code through the development-testing-production environments.

Figure 1 (below) shows an early view of a high-level process for managing code developed at the NRC. This is conceptual; it does not mandate any particular toolset. In fact, the NRC uses the IBM Rational suite and this process has been refined and updated to take advantage of that toolset, but the basic concepts remain the same.

Source control becomes the center of the code universe and the entire process reinforces the clear separation between the development team, testers, and the administrators that oversee production.

Under this process the changes begin with a development team that builds and unit tests. The development team checks the code into source control with a “transition document” that describes the changes and gives instructions for installing and testing the code.

The testing team gets the updates form source control, runs the tests, and either sends the development team a message with the discovered bugs or confirms the changes and informs the production team. The testing team schedules the changes in a formal release and then moves them into the production environment.

Ideally, this process—or something similar—applies to both ColdFusion code and database updates. For this to work with the database, all database changes need to be scripted (usually using Data Definition Language).

This diagram (Figure 1) was created using a relatively new standard called Business Process Modeling Notation (BPMN), an emerging standard for modeling business processes. The specification for BPMN is available at: http://www.bpmn.org/ and is gaining support among tool vendors. This specification highlights another skill necessary for the enterprise ColdFusion team—business process design and modeling. Although another team is usually responsible for business process modeling in typical scenarios, it is important for the ColdFusion team to be, at the very least, conversant with it in enterprise and government environments.

Figure 1. The relationship between development team, testers, and the production environment

(+) View larger

Download full scale image (ZIP, 25K)

The Larger Process

Code and framework standardization are the nuts and bolts of development within the federal government. These activities are wrapped in large processes that control many aspects of how the organization funds and runs projects.

An agency-adopted Software Development Lifecycle Management Method (SDLCMM) governs most development within the federal government. This method defines the process for developing software, the required artifacts for gaining approval for software projects, and the detailed processes governing development.

Usually, the SDLCMM ties into the broader agency process for managing capital investments, called the Capital Planning & Investment Control (CPIC) process. Often the SDLCM and CPIC documents overlap somewhat, particularly when building the business case justification for a software application project.

ColdFusion as Glue

It has been said before that ColdFusion can serve as the glue that binds together different parts of an application, helping to connect multiple applications. This is particularly important when working in the federal government space because federal agencies frequently have a range of legacy technology in place. As we’ve seen at the NRC, this may include everything from Clipper applications to mainframe applications to departmental Access-based ticket tracking systems.

It is becoming increasingly important for agencies to be able to tie all this information together and present it in a unified interface, a role that ColdFusion excels at.

In fact, many agencies face the problem of how to move a mountain of legacy apps, created with older expensive technology, onto the web while updating them so they play together better. A key problem is how to pay for all the updates—or, more accurately, all the rewrites.

Most agencies are not in the position of being able to dedicate the funds or personnel to such a daunting task, despite the fact that they are being pushed to better integrate their applications.

ColdFusion can provide a viable solution to this problem. Instead of trying to re-write all the legacy applications, agencies can create ColdFusion components that serve as “wrappers” for existing applications to make the needed functionality available through web services. To do this most efficiently requires an overall enterprise architecture view, but it is possible to get benefits even with small scale projects.

The NRC is beginning to explore the idea of what we have termed an “enterprise service-oriented architecture” (ESOA), powered by web services exposed through ColdFusion components. ESOA is a concept that works for legacy applications whose data and functions are exposed through component wrappers as well as for new application development.

By addressing the problem of interoperability, the agency can then begin to convert legacy applications as priority, time, and budgets permit.

ColdFusion Addresses a Range of Skills

Most federal agencies do not develop software primarily. At a practical level, this means that if the agency has developers of its own, they are likely to have a wide range of skills: some are exceptional, but most are junior as development is not their primary job. Using ColdFusion and a standardized development framework such as Fusebox or object-oriented design, helps the team divide the work according to skill; this is a great advantage.

Technology Agnostic

Since passage of the Clinger-Cohen Act (wwwoirm.nih.gov/policy/itmra.html), federal agencies have focused more and more on standardizing technology. Over the long term, this might limit the number of technologies that federal agencies are authorized to use. Because ColdFusion MX is agnostic to the underlying application server and OS, it has a unique opportunity to remain relevant no matter which choice an agency makes.

It is important for enterprise ColdFusion developers to become familiar with Clinger-Cohen’s mandate for agencies to develop a formal enterprise architecture because agencies must tie their local enterprise architectures into the “reference models” that Federal Enterprise Architecture Program Management Office (FEAPMO - www.feapmo.gov) establishes. Those reference models describe:

• The business of government at a very high level
• The technology services that support that business
• The performance metrics that measure how well an agency accomplishes their business objectives
• The data models the agency uses to persist their data

While adopting reference models has not occurred overnight, it is a continuing concern for agencies as the Office of Management and Budget has begun to use the reference models to decide which projects will – and will not – be funded.

To legitimately play at the federal enterprise level, ColdFusion development teams must become familiar with the reference models and their impact.

In fact, ColdFusion ties in well to the reference models, in particular through the use of ColdFusion Components (CFCs) because the reference models encourage a service-oriented approach. By encapsulating functionality or entire applications into CFCs and exposing them through web services, ColdFusion developers can deliver service components that agencies can potentially reuse amongst themselves.

ColdFusion as Management Tool Environment

In addition to ColdFusion’s role in application development, it is a natural environment for developing tools and applications that support the overall development process. For example, when an agency builds a development-testing-production set of servers and has established the business rules for moving code through those environments, ColdFusion is a natural choice for automating the management of those processes. In other words, the agencies can use a ColdFusion application to help manage and track the development and deployment of other ColdFusion applications. For example, the NRC is exploring the possibility of using ColdFusion as a way to aggregate information from the various Rational tools—and other data repositories—into an integrated view to help developers manage their projects.

A very appealing possibility is to use ColdFusion to build tools to help users walk through the CPIC and SDLCMM documentation requirements. This would be a great help to users, would ease the support burden on the Office of the CIO, and would help to standardize and institutionalize the official NRC processes.

Conclusion

Enterprise ColdFusion seems to be increasingly an option in the federal government space. This represents a great opportunity for ColdFusion developers. To meet that opportunity, however, ColdFusion teams must add skills not always required when doing departmental or office development.

This article introduces some of the issues our team encountered in developing applications in the enterprise and government environment and how ColdFusion addresses those issues, it is by no means complete.

About the author