In-Depth

Emerging Tools Fueling Escalation of Component Development

Component development model requires separate tools for phases of development life cycle; IT developers say holes filling quickly, but a comprehensive suite remains elusive.

There are few topics in IT organizations today that are likely to spark debate more quickly than the standing of software development tools. Many, if not most, developers are convinced that their favorite tools are the best, and rebuke colleagues who favor another toolset. Such debates are sure to continue as the tool business begins an apparent renaissance with the advance of IT development techniques to finally support the long-hyped component development model.

The effective development and deployment of component-based systems requires a broad range of tools. Because no single tool can cross all phases of component development, developers need to discover which tool is best for each function in a specific project. And beyond developers, whole firms must examine their need for tools and the ability of their people to use them effectively. Favoritism, experts say, can kill these projects.

An organization's tool needs are shaped by its business requirements, corporate application architecture, enterprise infrastructure and developer skill sets. With all of these factors, is it any wonder that no one tool can meet all needs? Fortunately, the marketplace today can provide developers with an environment rich in tools for all aspects of the development life cycle.

Challenges and trends

Without a doubt, developers are strong proponents of their favorite tools. They have invested much time and effort in building skills that make them productive using the single tool. Pressure to deliver software solutions rapidly drives developers to specialize in particular toolsets in order to gain the productivity demanded by their managers. One challenge of specialization is making both developers and the organization productive throughout the life cycle.

As developers narrow their tool focus, they are demanding broader functionality from tools so they can do more work in their preferred environment. While developers do not find it productive to become expert in the use of many different tools, they still have a wide variety of tasks they must accomplish.

New technologies and architectures are causing developers to create ever more complex systems. To meet this demand, developers want tools that can cover the gamut of development and deployment activities.

While tools are a significant factor in developer productivity, they cannot guarantee a successful component development project. A software engineering development process must first be im- plemented to provide a framework for component development success. Unfortunately, tool support for development processes is minimal to date. Experts note that the availability of tools that can au-tomate the development process would speed process adoption, and thus improve timeliness and software quality.

Tool suppliers are taking heed of the demand for such products, observers note. For example, several tool vendors have started building interactive development environments (IDEs) that are designed to handle complex, n-tiered architectures. One example of progress in this area is the growing use of wizards that automate some complex and tedious tasks. Some tool-makers are also promising to provide more integration with the various third-party technologies needed by n-tiered applications. These are all good steps toward providing a single platform for software development, though more is still required for most corporate component application development projects.

IT developers have for years discussed the tool requirements for component development, and for much of that time have said they are looking for a tool that is the equivalent of a Swiss Army knife. Such tools, these developers say, must have the flexibility to adapt to new — and rapidly changing — technologies and architectures. Many developers have started championing an emerging group of simple tool suites that are tightly integrated within a development and process framework. This type of framework is starting to emerge for component-based development.

Despite a lack of tools for some phases of the process, some companies are already having success with the new component architectures. For many, this means using Web and component-based architectures. Glenn Palmiere, CIO at G. Pierce Wood Memorial Hospital in Florida, noted that his company has been able to cut development time by 50% since it moved to a Web and component-based architecture. Palmiere also said the new efforts have greatly helped the hospital reduce its backlog of applications from 270 to 14. These are the kinds of results businesses demand from component development efforts.

While developers are focusing their efforts on finding tools for specific parts of the process, organizations are looking for a much broader product set. As the process of developing and delivering applications grows more complex, companies are looking to automate as much of the process as possible to improve productivity. Accordingly, they look for tools that will help them be effective in all phases of development. This means organi- zations have to manage more tools and develop more specialized skill sets. Companies can mitigate tool proliferation by restricting the number of tools they support for any given development phase. Communication and the integration of tools across the life cycle therefore become critical issues in helping organizations to deal with this complexity.

Rapid changes in technology can complicate matters for developers and vendors alike. Many of today's tools were born to support the creation of monolithic systems and, at times, these roots still show. Many of the tools were adapted for the client/server revolution, and then for distributed systems, by adding layers of complexity. Today, the need to extend support to the World Wide Web has created an environment in which tools cannot keep up with developers' needs. Technically incomplete tools, and tools that do not integrate well with others, tend to slow component technology adoption and deployment. Suppliers of these tools are scrambling to address the problems created by adding on to older technologies.

At the same time, the development skills of engineers charged with building these architectures often lag behind an organization's desired — and required — rate of change. To compensate for their lack of expertise in emerging technologies, developers need tools that can minimize some of the immediate requirements of new skill sets. Some operations have turned to wizards to immediately address the issue. Common Object Request Broker (CORBA) wizards, for example, can simplify the process of creating distributed applications, though developers are still forced to spend significant time filling in the gaps.

Tool considerations

Developing component-based systems calls for more from development tools than just writing lines of code. The entire life cycle, from system conception to deployment and maintenance, needs to be considered when selecting a toolset. This article has so far looked at component development trends from both a developer and an organizational perspective; now we will examine what these trends mean to each stage of the development life cycle.

Component development projects need to start with the selection of a software engineering process. Many users browse through a few books to help them define how the process will work. Others create and document their own processes. Organizations can get a running start by turning to process development tools. The available lineup includes the Rational Unified Process (RUP) from Rational Software Corp., Cupertino, Calif., and the Platinum Process Continuum Process Engineer from Computer Associates (CA) International Inc., Islandia, N.Y. Both tools are said to offer a compendium of best practices for component development processes.

The Rational Unified Process focuses on best practices for the developer. According to Per Kroll, Rational's group marketing manager for process and product management, RUP can provide developers with guidance in their day-to-day work. In addition to process guidance, RUP includes tool masters that help developers accomplish their tasks with Rational's suite of products. The best practices in this tool are not focused on project or process management.

CA's Platinum Process Continuum Process Engineer is a broader compendium of best practices. Its best practices address the process engineer and project manager, as well as the developer. Process Engineer is one tool in a suite of process and management tools.

Both of these tools face a challenge in integrating existing corporate development processes. For comprehensive tools such as Process Engineer, the integration requirements can be sizeable depending on the complexity of the process in place. IT development managers face similar issues with less-complex tools like RUP, but the scope of impact is narrower. While Rational does provide RUP with some integration with the firm's variety of tools, tight integration with a complete set of development tools does not yet exist for either product, observers say.

Development managers say there are no tools available yet that can automate development processes or provide them with workflow. Such tools could provide the framework required for component development, experts say.

In the area of analysis and design, today's tools tend to come in two flavors: requirements management and system modeling. While developers are generally more familiar with system modeling tools, requirements management tools can be a great help in both building and managing the building of systems. Several development industry insiders continue to express amazement at the number of developers who use neither requirements management nor system modeling tools. Requirements issues are the leading cause of design flaws, as well as projects being late or over budget. Additionally, clear documentation and communication of a system design can speed software development. Such tools can help users manage project scope and facilitate communication, and should be playing a key role in the rapid development of high-quality systems.

Rational's RequisitePro and Technology Builders' Caliber-RM are two tools for managing requirements. Requirements management tools are basically organized repositories for the requirements with links to relevant design artifacts. There are several advantages to using this type of tool. You can keep track of the scope of a system and manage "creep." You can also trace requirements to the design of the system to ensure that the required functionality has been implemented. Requirements tools can also work with testing systems to validate appropriate testing. These tools can help users understand the impact of requirements changes or sharing requirements across systems.

Like process tools, requirements tools often need to be configured to match an organization's processes. Each of these products can provide ties to modeling and testing systems. RequisitePro's Net Market edition is interesting because it comes with predefined requirements and analysis artifacts for e-commerce systems — a trend IT development managers say they hope will continue.

Rational has found significant success with its Rose modeling toolset. Together/J, from Raleigh, N.C.-based TogetherSoft Corp., is a similar tool that observers say has become somewhat successful among the ranks of Java developers. Select Enterprise from Princeton Softech, Princeton, N.J., is another modeling tool that supports a variety of development environments. The emergence of a de facto standard methodology has significantly boosted corporate interest in modeling, analysts say. In 1990, there were 50 different meth- odologies for modeling object-oriented systems. Today's tools show that most users have standardized on the Unified Modeling Language (UML), which was championed by Rational and is now controlled by the Object Management Group (OMG), Framingham, Mass., for component-based systems. The standard makes it easier for developers to communicate with one another, say managers. Tool selection now becomes a matter of how well a tool integrates with a corporate IDE and how easy it is to produce the type of artifacts the process requires. While all tools claim some level of round-trip engineering, not all tools are equal. Experts warn IT development managers to evaluate tools against the organization's particular requirements.

Development issues

No subject is likely to generate more heat than the selection of a corporate coding tool. There are so many on the market, it is impossible discuss each one here. Instead, this section will focus on the three main camps of component developers and their tools. The largest camp consists of developers who use the Microsoft development environments. Developers in the second camp use standalone IDEs, while the final camp contains developers who use integrated development and deployment environments. Each camp has its proponents and detractors.

Without a doubt, Visual Basic is the most popular IDE for building component-based systems in the world today. Among developers I polled, the consensus is that Microsoft makes easy things easy and intermediate projects not so hard. The VB object class browser, command completion and remote debugging are favorite features. While Visual Basic is much loved for its ease of use, experts say it does have its weaknesses, especially in enterprise development projects.

Developers who use standalone IDEs have the widest range of tools to choose from. Among the developers polled for this story, the more popular tools are IBM's VisualAge for Java, Inprise/Borland's Jbuilder and C++ Builder, and Visual Café (formerly owned by Symantec) from Cupertino, Calif.-based WebGain. One interesting move in this area is the porting of these tools to Linux. The Inprise/Borland Kylix project, which will port Delphi and C++ Builder to Linux, will help make RAD tools available to Linux aficionados. IBM's strong support for Java and other tools on Linux also bodes well for developers who want to use this platform. This developer camp also makes strong use of tools related to their IDEs. For example, many C++ developers consider Rational's Purify essential for high-quality development.

The third developer group uses toolsets that combine development and deployment environments. Popular toolsets include eBusiness Platform from SilverStream Software Inc., Burlington, Mass.; the eWave component-based e-commerce suite from Unify Corp., San Jose, Calif.; and the Forté line of tools from Sun Microsystems Inc. If the application under development fits within a tool's range of capability, developers will often find such tools very productive. Observers note that the capabilities of the tools are improving steadily and, at the same time, tools suppliers are adopting more industry and de facto standards. The latter trend should boost the use of such tools in the coming months, observers say.

While the focus of these tools is component technology, they must also support another major driver in development today — the World Wide Web. Almost every organization is moving to Web-based application architectures to shorten development time and reduce development costs. The trend is clearly having a major impact on what developers need to accomplish to develop capable applications. It is in this area that developers noticed the most gaps in component development tool capabilities and the needs of corporate developers. The most common complaint is the lack of tool integration between front-end Web development and other tiers of a system. For example, Dan Johnson, a developer with Raleigh, N.C.-based Carolina Power & Light, said he would like to see end-to-end debugging from either source or the execution en- vironment. Other developers said they would like to see tools with more built-in Internet support.

Another area where developers are finding gaps is in middle-tier development. Many server-side pieces of systems do not co-exist well with other server-side pieces. This can be true even with products from the same vendor. This can be caused by version compatibility issues or by overlapping functionality. With many tool vendors providing their own middleware pieces, compatibility has become critical to many organizations.

Many IT developers have identified additional gaps. Deployment and release engineering remains a mostly manual process for most organizations. The complexity of distributed Web architectures has only made the problem worse, as most tools handle only a portion of what is needed. The most commonly mentioned tools in this area are PVCS from Merant, Mountain View, Calif., Visual SourceSafe from Microsoft, and ClearCase from Rational. Roundtable, from Santa Ana, Calif.-based StarBase, is also worth a look.

Testing remains development's step-child in many organizations, even in complex component development projects. Several developers recounted the challenges they faced trying to get their organization to purchase testing tools. Those that bought testing tools purchased products such as Compuware's NuMega DevPartner Studio for unit testing, and Mercury Interactive's LoadRunner and WinRunner for application and load testing. Both companies provide test management capabilities. Other tools, such as Technology Builder's Caliber-RBT, can help tie requirements to testing.

Clearly, component development tools are growing in power, but advances in technology and architecture can be expected to continue to outstrip tool capabilities. For developers, tool integration remains a major, though mostly unsolved, issue. Lack of tool integration creates extra work and opportunities for mistakes. At the same time, many developers said they are quite happy with the tools they have and look at the gaps as opportunities to utilize new tools and technologies that can help them become even more productive.

Most   Popular