5.2 Key Issues
There are important issues you need to consider in your business case. These include business goals for the technology, technical sophistication, organizational readiness, infrastructure support, and reuse. These issues are not isolated from one another, but interrelated. Overlooking any of them can lead to failure in deploying component technology at the enterprise level.
5.2.1 Business Goals
Business goals help you understand when you should or should not use component technology. You should not immediately assume that components are the only way to solve your problem. HTML and JavaScript can support a simple Web site. Perl is perfectly adequate for many CGI and scripting needs. If your application is simple or not mission-critical, non-component based tools may be quicker or cheaper to use.
When should you use component technology? Components are the right answer for complex and mission-critical systems. They are robust, scalable, and flexible. These are critical factors for mission-critical systems. Many find that component technology often trades simplicity for scalability and flexibility. Anyone who has deployed an n-tier application will acknowledge that this is more challenging than deploying a client/server or monolithic application. Simply managing the increased number of software assets and multiple platforms makes it a more challenging task. This trade-off with simplicity is not always the case, but it is usually true for most medium to complex applications.
One problem is that the potential payback for components may be too low for a given application. Suppose your company is new to component technology and doesn't have the infrastructure or skills needed to deploy a moderately complex component application. You may not be able to justify the startup costs for the technology with that single application. Many organizations address this by identifying ways to distribute the costs and benefits across the enterprise. Unfortunately, this is not always possible.
Component technology can show real benefits if your organization calculates the total cost of ownership (TCO) of an application. A TCO viewpoint makes it possible to demonstrate the development and maintenance savings component technology can bring to an organization. We also know that development costs can be reduced through reuse. A component infrastructure can also reduce maintenance costs through its use of encapsulation, well-designed interfaces, and reuse. The scalability of component infrastructures avoids the need for expensive redesign and implementation.
Increased software quality is another reason to use components. I know of one organization that reduced application defects through the reuse of known good software. The effects were so dramatic that it found unit testing to be of little value and dropped it. Many companies give lip service to quality, but those who take it seriously, such as the one mentioned above, will want to adopt component technology.
Recognizing that using components is a business decision, how do we go about building a business case for components? One technique is to partition the business case by the level of technical sophistication of the components you want to use. Each level of sophistication has corresponding specifications on infrastructure, organizational readiness, and cost. By dividing a business case in this fashion, you can create incremental business cases to guide your organization in its use of component technology. This particular approach is useful in large organizations where the cost of wholesale component adoption is viewed as prohibitive.
5.2.2 Technical Sophistication—Not All Components Are Equal
Not all components are created equal. Components differ in complexity, scope, and level of functionality. They differ in the skill sets needed to use them and in the infrastructure they require. This differentiation among components makes it difficult to create a single business case for components. However, it provides a way to create a useful set of business cases. To create this set of cases we can divide components into three categories.
GUI components
Service components
Domain components
These categories let you divide the business case into models that differ based on complexity, cost, and organizational readiness. You will also find that each category has different productivity factors. Another benefit of this approach is that it lets you select the appropriate business case based on your company's environment and needs.
GUI components are the most prevalent type of component in the marketplace. GUI components encompass all the buttons, sliders, and other widgets used in building user interfaces for applications. Reusing such prebuilt components is fairly easy and has a quick payback. Building a robust GUI component requires a greater level of skill and commitment to component-based software engineering. I find it is rarely cost-effective to develop your own GUI components. In 1999 the market for GUI components was about $300 million. Most of these components were COM technology components, but the market for Java technology components is growing.
In the next category, service components provide access to common services needed by applications. These include database access, access to messaging and transaction services, and system integration services. One common characteristic of service components is that they all use additional infrastructure or systems to perform their functions. For example, you may wrap an existing system to create a service component that becomes a service to other applications. Service components also provide infrastructure support. Another common use of service components is to facilitate Enterprise Application Integration (EAI). You will find these components combined with other EAI tools such as message-oriented middleware (MOM), transaction servers, data transformation engines, and workflow systems. Since they don't provide the full functionality of these systems in themselves, these components are usually less complex than domain components but more sophisticated than GUI components.
Domain components are what most developers think of when they talk about business components. They may be reusable or not. Non-reusable domain components have an impact on an organization similar to service components, and you can use the same business case to justify them. In this chapter, however, I only consider domain components that are truly reusable. I call them domain components because truly reusable ones are often found only within a singular domain. For example, the domain components in an insurance application could include Bill, Policy, and Claim components. It is unlikely that they would find broad reuse outside of that domain. Reusable domain components are also difficult to design and build. They may have their own application context dependencies as part of an application infrastructure. They also require a high level of domain expertise to build and deploy. The business case for domain components builds on the technical sophistication required of both GUI and service components.
5.2.3 Organizational Readiness
One of the greatest challenges you will face in successfully using component technology is organizational readiness. Organizational readiness encompasses existing development processes, developer skill sets, and corporate culture. These areas are often overlooked in establishing business cases, yet it is here and not with technical issues that we spend much of our time. Consider the non-technical challenges you face in deploying a new technology. Who needs to say yes to your project? It isn't usually just the people funding it. How will you build a broad base of support for your project? Whom do you need to convince to adopt your technology? If you ignore these questions and focus only on technical issues, you will fail. One approach to answering these questions is to put together a communication and marketing plan that will help you sell the technology to those you want to adopt it. Refer also to Chapter 24, by Don Reifer, on reuse strategies.
Every organization believes it has a development process. I find, however, that most organizations' processes are less well-defined than they believe. You might be able to use GUI components in a haphazard fashion, but that approach won't work when using service and domain components. When building a component, an undisciplined process will cause you to fail. You can assess your organizational readiness most directly by evaluating the development process documented and followed by your organization. To gain the full benefits of component technology, you need a software engineering approach to development and deployment.
What kind of processes does your organization use? You don't need to use an excruciating and overblown process, but don't confuse "just enough" process with no process at all. By just enough process I mean you need a consistent and repeatable approach to engineering software. It doesn't have to be the most detailed process ever published. If you don't have a repeatable process, however, you don't have a process at all. Don't forget that the process must encompass everything from requirements elicitation and domain analysis to testing, configuration management, component management, and release engineering. All of these areas are affected by component technology.
A consulting organization generally helps companies new to component-based development (CBD) and CBSE to establish
A software engineering process
Measurement and metrics (to compare existing projects against a CBD project)
A training program for the organization on components and reuse
A training program for the software development organization on all aspects of component analysis, design, development, and testing, as well as detailed documentation
A mentoring program for a pilot project team on a small, but relatively important, software component project
A mentoring program for a larger project team on a longer, more complex software component project
A training program for the project teams that will routinely design, develop, and test for reuse
It is unlikely that one organization can provide all these services. Many consulting organizations might offer to provide them all, but no handbook for CBSE exists. Many approaches to all services are available; it is incumbent upon you to select the various consultants that can provide the services your organization needs. Expert trainers and mentors will make a positive impact on your project team without disturbing their current working equilibrium.
Once developers begin to acquire new skills you will find that you can't propagate them fast enough. This delay in developing deeply honed skills affects an organization in two ways. First, it slows the adoption of a technology because there just aren't enough skilled people to do all the potential work. Proper organization can minimize the number of people who need extensive skills. At the same time, an effective organization can use a wide variety of development talents. Proper training can enable developers to focus on specialized skill sets that let them become productive more quickly. Second, the payback and benefits of the technology are delayed. This is one area that needs serious attention in any technology business case. You must be careful not to be overly optimistic when forecasting the payback in using component technology. There is often a strong negative impact in using a new technology when promised rewards do not materialize.
Over the past two years there has been much discussion about the best way to organize component-based development. One of the early suggestions was to divide people into component builders and component assemblers. This certainly has some merit. This division of labor allows your most skilled developers to focus on the more complex task of component creation. Less skilled developers can work on the simpler task of assembling the components. It appeared to be a good idea, but it was not the solution early component managers anticipated. Assembling components can be a complex task, depending on the application layer you are working in.
An alternative to simply dividing people into builders and assemblers is to organize their skills by design layers for component infrastructures (refer to Chapter 15). A component infrastructure will typically be divided into four layers: GUI, Workflow and Process Control, Business Services, and Data Services. For example, the GUI layer can use less skilled staff to assemble simple GUI components while your more skilled developers focus on developing Workflow and Business Service components (together often called the middleware layer).
The middleware layer needs skilled developers for both component development and assembly. These are not the same skills. Component development at this layer is focused on business logic and the developer must be a skilled domain expert. Assembly at this level requires developers skilled in using application servers and other middleware components. The developers also need to be adept at defining and implementing interfaces to other layers. These skills are often tool-specific.
The Data Services layer needs people knowledgeable about databases and skilled in the development tools that will access them. These tools often provide a database access layer and require tool-specific knowledge. To produce efficient Data Services components, developers must have a working knowledge of databases, including query optimization and table layout.
Once you've designed the most appropriate organizational structure, you can focus on staffing and training. Fortunately, not everyone needs to be an experienced generalist. Instead of trying to give everyone the same skills, you can focus training in three areas—by layer, by process, and by tool. The proper organization will minimize the amount you need to spend on training in these areas.
5.2.4 Infrastructure Support
Infrastructure support becomes an important issue when you move beyond using simple GUI components. Any time you start using components in middle or lower layers of an n-tiered architecture, you need to think about infrastructure support. In a business case this becomes an issue when organizations consider 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 Java Beans (EJB) requires an application server to run. If you don't already have one in production, you need to consider what it will take to make it possible to deploy EJBs (refer to Chapter 33). You will need to set up development, testing, and production environments. You may need to acquire additional hardware servers, as well as multiple application servers. Then you must consider the costs and personnel support for the application server in production. You must also determine whether your existing technical support staff understands how to operate the application server, respond to its errors, or restart jobs with it. You will likely experience additional training costs or staffing needs just to manage middleware components. This isn't simply a matter of having the component development team support its work. Reusable components and component infrastructures may be used by many teams and require more central support.
5.2.5 Reuse
Reuse is something developers have talked about for years but have had great difficulty in achieving to a significant degree. Component technology strongly supports reuse and this can have a significant impact on your business case. Reuse also has costs associated with it. You need to consider both the savings and costs in your planning.
The productivity factors I use in my business cases are ultimately based on the productivity gained by reusing components. If we are developing complex systems we can gain an advantage simply by using a component-based approach, but we gain much more when we can reuse components. One reason for dividing the business case into three categories is because of the different reuse productivity factors experienced with each type. Companies that have implemented carefully planned reuse processes have seen millions of dollars in savings. Even the simple reuse of GUI components has positive payback. This wide range of values will be seen in the cost models.
Reuse programs can pay for themselves, but you cannot implement reuse without spending money to get it. You may purchase simple components or spend time and effort developing them. Their cost is relatively small and the payback is small. At the other extreme we have domain components that are serious business assets. Domain components usually have a high development or purchase cost. Developing domain components generally requires additional people, processes, and tools to initially manage the software component life cycle effectively. The cost is higher, but the payback can be substantial. Additionally, the initial component life cycle is longer than the traditional life cycle, but with reuse it decreases substantially. Either way, you must account for these costs in your business case.