Final exam

Question 1: Component software

"Component software" refers to unbundled software modules that perform some function common to many software applications (such as editing or graphical-user-interface widgets) and that are licensed to application software vendors to incorporate into their products. Suppose you are starting a company to develop and market software components programmed in Java (perhaps to be used in applications for the network computer). Outline the obstacles to success that you anticipate, within the scope of issues covered in the course, and how you might overcome those obstacles.

From Eshwar Belani <belani@CS.Berkeley.EDU>:

Building better software in less time is the goal of every IS shop. Every significant advance in software development, whatever its source, aims at that goal. Component-based development means assembling applications from components: reusable, executable packages of software that provide their services through well-defined interfaces.

However, no matter how many benefits a new model has to offer, if there are errors made in its introduction and deployment, it will not succeed. We highlight some of the obstacles facing the industry as a whole (macro) and from each individual firm's point of view too(micro). We then provide tools, techniques and strategies to overcome these obstacles.

Obstacles

1. Too Many Standards

There are several technologies which can be used to develop components. Among them include - Microsoft's DCOM based on Active X, Sun's Java Beans, IBM's OpenDoc, OMG's CORBA, Iona's Orbix, Digital's ObjectBroker, Expersoft's XShell, and HP's ORB Plus. It is hard for a vendor to choose which standard to adopt. Moreover, it's expensive to keep developers up to date on tools and training for all the different technologies. A vendor can choose the cheaper path of waiting to see which way the industry goes. However, watching and waiting could be the most dangerous option of all, since component technology moves so quickly. Those who choose to stand still now could find that it's almost impossible to catch up later.

2. Choosing the right component model

Components can be standalone or in-process (need a container app). Moreover, they may run on either the client or the server. Choosing a component model is a critical decision as it determines which pool of components you'll be able to select from, what tools you can use to assemble applications using components, and how you'll create your own components.

3. Immature technology

Java beans is only evolving. ActiveX has security problems in heterogenous networks. Component technology is still an active research area and based on interface standards which usually have shorter life expectancies than the standards setting process.

4. Reorganization of development teams needed

The traditional approach of building software applications using designers and developers is not conducive. New roles and responsibilities have to be created to fully harness the new model.

5. No established sales and distribution strategies

There is no satisfactory answer as to what the sales and distribution channels will be.

6. No pricing model

There is confusion about how to price the components. Using a scheme the market is not used to (example: pay-per-use) when alternatives exist could have repercussions. It is not clear what scheme(s) will be most compatible with the differing market objectives.

7. Integration and Testing is a nightmare

Integrating components from different sources developed in different environments and testing the final product is a nightmare for application developers. Part of the reason is because components are not tested across a wide range of platforms.

8. Hard to get everyone to changeover from legacy techniques

There is a huge switching cost involved when developers change over from using legacy means for reusing code (libraries, object oriented technology). App developers have to begin thinking of designing apps in terms of components. Moreover, the learning curves associated with the component technologies can get pretty steep.

Overcoming the obstacles

1. The Current Dominant Component Model: ActiveX's COM

ActiveX controls are the best fit for Windows, and Windows dominates the desktop. OpenDoc has not had success, Java beans are still evolving and are not portable when one takes full advantage of the local OS. Moreover, Microsoft has a large headstart in components. As a generic component vendor I would bet on ActiveX for the short term.

2. Use Java beans for Web based apps.

Any serious web app will have significant client-side processing. A component vendor focussing on such apps is better off with Java beans because of the security and portability features. With the rapid growth predicted in NCs and emergence of the wired consumer era, the market for these components is set to rise exponentially.

3. Invest in R&D

NIST pumped in $150 million for research into component technology which express program requirements in terms of radically new languages rather than interfaces. Also, we need software architectures which allow for interoperability between component technologies.

4. Dismantle existing software development structures

New application development teams will need to consist of application architects, component provisioners and component assemblers. Architects take the place of designers, component provisioners develop the components, knowing in detail how components operate with each other. Component assemblers stitch the components together for the finished product.

5. Emergence of clearinghouses and repositories

Rather than being just storage spots, new open architectures allow repositories to act as a hub or "supergroup", linking a variety of different tools and disparate components into a single, common information management infrastructure. In addition, they provide catalogs for components, support electronic ordering and distribution through the web, and handle licensing issues. A component vendor must make sure to get his components listed at such repositories.

6. Pricing: Flexibility will be a critical success factor

Several schemes exist for pricing - server-only pricing, per-user pricing (more administration overhead), software rentals (ie download a rented app), subscription pricing, one-time licensing etc. As the market is evolving pricing schemes will be determined only through trial and error, and flexibility on part of the vendors will be key until a solid business model arises.

7. New modeling tools focussed on component based development

Successful component-based development of sophisticated applications requires an effective application architecture, the proper controlled iterative development approach, and high-quality testing. Modeling tools can be an effective means of understanding the problem and arriving at the correct solution. These tools thus facilitate the design and development of apps through the use of components.

8. Intelligent assemblies of hierarchies of components

In computer hardware, the hierarchy is chips, then boards, then systems. Similarly, the key to the power of software components lies in large-scale integration and reuse, not solely with the individual components themselves. Components composed of other components allow thinking about problems at the appropriate level of abstraction and this helps solve the integration and testing difficulties.

From Chris Rigatuso <rigatuso@haas.berkeley.edu>:

Trust: Compared to competition, what is our reputation? What evidence in the market is it based on? Does our offering address the key concerns that decision makers are likely to have when considering a purchase of our products? The issue of trust is compounded by our several choices for initial target segments: application vendors, database vendors, home users, business users. We should concentrate on early adoptors with the most technical knowledge and independence, and the least relience on brand-name recognition.

Core assets: What does our firm have that otherís cannot obtain? How long might that advantage last? The industry has low barriers to entry now, in part because there is no established leader in the Java components industry. In fact, its a segment of the software market, its not yet an industry!

Key requirement: Actual reusability: target userís level of knowledge and ability. How much effort will be expected? How much will be expended to create component based software?

Distribution system Because the cost of the components (marginal cost) will be about zero, the last thing we want to do is get into a price war with potential new competitors. Because of this, the cost of delivery, service, and the customerís total cost of ownership will be key elements in our strategy. One possibility would be to use the web as a two-way distribution network, components are exchanged for test results, and feedback forms, and future requirements specifications.

Portability/Compatibility: What platforms are key? Are there Java features that work better on different platforms (eg. Netscape Navigator versus Internet Explorer). What is the technology rate of change that may obsolete decisions based on different effectivity of different platforms?

Vision of convergence important in establishing solid distribution system: In the future, components will encompass both software code, data, and content (any mediatype). The distribution system does not really care what is inside, it cares only about security, payment, destination, and perhaps speed or throughput. The requests could originate in the application, as in the Marimba "Castanet" model, or be chosen by the source (firm which provides the component). Any distribution system selected must see the importance and possible ubiquity of such a distribution system, and align with the forces destined to own this system. See http://www.marimba.com/datasheets/castanet-ds.html

Complementary products: Integrated support for best tools and methodologies. A "technology web" of and services, including consulting should be available. This also will be part of the strategy of the firm, and will require a lot of attention and funding especially in the early years and first product launches.

Versioning: Levels of support should determine pricing, since the code is easily copied and shared.

Bundling with Tool vendors: Various development environments should be targetted as the premier source of deploying the Java component libraries. Clearly testing and productivity in those environments is key to success.

Understanding and conveying your customerís success involves a thorough understanding of the patterns of problems, and work arounds that occur among customer groups. Having staff from these areas is very powerful, and spending time with them observing and interacting with daily work process is very useful. The results will influence these critical knowledge bases within the company:

Improved product design: taking into account usage patterns across time, components, and applications

Improved benefit communication: knowledge that sales and marketing can use to close deals. This may result in white papers, financial impact studies, and actual customer case histories. Also the benefit of easier versioning of customersí products (by packaging with different components, and disabling or enabling them) could lead to greater use.

Improved process design: new ways of implementing applications based on the components available, the tools available, and the distribution system available. This too will influence future purchase and bundling decisions. These new processes may affect the publication of new white papers, new partnerships, and the evolution of the technology web.

Indirect network externalities: what other products and services can drive the demand for component based solutions? Changing computing paradigms? Tools in use today that allow component based systems to be designed or implemented?

Switching costs: to what extent are substitute tools and components in place? What are their strengths and weaknesses? To overcome switching costs, we may need to subsidize the key early adoptors.

Compatibility: inward compatibility relates to the conventions and interface style across our components. This is important in that influences productivity of our customers. Outward compatibility: interfaces to standard external systems is critical in meeting demands. Database interfaces (ODBC, SQL) are examples. Tracking the set of evolving standards that will be necessary to interface Java components to other systems.

Consortia: OMG interaction would be beneficial since there is accumulated requirements for interoperation, resuse, and available tools available through OMG and its member companies. Tracking of changes, demands, both met and unmet will be important for the firm. It will not be as important as informal collaboration through partnerships with tool vendors, consultants, and systems integrators which will contain much of the leading technology knowledge to win contracts and build viable solutions. As standards emerge, such as security, digital cash, digital video, and voice transmission, it will be important to provide leading time to market, to prevent being unseated by competitors.

Key Idea: Developing lock-in through loyalty: A third party distribution system could take advantage of derived classes and potentially even applications from the users of our Java components. This would provide an increasing returns model, since our customers could share profits with us, and thus we can lock them in for increased loyalty. In this low-barrier-to-entry industry, the feedback loop of providing a distribution channel that they can share also, provides a sustainable competitive advantage. Heavy interaction with users will help ensure a rapid convergence on easy-to-use interfaces and minimize bugs.

This idea coupled with extensive bundling: both within firm (packages of components) and across firms (bundling with distribution, design, and communication infrastructure products) allows a huge possibility for generating profits, by meeting individual needs of various customers (mass customization, segments of one).