Columns

Challenges to Component Technology Success

• By John D. Williams
• January 1, 1900

In my last two columns, I described the issues surrounding the business case for components. I talked about the importance of understanding business goals and the component life cycle. I also discussed the roles of organizational readiness, infrastructure support and reuse as key success factors. While all of these things are important, I cannot neglect to mention the risks and challenges users face when trying to use component technology successfully.

While you can develop a business case for components, it is another matter to actually obtain the value you want to achieve. There are many reasons the expected value may not be achieved: poor planning, shifting business conditions or a change in the basis used for your assumptions. The chance of any of these happening is the risk users take when moving forward with any technology. Most business cases require users to identify areas of risk and to define ways to mitigate such risk. Accordingly, it is worth taking the time to look at these areas of component technology.

Understanding the risks you face not only helps you to develop a good business case, it lets you understand which battles you need to fight. Identifying risk in your organization depends on the answer to one important question: "What will keep us from obtaining the value we desire when using components?" Evidence suggests there are three areas that can cause significant problems: wrong culture, wrong goals and wrong purpose.

Wrong Culture

When discussing a wrong culture, we are not judging its correctness, only its readiness for component technology. For our purposes, a wrong culture is one that is not prepared to make good use of components. However, this is not simply a matter of saying you are ready to use components or not. In order to take advantage of the different levels of components, there must be a corresponding change in the development culture.

Consider the following anecdote, which may describe the culture at your company. There was once a ditchdigger who was given the job of digging a particular ditch by 6:00 p.m. It was a challenging task, but he figured if he worked hard all day, he just might get the job done. He had been working for about two hours when a fellow pulled up with a backhoe and asked him if he would like some help. The ditchdigger told the man to go away; he had to finish digging the ditch by 6:00 p.m. and didn't have time to talk.

As our little story shows, some cultures can be narrowly focused. Because of time or cost pressures, they feel they cannot take the time to consider alternatives to the way they currently work. A narrow focus is understandable, but organizations often do themselves a disservice by not considering alternatives to current practices. Developers usually approach this problem in one of two ways. They either wait for a brief respite before bringing in new technology, or they bring it in by stealth and declare victory once they have accomplished their goal. Either way, moving to a new technology in this type of environment can be a real challenge.

The stealth mode of technology adoption has its own risks, however. What happens if this back door, under-funded and unsupported approach fails? It often means that the technology will not get another chance. Successful stealth programs require both support and protection to succeed. It may be at a low level, but it must exist. One-man heroics rarely carry the day.

Another organizational problem is a lack of infrastructure for the level of technology you want to use. This is most often seen when moving to more advanced levels of component usage. Organizations may not be inclined to make this move because of the investment required. Even if you make the case for a good return on investment, budgetary constraints may make it a moot point. For example, business conditions may require that resources be focused on certain projects, leaving none for rolling out new technology. One approach is to deploy new technology on a small scale before rolling it out to the enterprise. However, some pieces of infrastructure are so expensive that a small-scale rollout makes little sense.

And while reuse can deliver great value to an organization, companies often have to change both their processes and structure to take full advantage of it. Developing truly reusable components is hard work and requires a software engineering process to do it well. Furthermore, you often need to modify your development process to include reuse. Most processes I have seen do not make any allowance for either creating or using reusable components. In addition, you need someone to support commonly reused components. This means establishing some type of reuse center.

Yet a corporate culture can also undermine reuse. I know of a company that rewards its developers based on the amount of code they write. The more they write, the greater their reward. That company won't have reuse as long as the "more is better" reward structure is in place. Companies that succeed at reuse have a culture, as well as a reward structure to support it.

Wrong Goals

When building reusable components, you must envision not only today's needs, but how your components may be used in the future. What if you get it wrong? You may simply not anticipate a particular usage of a component. This is not unusual. Developers will often try to use components in ways that the components' designers never imagined. The problem with this is that you may be unpleasantly surprised by the results. Good documentation and a focus on black-box reuse can help.

Even if your component has the functionality you need, there may be a mismatch in system engineering goals. For example, you may have designed a component for great flexibility — a worthy goal. What happens, though, when someone wants to reuse it but needs high performance within narrow constraints? In this case, your component may not be the right one to use even if the functionality is there. Many factors go into determining whether a component is a good fit for a particular application. Good component documentation helps characterize engineering constraints and fitness for use.

Another area where goals can go wrong is when the component is well designed, but business needs change. When you design a reusable component, you usually make some assumptions about the nature of a domain and the processes that will work in it. In today's economy, however, it is not unusual to have your assumptions challenged and discarded. Businesses change their processes and models to meet the changing demands of customers. Some businesses even change the type of business they are in (I know; I worked in one). This is one reason it is so difficult to build good domain components. You are gambling that your assumptions about the future of a business are correct, and that is not always a good bet. Because the cost of developing domain components can be so high, firms find it cheaper to modify a generic model than to build one from scratch. This is part of the reason the ERP market has grown so much. This is also the reason it is easier to gain value from service components. While your business may change, your need to access a database probably will not. In dynamic markets, infrastructure services may remain more stable than the domains they serve.

Wrong Purpose

Closely related to the issue of wrong goals is the problem of wrong purpose. For example, service components and domain components each have a different scope and purpose. Because they have differing needs in terms of infrastructure support and developer skill sets, you should not use the same component for both purposes. I have seen this type of problem happen most frequently on small projects when analysts try to cram lots of functionality into a few components. For some reason, they think that having fewer components will make their system simpler; instead, they end up with poorly abstracted components that have mixed types of functionality. This quickly becomes a debugging, maintenance and reuse nightmare. Good analysis and design can overcome this problem. In this case, more classes can mean better abstraction, greater flexibility and higher quality.

The business case for components must address the risks we face. Understanding these risks also helps users to understand which battles they need to fight in their own organizations. In order to identify risk, however, we need to determine what will keep us from obtaining the value we want when using components. This will vary from organization to organization, but for many companies the key areas of wrong culture, wrong goals and wrong purpose are a good place to start.