Customer demand for increasingly sophisticated and integrated software solutions has led to large and sometimes unwieldy application packages, feature-laden but difficult to maintain and modify. Developing, maintaining, and upgrading these large, cumbersome applications can require a vast organization. The programs are difficult to create, expensive to maintain, and can take years to revise.
Upgrades or bug fixes in one such component of an application require the developer to release and the customer to buy a completely new version of the package. Some developers have added extension mechanisms to their packages to allow addition or replacement of certain components, but the extensions are proprietary, incompatible with other applications, and applicable to only certain parts of the package.
Because of the barriers put up by the current application architecture, users are often frustrated in attempting to perform common tasks:
OpenDoc addresses these issues by enabling the development of a new kind of application, one that provides advantages to both users and developers in the increasingly competitive software markets of today and the future. OpenDoc replaces the architecture of monolithic conventional applications in which a single software package is responsible for all its documents' contents, with an architecture of components, in which each software module edits its own content, no matter what document that content might be in. This is illustrated in Figure 1.
Figure 1. Monolithic Application Compared to Components
OpenDoc allows developers, large or small, to take a modular approach to development and maintenance. Its component-software architecture makes the design, development, testing, and marketing of integrated software packages far easier and more reliable. Developers can make incremental improvements to products without a complete revision cycle and can get those improvements to users far more rapidly than is possible today.
For developers, this is a radical shift in approach, although its implementation is not difficult. For users, this is only a minor shift in working style; its main effect is to remove the barriers to constructing and using complex documents imposed by conventional monolithic application architecture.
OpenDoc components allow users to assemble customized compound documents out of diverse types of data. They also support cross-platform sharing of information. They resolve user frustrations with conventional applications by removing the barriers listed earlier:
While providing all of these advantages, OpenDoc exists harmoniously
with existing monolithic applications;
the user need not abandon conventional applications in order to start
using OpenDoc.
Table 1
summarizes some of the principal advantages of the
OpenDoc approach to software for both users and developers.
For Users | For Software Engineering | For Software Marketing | For Small Development Teams | |
---|---|---|---|---|
Modularity | Can easily add or replace document parts | Can easily test and upgrade components; can reuse components | Can assemble packages with great flexibility | Can create components that work seamlessly with all others |
Small size | Less memory and disk space needed | Easier to design, code, debug, and test | Easier, cheaper distribution | Faster development and easier distribution of a component |
Multiple platforms | Documents travel across platforms so users can select familiar editors on each | Development effort on one platform can at times be leveraged to others | Opportunities for increased market share | Application of limited resources can at times be used across different platforms |
Scriptability and extensibility | Users have greater control over behavior of document parts | Increased ability for communication among parts | Better coordination among components in a package | Increased ability to communicate with other components |