Preparing for Components

In last month's column, I introduced the key issues to be addressed in building a business case for components. I discussed the importance of understanding business goals and the value of looking at the entire life cycle of a component. I also showed that all components arenot created equal, and that the business case changes as the category of component changes. Three basic categories of components were identified: GUI components, service components and domain components. These are not the only potential categories for components, but they cover the range of issues users need to address when building a business case. This month, I want to highlight additional key issues for the component business case: organizational readiness, infrastructure support and reuse.

One of the greatest challenges to the successful use of component technology is organizational readiness. Organizational readiness includes existing development processes, developer skill sets and corporate culture. These areas are often overlooked in business cases, yet it is here and not with technical issues that we spend much of our time. For example, any time you want to roll out a new technology, you need to get buy-in from both developers and managers. This usually means you need to put together some sort of communication and marketing plan to sell the technology to those you want to adopt it. If you focus just on the technical issues, however, you will often fail because you have not taken the time to address organizational issues.

Every organization believes it has a development process, which may or may not be true. Most organizations actually have less process in place, rather than more. You might get away with using GUI components in a haphazard fashion, but that approach just won't work for service and domain components. It also won't work for building any type of component. A software engineering approach to development and deployment is required to gain the full benefits of component technology. You don't need to use an excruciating and overblown process, but don't confuse just enough process with no process at all.

The process will need to encompass everything from requirements gathering and domain analysis, to testing and release engineering. These areas are all affected by component technology. For example, the design and creation of high-quality components requires a process that embraces a good object-oriented methodology. While components do not need to be implemented as objects, the object-oriented principles of encapsulation, abstraction and inheritance can be very helpful in designing good components. Testing changes as you begin to reuse previously validated and tested components. A good process will help you understand where useful testing begins and ends. The delivery of n-tiered component systems is also different. Deploying different tiers to various platforms is a complex task. A good release engineering methodology will help you deploy applications smoothly.

Once developers acquire new skills, you'll find that you can't propagate them fast enough. But component-based systems are more complex than older client/server systems, so it takes longer to acquire skills that are both broad and deep. But gaining such skill and experience affects an organization in two ways. First, it slows the adoption of a technology. There just aren't enough skilled people available to do all the potential work. Second, the payback and benefits of the technology are delayed.

In my February column ["Challenges of component technology," p. 72], I addressed how you might best organize the skills of your developers for application development. I won't repeat that information here. Once you've figured out your organizational structure, you can focus on staffing and training. It is important to have a generalist on your staff, someone who can help you make decisions about how to deploy technology. But not everyone needs to be a deep generalist. Instead of trying to give everyone the same skills, focus training in three areas — by layer, by process and by tool.

There are other organizational inhibitors that need to be avoided. The first is the "will" problem. Some people will not change unless they are told to do so. There are many developers who would rather do what they know how to do than learn something new. Senior developers and architects with project leadership responsibilities may take this stance because they are more comfortable committing to something they know, rather than betting on something they have little or no experience with. The old "not invented here" syndrome can also kick in. Each organization has a few developers who believe that if they didn't think of an idea first it must not be worth much. The challenge in getting these people on board for component development is to help them believe it really was their idea.

Finally, one of the biggest challenges is who will pay. This is particularly true in the area of reuse. No one wants to pay the extra cost up front to develop truly reusable components. What is needed is an enterprise perspective. If a reusable component will benefit the enterprise, then it makes sense to fund its development. In practice, it is often a separate reuse center that has to pick up the cost of making a component reusable. They also become the ones to benefit financially from its reuse.

Infrastructure support

Infrastructure support becomes an important issue when you move beyond the use of simple components such as sliders and buttons. When you start using components in the middle or lower layers of an n-tiered architecture, you need to think about infrastructure support. For our business case, this becomes an issue for service or domain components. Any time a component needs to make use of middleware services, such as application servers, you need to consider the cost of the new middleware. For example, Enterprise JavaBeans (EJBs) require an application server to run. If there is not already one in production, then you need to consider what it will take to make it possible to deploy EJBs. You will need to set up development, testing and production environments. This may mean additional hardware servers, as well as multiple application servers. What about support for the application server in production? Do your operations people understand how to operate it, respond to errors or restart jobs with it? You may acquire additional training costs or require more staff to satisfy this issue.

The same issues can apply to existing software as well. How will the new combination of your reusable component and existing middleware be supported operationally? New combinations of software often raise support issues. This isn't simply a matter of an application development team supporting its work. Reusable components and architectures may be used by many teams and require more central support.


Reuse is something that developers have talked about for years, but have had great difficulty in achieving to a significant degree. While components are not the only reusable artifacts, component technology strongly supports reuse, which can have a significant impact on your business case. Reuse also has a financial factor associated with it. You therefore need to consider both the savings and costs in your planning.

The productivity factors used in the business case are ultimately based on the productivity gained by reusing components. If we are developing complex systems, we can gain some advantage simply by using a component-based approach; however, we gain much more when components are reused. One reason for dividing the business case into three types is the different reuse productivity factors associated with each type. Companies that have implemented well thought-out reuse processes have saved millions of dollars. Even the simple reuse of GUI components has positive payback. This range of value will be seen in cost models.

Reuse programs can pay for themselves, but you can't have reuse without spending some money to get it. Simple components may be purchased, or you can spend time and effort developing them. Their cost is relatively small and their payback is OK, but not spectacular. At the other extreme, we have domain components that are serious business assets. But you also need people, processes and tools to manage them effectively. While the overall cost is higher, the payback can be very great. Either way, you need to account for these costs in your business case.

Clearly, the business case for components is about more than technology. Organizational issues can have a significant impact on your ability to use and deploy different categories of components successfully. Next month, I will examine the different business cases for components. By creating different categories for our business cases, I will show you how to demonstrate success at simpler levels of component use and lay the groundwork for future success and justification.

About the Author

John D. Williams is a contributor to Application Development Trends. He is president of Blue Mountain Commerce, a Cary, N.C.-based consulting firm specializing in enterprise, domain and application architectures. He can be reached via e-mail at [email protected].