- Object-Oriented Technology
- Component-Oriented Technology
- Technology Ownership
- Client-Server Technology
- Internet Technology
- Architectural Layers and When to Use Them
- Software Application Experience
- Technology and Application Architecture
- Applying Standards to Application Systems
- Distributed Infrastructures
- Conclusions
- Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Technology Ownership
Because object technology is the dominant commercial paradigm, it is important to understand the major kinds of commercial technologies available for the architecture of software systems. The two major categories include proprietary software and open systems software.
Proprietary Software
Proprietary software is a non-standards-compliant product of a single vendor. That single vendor controls the form and function of the software through many iterations of product releases. When today's systems are built, they are dependent upon commercial software to varying degrees. Commercial software is the primary form of software reuse and in practice is a much more effective form of reuse within individual enterprises.
An economy of scale is one reason why commercial software is a more powerful form of reuse. Large numbers of copies of the software are distributed to customers, and the software can be debugged and quality controlled to a degree that exceeds the in-house development capabilities of even the largest end-user enterprises. When end-user enterprises depend upon proprietary software, they are dependent upon the vendors' continued support for existing capabilities, and architecturally many end-users depend upon future features that the vendors claim will be added to the software. When proprietary software is packaged in the form of a public specification or standard, the specification is usually a direct representation of that single software implementation.
Often, when proprietary specifications are put forward in the public domain, it is unlikely that the proprietary implementation will be modified. This leaves the impression that proprietary software can also be an open system standard, when in fact there is no possibility of modifying the underlying technologies. This phenomenon is especially true when millions of software licenses have been distributed and are running on existing software systems. When proprietary technology is put forward, vendors use unique interpretations of software concepts to describe their products. These interpretations can include fundamental modifications to object-oriented principles.
"We shape our buildings; thereafter they shape us."
—Sir Winston Spencer Churchill
The most significant aspect of proprietary technology is the provision of application program interfaces (APIs). The APIs to proprietary software define the boundary between a proprietary implementation and any value-added application software that either an independent software vendor or the end-user provides to build application systems. As proprietary software technologies evolve through multiple releases, the application program interfaces can change.
New capabilities are continuously added to proprietary software, and this exacerbates the complexity of application program interfaces. In many cases, the complexity of the program interfaces available with proprietary software greatly exceeds the functionality needs of end-user organizations. It then becomes appropriate for the end-user organizations to attempt to manage this complexity in various ways. Complexity-management concepts are covered in several chapters, most explicitly in Chapter 5.
In addition to adding new capabilities to proprietary program interfaces, vendors also on occasion may make obsolete their interfaces in software. Doing so can have a significant maintenance impact upon application software. As proprietary software evolves through multiple releases, it is important for users to continue to upgrade the software to remain in synchronization with the mainstream support activities from the proprietary vendor. When the end-users' systems fall behind more than two cycles, it is often necessary to repurchase and reintegrate completely the commercial software in order to synchronize with the currently released version. Many end-users have found that application program interfaces are almost completely obsolete within a few cycles of product release.
In summary, proprietary software releases and the evolution of the program interfaces become a treadmill for application programmers and independent software vendors to maintain synchronization with available and supported software. There is a conflict of interests between the application users and the proprietary software vendors because the majority of the vendors' profits can be driven by the sale of software upgrades.
Open Systems Software
The other major category of commercial software is open systems technologies (Figure 3.2). An open system technology is fundamentally different from a proprietary technology. In an open system technology, multiple vendors agree to develop a specification that is independent of proprietary implementations. This is the case of most formal standards activities and many consortium standards activities, which are becoming increasingly prevalent. In an open systems technology, the specification governs the behavior of the implementations.
)
Figure 3.2. (a) Proprietary Technology and (b) Open Systems Technology
One of the key benefits is a consistency of implementation interfaces across multiple vendors. Additional benefits include uniformity of terminology and software interfaces because the open systems technology requires multiple vendors to reach consensus. Another benefit is an increased level of technology specification and an extended life cycle. Because product developments are in parallel across multiple vendor organizations, the corresponding marketing activities that create the demand for the technology are also synchronized and coordinated. A key benefit of open systems technology is the interoperability that it provides between commercial software vendors. The distinction between open systems and proprietary technologies is particularly appropriate for object-oriented systems, which are becoming the mainstream of application development, as object technology is already the mainstream of commercial technology.
Commercial information technology is evolving. Additional capabilities that increasingly satisfy application needs are being added and are becoming available through commercial technology. However, there is also a significant amount of reinvention in commercial technology of fundamental capabilities such as operating systems and programming languages.
In some commercial technologies, such as office automation, word processors, and spreadsheets, a continual reorganization of functionality is presented to the end-user without significant extension of capabilities. In the view of many people, the rate of technology evolution on the commercial side is relatively slow in comparison to the growth in needs for competitive application developers. Commercial technology is put forth to satisfy the needs of large numbers of users. The generality of this software exceeds the need of any individual application user. In order to adapt commercial technologies to application needs, there is a requirement for software development and installation which customizes the commercial software to the needs of specific applications (Figure 3.3).
)
Figure 3.3. Commercial Software Customization
The requirement to customize commercial technology is often called profiling; this concept is covered in more detail in Chapter 5. In addition to the profiling software, substantial application-specific software is required to create application systems. Because of the relatively primitive capabilities available commercially for many application needs, this requirement drives an increasing demand to build more and more application-specific software to complete the architecture for application systems. As systems evolve from single-user and departmental-level applications to the enterprise with greater interoperability capabilities, the functional gap between available commercial software and individual user software will continue to increase.
The architecture of applications software systems is increasingly important in how systems support user needs. The majority of systems that have been created outside of the telecommunications industry are integrated using procedural and other paradigms that often lead to ineffective solutions. In fact, for systems created by corporate development organizations, a majority of the software projects are considered unsuccessful at completion. From an architectural perspective, many of these systems resemble the configuration in Figure 3.4 (a) for stovepipe systems. In a stovepipe system, there are a number of integrated software modules. Each software module has a unique software interface. This unique software interface corresponds to a single program implementation.
)
Figure 3.4. (a) Stovepipe Systems and (b) Component Architectures
When the system is integrated, there are many one-to-one dependencies between various parts of the system. These dependencies are unique integration solutions. As the scale of the system increases with the number of modules, the number of dependencies increases by the square of the number of modules. This increase in complexity has many negative consequences. In particular, as a system evolves, it becomes increasingly less amiable to modification and extension. System extension happens to be one of the major cost drivers in application development; it can account for as much as half of all software cost [Horowitz 1993].
An alternative way of building systems includes a planned definition of software interfaces that provide a greater level of uniformity across the integrated solution. Component architectures are application systems that are defined using consistent application program interfaces across multiple instances of software subsystems (Figure 3.4). Component architectures reduce the dependency between software modules. The reduced dependency enables the system to be extended and support larger scales of integration. The complexity of the software integration of a properly built component system is tied to the number of software modules needed to build the system.