Installation and Architecture

The various definitions of "software architecture" provided in Chapter 1 don't correlate strongly with the concept of installation or installation process. I don't have a problem with this, because the primary reasons "architecture" is of concern deal with such things as efficiently organizing the development team or choosing the best tarchitectural style for a given problem or problem domain.

Forces and Choices

That said, there are a variety of ways that marketectural or tarchitectural forces and choices influence the installation process, as the next sections describe.

Managing Subcomponents

In a component-based system, all required components must be present, in the right version and configured the right way, in order for your software to work. Quite often this means making tough choices about whether or not you should install a component or require that the user install it. I've done both.

In-Licensing Requirements

Some technology license agreements (see Chapter 5) have terms governing the installation of the technology, such as contractually requiring you to use their installer. Of course, the license agreement could state exactly the opposite and require you to write your own installer subject to its terms.

License Agreements

Your legal department will want to associate some or all of the license agreement with your installation program. This is commonly referred to as an End User License Agreement (EULA). Make certain you're including a EULA as part of the installation process in the manner your legal department requires. For example, you may be required to have a "scroll to the bottom and click" screen that presents the license agreement to the user and halts installation until the user indicates acceptance (usually by clicking on a button).

We Pick up after You're Done

The specific technologies chosen by the tarchitect can affect the installation process in a number of ways. For example, it is common in well-designed tarchitectures to partition persistent storage in a separate subsystem, both logically and physically. If a relational database is used for the actual storage, quite often the only configuration data needed is the database connection string, a user ID, and a passwordprovided the database has been properly installed on the target system, the appropriate permissions have been set, and the database is available for your application's use. If the database hasn't been installed, you're going to have to do it.

In one application in which we supported both SQLServer and Oracle, we created a two-step installation process. The first step required customers to install and configure a variety of software, including the database, before they could install our software. To help them, we provided detailed instructions.

The second step was installing and configuring our software. To make this easier we had several steps, including creating a preinstallation program that ensured that each required technology was properly installed and configured.

Business Model

Some licensing models, such as per-user volume licensing (see Chapter 4) track installation events to count the number of licenses consumed. Others track access or use of a component that may affect the installation process. For example, many large applications offer small features that are installed only when the user attempts to use them (on-demand installation). More generally , your business model can affect how you create your installer, and your installation process can make supporting your business model easier.

Partitioning Installation Responsibilities

A general tarchitectural concern is the partitioning of responsibilities among various system components. As component capabilities change, the responsibilities we assign to a component may also change, which ultimately can affect the partitioning of components in the delivered system.

The increasing sophistication of installation programs, such as InstallShield's Developer, provides a great case study. In the early days of Windows, writing a really great installation program required the tarchitect to create a variety of components to check for the right versions of key files, necessary disk space, and so forth. Such tasks, and many more, are now performed by installation programs. Learning to let these programs do as much work as possible is a practical strategy for handling many complex installation tasks .

Installation Environment

The environment you're installing into, as well as the environment you're going to support, can have a substantial impact on your installation architecture. Consider an e-mail management tool for the growing market of knowledge workers who work from home. If the tool is really useful, it is inevitable that corporate users will want to adopt it.

While both home and office users may require the same core features, the context associated with each is very different. This difference will be expressed in a variety of ways, including the installation process.

The home user may be content to install the software via a CD-ROM or a DVD, or through an Internet download. The corporate user, on the other hand, is working in a very different environment. His machine is likely to be under the control of the corporate IT department, and the system administrator will probably want to be in charge of installationamong other things, by installing the software from a centrally controlled server on the internal network; by controlling one or more installation parameters such as where files are stored; and by controlling the specific features installed. When designing your installation process, make certain that you account for the environment of the target market.

Installation Roles

Many enterprise customers are comprised of people having different roles. System administrators have different responsibilities than database administrators, and both are distinguished from security and network engineers . To make things easier for you and your customers, organize complex installations according to these different roles. For example, database setup and data load scripts (environmental, schema DDL or DML, or data) should be separately organized, allowing database administrators full visibility and necessary control over your installation. This actually saves you time, because chances are each administrator will want this control before installation proceeds anyway.

Sensitize Developers

Have each developer run through the install process at least once so that they're sensitized to how their work products affect installation. Do this when they're first hired , so that they enter the team with an appreciation of installation issues.