- 1 Introduction
- 2 Key Issues
- 3 Key Problems
- 4 Building the Business Case
- 5 Conclusion
5.3 Key Problems
It is one thing to develop a business case for components. It is another to actually obtain the value you hope to achieve. Because most business cases require that you identify areas of risk, it is worthwhile to review key problem areas. Knowing the problems to face will help you develop good business cases and understand which battles you need to fight and when. The key question organizations need to answer is: "What will keep us from obtaining the value we desire from using components?" Evidence suggests that there are three areas that can cause significant problems.
Wrong culture
Wrong goals
Wrong purpose
5.3.1 Wrong Culture
The wrong culture is one that is not prepared to make good use of components. This is not simply a matter of being ready or not. Just as there are different levels of components, each of these levels requires a corresponding change to the development culture to take advantage of them.
Does the following describe your culture? There was a ditch digger who had the job of digging a particular ditch by 6:00 PM. 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 pulls up with a backhoe and asks the digger if he would like some help. The ditch digger tells the other man to go away and not bother him because "I've got to get the ditch dug by 6:00 PM."
Some cultures can be narrowly focused. Because of time or cost pressures they feel they can't take the time to consider alternatives to how they 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 to bring in new technology or they bring it in by stealth and declare victory when they've accomplished their goal. The latter approach carries great risk. If the effort fails it may damage the reputation of the technology. It may no longer be possible to bring in the technology by other means. Either way, moving to a new technology in this environment can be a real challenge.
Another organizational problem is the 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. The organization may not be inclined to make the move because of the investment required. Even if you make the case for a good return on investment, budgetary constraints may derail the project. The business may have other high priority projects that consume all available resources and funding, leaving none for your component project. One approach to this problem is to deploy new technology on a small scale before deploying it across the enterprise. However, some pieces of hardware and software infrastructure are so expensive that a small-scale deployment makes little sense.
Reuse can deliver great value to an organization, but organizations 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. I find that most organizational processes fail to have any allowance for either creating or using reusable components. You also need someone to support commonly reused components. That means establishing some type of reuse center. Corporate culture can also inhibit reuse. I know of a company that rewards its developers based on the amount of code they write. This company will never achieve significant reuse while it rewards the exact opposite behavior. People will work according to how they are measured and rewarded. You need to ensure that your performance measures and goals don't hinder the change you are trying to accomplish.
5.3.2 Wrong Goals
When you build reusable components you are building for the future. You try to envision not only today's needs, but also how your components may be used in the future. What if you get it wrong? This could happen in different ways. You simply may not anticipate some usage of a component. This is not unusual. Developers will often try to use components in ways their designers never imagined, and you may be unpleasantly surprised by the results. For example, you may have designed a component that is incredibly flexible and has a correspondingly reduced performance. What happens when someone wants to reuse it but needs high performance within narrow constraints? Your component may not be the right one to use even if the functionality is correct. A developer considers many factors when determining if a component is a good fit for a particular application.
Another area where goals can be wrong is when the component is well-designed but the business needs change. When you design a reusable component you make some assumptions about the nature of a domain and processes that will work in it. In today's economy it's not unusual to have your assumptions challenged and discarded. Businesses change processes and models to meet the changing demands of their customers. Some businesses even change the type of business they are in. This is one reason it is so difficult to build good domain components. You're betting that your assumptions about the future of a business are correct and that's not always a good bet. This is also the reason it's easier to gain value from service components. While your business may change, your need to access a database probably won't. In dynamic markets infrastructure services may remain more stable than the domains they serve.
5.3.3 Wrong Purpose
Closely related to the issue of wrong goals is the problem of wrong purpose. For example, service components and domain components are different from each other. They have a different scope and purpose. They have differing needs in terms of infrastructure support and developer skill sets. You cannot use the same component for both purposes. This happens when analysts have poorly abstracted their components and mixed types of functionality. Good analysis and design can overcome this problem.