Component-based development has the potential to improve developer productivity, speed the development process, and result in the deployment of more flexible applications with a far higher level of quality. IT organizations have thoroughly embraced the concept of component-based development in order to take advantage of these benefits. Impressed with demonstrations of the productivity of component-based development, managers we meet are set to start buying component development tools, building components, snapping them together into applications, and rolling them out across the net.
Whoa! I donıt want to shut down anyoneıs component-based development party (an approach I have long advocated), but application managers must rethink their development process in light of components. Simply slapping together components and tossing the resulting applications to the users wonıt work for long. As soon as you need to build a component-based application that is large and complicated enough to require more than one or two developers or that will require frequent enhancements or modifications, you will face some serious problems.
By the time you reach the point where you need a second release of an application, youıll be unable to avoid the inherent complications of component-based development, no matter how lucky youıve been until that point. Consider upgrading a packaged application. For a period of time, both versions may need to exist while the functionality and data are migrated between versions.
For an IT manager, accurately tracking the inventory of components through all stages of design and development and managing the developersı use of components are major issues. Failure to solve these issues will seriously hinder the spread of component-based development and prevent organizations from fully realizing the benefits of this approach. It wonıt take long for these issues to become apparent; youıll see it as soon as an application has to be fixed or changed. The component may have been enhanced several times since the initial development, or maybe it simply canıt be found. The organization may not even be able to identify definitively the exact components of a particular build.
With so many different components and versions of components floating around, developers will have great difficulty assembling a seamless application. Fortunately, you donıt have to look far to solve the problem. The solution lies in configuration management, a development discipline thatıs been around for years.
Configuration management represents the grunt work of application development. It entails painstaking, continuous tracking of all the work done to the code and then tediously logging every change. It requires that application development managers impose constraints and discipline on the developers, which is never an easy task. But despite all the trouble, configuration management remains an extremely valuable discipline for managing both the development and maintenance of distributed systems. This is especially true for companies facing such challenges as component development and deployment, multiplatform development, shortened release cycles, accountability requirements, or geographically dispersed development teams.
Nobody likes doing this kind of work, but a new generation of configuration-management tools automates most of the laborious, painstaking, manual chores. These tools let the computer do what it does best: track the mundane yet important details so users can focus on adding value to the process instead of constantly performing tedious bookkeeping. Configuration management still imposes constraints and discipline on the developers, but the tools decrease the many opportunities for human error that exist in the development and maintenance life cycle. The gains far outweigh the costs.
Application development managers I work with are confused about configuration-management tools and the configuration-management tool market. The configuration-management tool market covers a broad spectrum of user requirements and product functionality, resulting in a perplexing set of choices when selecting a solution. Products that nominally compete may actually have very different value propositions that may appeal to organizations with very different requirements. To select the right tool, development managers not only have to understand the tools but also clearly understand their own configuration-management requirements. (See Figure 1.)
The spectrum of available configuration-management products ranges from developer-focused version-control tools (see the lower lefthand corner of Figure 1) to process-focused change-
management solutions (see the upper right corner of Figure 1). As long as organizations understand the differences among these configuration-management solutions, they can benefit from this wide range of options. All organizations have unique development and maintenance procedures and processes. As a result, no one configuration-management tool can fit all situations.
Within most client/server development projects, configuration management is usually regarded as simple version control ıcode check-in/check-out facilities that prevent developers from stepping on each otherıs work. Version control is the basic functionality around which most configuration-management tools are built. All version-control tools include version-management support as well as some level of support for things like workspace management, build management, and defect tracking.
For the most part, these tools incorporate a developer-focused view of the development process (see the lower left corner of Figure 1), which means they are implemented at the developer or project manager level. They are not designed to play a role in application deployment or system and application management. Therefore, they provide limited support, if any, for managing components. Also known as source-code management tools, version-control products range from Unix-based utilities such RCS and SCCS or Windows-based workgroup-level tools such as Microsoftıs Visual SourceSafe all the way to higher-end solutions that provide a more complete configuration-management environment, such as Intersolv Inc.ıs PVCS.
Mainframe products have long supported library-management functions (the mainframe equivalent of version control) and process- and change-management functionality. In client/server environments, however, application life-cycle support is far less mature, and the value of configuration management is only now beginning to expand beyond application development. IT organizations are demanding more comprehensive change-management solutions ı tools that help support the entire application life cycle, including development, deployment, and maintenance. Such support is crucial with the emergence of enterprisewide component-based development.
To meet this demand, configuration-management vendors are increasing their productsı level of support for functionality that was traditionally outside the scope of a configuration-management tool. This change-management support includes tighter links to software distribution products, help-desk functionality, and component and application versioning. Change-management solutions are at the other end of the configuration-management spectrum from version control tools. These solutions go beyond support for the coding process to help organizations manage deployment and maintenance of the application as well. Tools in this space include Team Connection from IBM, CCC/Harvest from Platinum Technology Inc., and TrueChange from True Software Inc.
Change-management support is crucial to the widespread acceptance and ultimate success of large-scale, distributed applications. The Internet and the rise of component-based development have combined to magnify the pain most IT organizations currently feel when they attempt to manage these distributed systems. Within this new paradigm, development projects are often shorter, involve more people, and impact more aspects of a companyıs operations. Integrated change-management support ıfrom code and component versioning to release management of Web content, application deployment, and integration with systems and application-management solutions ı can help ease the pain of building and deploying component-based applications. It can also help decrease the risks associated with distributed development and maintenance projects.
A word of caution, however: Change-management solutions are not for everyone. Most IT organizations are not in a position to define, let alone manage and control, their process for distributed life-cycle support. Unlike version-control tools, which are developer-centric, change-management solutions are usually implemented from an IT management perspective with more process-focused support for controlling and monitoring the development process or workflow. These solutions are well suited to organizations that demand strict development guidelines and management oversight, including highly regulated industries and production-oriented development environments in which existing applications are constantly updated. Organizations with separate departments responsible for application maintenance will also benefit because the change-management solution can provide a common technology infrastructure for facilitating communication and collaboration among different departments.
IT organizations have many options when choosing a configuration-management tool. However, before an organization can choose a product, it must consider the type of development process and structure it has in place, its level of application development and deployment maturity, and its specific product requirements, such as the Department of Defense or ISO 9000 compliance. Because configuration-management tools have different functionality and value propositions, no one tool will work in all environments. By understanding the focus and scope of the vendor, the implementation strategy required to leverage the productıs functionality, and the specific functionality the tool provides within the overall application life cycle, IT organizations can choose the most appropriate configuration-management tool for their specific requirements. Finally, organizations must also consider how their configuration-management needs will change over time, usually evolving toward increasingly sophisticated change-management requirements.
Configuration management isnıt glamorous, but it does the grunt work that will make it possible to develop, deploy, and maintain large-scale, component-based distributed systems successfully. With solid configuration-management support in place, youıll be far closer to realizing the benefits that component-based development can offer rather than living the nightmare of yet another incomplete development approach.