7.3 Deployment

---

The introduction of a tool or integration of two tools into the everyday process of an organization is referred to as the deployment of the tool. Different ways to gradually deploy complex tools are described in this section. The section also includes thorough, more specific descriptions of PDM deployment and SCM deployment.

7.3.1 Deployment process

The deployment of a large complex tool, perhaps replacing another complex tool, is difficult to perform in one large step. There are several reasons for this. The new tool may not immediately function 100% at the organization’s environment. The problems that may appear in the beginning should not affect the entire organization; they should be processed by smaller groups first. The new tool may require education and training of the personnel concerned, often best performed in smaller groups. A deployment group is often used to help developers using the tool for the first time, and this help is more efficient and under control if the numbers of beginners is kept small. It is therefore often wise to train users, and deploy the new tool gradually. What follows is a series of examples of how such incremental deployment can be performed.

• Imitate the old tool. All users involved are assumed to be familiar with the old tool. Using first all of the functionality of the old tool that is incorporated in the new tool simplifies the deployment of the new tool. The new functionality in the new tool can then be introduced gradually. When the new functionality has been introduced, the redundant functionality can be removed. The disadvantage of this method is that it may lead to overlap between old and new functionalities during the transition phase. There is also a risk that users will avoid using the new functionality but will continue to use the old and remain unprepared when the old functionality is finally removed.

• Utilizing organization structure. Within a company, a product is often developed by several more or less independent teams, with each team responsible for their part of the product. The deployment process can utilize this organizational structure by letting only one of these teams first use the tool in order to make it work effectively in the company environment, before deploying it to the rest of the company.

• Pilot project. If the development is project driven, a common strategy is to execute a pilot project. When the pilot project is completed successfully and all of the lessons from this are learned, full deployment can be accomplished. A considerable advantage of this method is that a pilot group often consists of enthusiastic experts, those interested in testing new tools, those most eager to learn the latest developments, and those most likely to make the project successful. Such a project group will generate positive feedback, engaging and inspiring others in the organization after the successful pilot project and assisting with their education and training. Unfortunately, it is not always the case that such a group is available, as their capabilities are needed in all sections of the organization.

• Dividing the data managed. It is possible to deploy a tool to process only a portion of the data or certain types of data and continue to use the old tool for all other types of data. In this way a large number of users can learn the new tool at their own pace without jeopardizing the production. For example, a new PDM tool can be used to process nonproduct data initially, and when all users have learned the new tool, its use can be extended to the processing of product data.

• Deploy the new tool on a new mainstream project. This can work well in a project-based organization. A decision is made to commence deployment on the next available project. The deployment project works closely with the mainstream project to ensure that the mainstream project is not compromised by problems with the new tool. This approach has the advantage that there is a realistic environment to establish the new tool, and the deployment can naturally work through the various project stages. When the mainstream project team members get deployed on to other projects, they take the experience of the new tool with them. The risk is that is if there are major problems with the deployment, then the mainstream project may be jeopardized.

7.3.2 PDM deployment

PDM system deployment involves both process and infrastructure changes. The main purpose of a successful deployment is a smooth transition from older business processes to newer, improved processes utilizing the new and improved functions provided by PDM. However, due to the extensive changes in the infrastructure involved, the initial step of a PDM deployment requires large efforts. For example, PDM and database servers and the PDM software must be installed. Before the installation, the infrastructure must be specified: the network topology to be used, the capacity of the corporate server and of the other servers, and ways that the network can be expanded in the future. The entire network will probably not initially be built, and the full capacity of the nodes will not be achieved. As the PDM system will be integrated in new processes, the network and the capacity will also increase. In addition, changes in the system infrastructure and the information architecture (information model, data structures, databases, and vaults) must be specified, and the migration of data from older systems must be performed.

Apart from what is described in general for the evaluation and deployment of a complex system in Section 7.1, and cultural differences described in Section 7.3.4, additional areas must be taken into consideration to shorten the time and decrease the difficulty of deploying a PDM system:

• Administration and performance tuning. A PDM system should be customized in a test system separate from that which is in production (i.e., where the system users store, retrieve, and update product data). The newly implemented functions can be tested in the test system without disturbing the users. Later, all of the adjustments done in the test system will be exported into the production environment. The migration of existing data from an old system to the deployed PDM system must be planned; programs for automatic data conversion written, tests performed, routines and procedures for the migration written, and original data migrated into the new PDM system. The administrators must install client software, perform general administration of the PDM system, supervise database transactions, and install new servers, including software. Further, close cooperation with system and network administrators, system performance tuning, and timing of hardware upgrades must be taken into consideration. Before the deployed system can be used in a production environment, a system acceptance test must be performed to verify that the new system will function correctly with the migrated data and fulfill customer requirements.

• Training. Planning for training and user support are essential factors in a successful deployment plan. Middle managers, users, and administrators should be prepared before system usage. Key users will play a critical role in mentoring and supporting other users. The training must emphasize the process tasks and not only tool functions. A broad-based training plan will help minimize the obstacles caused by enforced cultural changes. Training for new users (e.g., new employees) and retraining of users moving between projects must be provided on site.

• User support. PDM tools are usually large and complex, and they require a lot of efforts in the beginning when users do not understand all of the concepts. PDM tools require a permanent support from experts.

• New groups. Deployment of PDM requires the involvement of new groups. For a successful deployment, several groups must be formed. Examples of such groups are an enterprise deployment team, a core team, and a training team. These groups must be closely coordinated for a successful deployment of the PDM system into a production environment.

The main task of the core team is to define the new processes used in the PDM system (see Figure 7.5). To implement these new processes, the core team forms a project group; specifies the project goals, all activities (e.g., new functions to be implemented or servers to be used), and a time schedule in a project plan; defines necessary additional requirements from other systems; and defines requirements for system administration and operation and support. The team then specifies how existing systems will map into the PDM system. Further, additional requirements related to the data model, working process procedures, the user interface, system information, infrastructure, and system administration must be identified and implemented. One type of change will be implemented by specification or modification of the data model. The new data model will define new work processes, new objects, new attributes, and new relationships to be implemented in the database. Another type of change will require writing additional software.

Figure 7.5: Deployment project resources and activities.

An enterprise deployment team should be formed early in the project (i.e., when all requirements and planning for the project are finalized). The team’s responsibility is the deployment execution. The enterprise deployment team should be focused on the enterprise view of the system deployment. It should consist of persons responsible for business-focused functions and persons responsible for communication with support people of the local sites (the site support teams). The enterprise deployment team will also need to establish user-support teams and identify key users. Key users will act as mentors and in some cases as backup for the first line support (i.e., they will answer questions from end users and managers). The responsibility of the site support team is to focus on local administration and end-user support issues (i.e., to ensure that servers are up and running, to supervise clients’ installations and upgrades, and to supervise databases and software upgrades on the PDM server). The team must also prepare a training team with start time, users to be educated, and location.

The training team includes technical writers and teachers. Their tasks are to write training material and train different end users at different locations, depending on information given by the project plan of the enterprise deployment teams.

7.3.3 SCM deployment

The efforts and time spent in the deployment of an SCM tool can vary considerably, depending on the software development process and the SCM policy of the organization. For small development teams, SCM support should be simple. For large projects and large teams, or distributed development, the requirements for SCM support are much greater. This calls for a more advanced SCM tool, which requires considerably more effort for deployment and subsequently for providing support and maintenance. The SCM policy will determine which type of tool will be selected and in which way it will be deployed and used. For this reason, organizations usually have an SCM policy, which identifies the purpose of SCM and the main directions of its use in the organization.

In the same way as PDM, SCM supports the infrastructure (i.e., makes it easier to organize the work and makes it possible to accurately maintain the old products), but it does not provide direct support for development as many other tools are used in the development environment (e.g., language-sensitive editors, wizards, debuggers). Many developers therefore do not see the direct benefits of SCM, and, on the contrary, they may feel that its use slows down their development work. In many cases, there are psychological barriers, but there are also SCM tools that are not user friendly and that require much additional work for the developers and the administration. This is especially the case if the tools are not properly integrated in the development process. To overcome these obstacles, the SCM tool must be adjusted to the development process to be used as smoothly as possible, and all SCM users must be well prepared for its use. This is the main goal of the deployment.

The goal, the results, and the deployment activities should be identified and specified in the deployment project plan. Depending on the complexity and size of the development process, different deployment groups can be involved in the deployment procedures. An SCM group (which will also exist during the full exploitation of the SCM tool) will be responsible for building the SCM infrastructure, the administration group will be responsible for defining the SCM system topology (the network of servers and clients), and a training group will train the SCM users. The building of the infrastructure and the integration of the tool in the development environment may require the development of additional software that can automate certain activities (such as automatic check in and check out), so that it may be necessary to build a development team. Such a team may be a part of the SCM group. Many of these activities may require expertise that the organization does not have. This expertise can be obtained by special training of the deployment groups or as assistance from external experts, often offered by the vendor.

SCM procedures should be integrated in the development process smoothly (i.e., as much as possible stepwise, both with respect to the functionality and the coverage of the development projects). If possible, each new function should be deployed in a particular project and then successively distributed through the organization.

To illustrate the deployment process, let us look at an example of a deployment scenario divided into several steps.

7.3.3.1 SCM process planning

As the benefit from SCM tools is only gained by their use in a development process context, it is necessary to specify the entire SCM process. This can be done on several levels of abstraction. We have already mentioned the SCM policy, which explains the overall goals of SCM. An SCM plan gives more details of particular activities that should be performed in development projects. In addition to such a general SCM plan, each project should have its project SCM plan that will describe the SCM activities in detail. Such a plan should state the following:

• The SCM structure that will be used;

• The tools (SCM and all other tools) and development environment that will be utilized;

• The software entities that will be changed;

• The baselines and configurations that will be created;

• Who will make the SCM decisions and how;

• Ways that the change management will be performed.

For the deployment process, a set of documents that are normally a part of any project should be created. These documents include deployment requirements specification, deployment project plan, project reports, quality assurance report, and final project report.

7.3.3.2 Tool installation

The SCM tool must be installed and the resources (i.e., servers and storage devices) for its installation must be obtained. The simpler SCM tools usually operate on the file system and do not require any considerable space. More advanced SCM tools usually use a database that might require a large storage media and additional software (e.g., database servers). The client parts of the tool must be installed on developers’ workstations. SCM tool installation is a task for the administration group.

7.3.3.3 SCM infrastructure

The basic infrastructure of an SCM tool includes a repository and workspace. The repository, which manages versions of CIs (such as files and folders), has an internal structure. It is usually a hierarchical structure representing a file system. A workspace might either be a part of the repository or placed in the file system. During the deployment, the organization should decide on the repository model—if there will be one common repository to include all development (and other) projects or if several repositories are to be created. Similarly, the overall structure of the workspace should be defined, where the developers will have their workspaces—in their private directories, on local clients, or on a common users’ server. The SCM group is responsible for the design of the SCM infrastructure.

7.3.3.4 Version management and concurrent development

We saw in Chapter 3 that there are different approaches to version management. The organization or the project groups should decide which model is to be used in the development projects. Should a concurrent check in and check out be allowed? Will it be possible to work on different variants? What is the merge policy? Different models are the bases for different types of development in which different goals are emphasized. For example, for a flexible and less firmly controlled development, a full concurrency will be allowed, while in a more strict process, only the strict lock mechanism and sequential version will be permitted. To facilitate the developers’ everyday work, the parameters defining the default behavior of the version management can be set up centrally.

7.3.3.5 Configuration selection

In the same way as for version management, the default selection criteria can be set up by the SCM group.

7.3.3.6 Build management

SCM tools usually provide basic support for building software in the form of a particular tool (for example, a program named Make). A single tool alone is not sufficient for an efficient build procedure. The developers must often define how the building will be performed, and this specification is often time consuming and error prone. The SCM group can provide the developers with programs that automatically create the build procedures.

7.3.3.7 Release management

Most SCM tools do not provide direct support for release management, but many small supporting functions and data are available to be used in the release management process. The minimum support that the SCM group should provide is a guideline for creating a new product release, indicating which tools can be used and how. Better support is provided when the release management process is performed automatically. Such support requires additional software, including functions from the SCM tool, such as that for generating a list of items included in the product and a list of all changes implemented (new functions and error corrections). This software can be rather simple (e.g., a set of scripts that execute particular SCM functions). More advanced support will include a reach user interface, which makes it easy to understand and to use different options that might be required for different types of projects.

7.3.3.8 Integration with other tools

To avoid distracting the developers with administration tasks, the entire SCM process should performed as smoothly as possible and should not disturb the developers more than necessary. This may be achieved by integrating the SCM functions in other tools and by adding new functions that use the SCM tool. For example, when a developer begins work in a project, all tools and all data used in the project (i.e., source code, libraries, and documentation) should be automatically available. Another example is automatic check out and check in of the files that the developers wish to modify. Many SCM tools provide such functions or functions that can be executed via line commands or via API. This makes it possible to build new applications that will automate different procedures in everyday work. These applications or the SCM functions can be triggered directly from other tools. The SCM development team (and the SCM group) must develop these applications and must integrate them in other tools. This work can require much effort, especially if a simpler SCM tool has been selected.

Integration with other tools should be performed stepwise. The basic functions, which are easiest to implement and which have the largest impact in the everyday work, should be implemented first (e.g., the automatic check-out/check-in sequence). More advanced procedures can be developed later and successively replace the guidelines.

7.3.3.9 Change management

Many SCM tools incorporate support for change management. Some do not, and for this case external change management tools are available. Change management is one of the more advanced activities and will usually be included in the process when the basic SCM functions are already established. Different levels of integration of basic SCM functions and change management can be achieved. In a nonintegrated solution, the tools are separate and the developers are those who do the integration job by manually updating documentation (e.g., entering changed file names in “change requests”). In a fully integrated solution, every change made in software or documentation is automatically related to change requests. Additional functions related to change management are functions that provide the statistical results [3] of the change process. This type of function is one of the more advanced support functions that only organizations with a mature development process require.

7.3.3.10 Distributed development

A distributed development is considerably more complicated than a local development. The basic principles must be clearly specified before the distributed development is begun. Examples of questions considered by these rules are [4, 5]: Who is responsible for which part of the system? In which way is the data replication achieved? How is awareness of each other’s activities between different groups supported?

Different SCM tools provide different support for distributed development. When using simpler tools, the development of additional software may be required. Even if sufficient support exists, the distributed infrastructure must be defined and built. The introduction of distributed development is a costly process, and it should usually be introduced in the organization in the form of a separate project.

7.3.4 Deployment of the PDM and SCM integrated environment

We can observe a large difference between deploying a tightly coupled integration and deploying a loosely coupled integration (see Chapter 4). A tightly coupled integration becomes like a completely new tool, with new functionality and with a new user interface. With a loosely coupled integration, on the other hand, it is possible for the users to continue working with their old tool. The integration then also provides additional functionality, which can be deployed according to the examples in Section 7.3.1. Two different, complementary issues should be taken into consideration: the integration and deployment of the tools and a common environment, and the integration of people that will work in the common environment and that must understand the entire process.

7.3.4.1 PDM and SCM tools integration and deployment— Different scenarios

We can distinguish three basic cases for obtaining a PDM and SCM integrated environment. The first case is applicable to companies developing hardware products and beginning with software development or including software components in their products. Together with software development, a new SCM tool will probably be introduced. Companies that traditionally develop hardware products tend to see the software components as hardware components. On the system level, this is a good approach, and it should be reflected in the use of PDM and SCM tools. The software deliverables (binary code and documentation) should be exported from SCM to PDM, while the software development should be performed in the framework of SCM. The deployment phase will include the deployment of the SCM tool itself and development of the import/export procedures. The second case applies to software (or dominantly software) companies that need PDM for managing final products outside the scope of SCM. The deployment will include deployment of the selected PDM system and the development of import/export functions between PDM and SCM. The third case comprises a situation in which a company develops both hardware and software components (and systems), and uses both PDM and SCM, but in separate processes. This case is in a sense simpler, as the users are familiar with both tools and the integration can be achieved faster and with less effort. However, it can happen that the process goes with much more difficulties if the users of these tools do not understand each other. For this reason the human and social aspects are very important.

7.3.4.2 Integrating people—Human aspects

Assuming a loosely coupled integration has been implemented, the PDM and SCM users can continue to work within their respective tool with particular additional functions related to the integrated environment. The next step is to:

• Get the users to begin to use the new functionality. This is similar to the introduction of any new tool and is not specific to PDM/SCM integration. It may also happen that some of the old functions will be replaced with new functions.

• Get the users to begin to talk with each other (with users from the other domain) and collaborate in order to understand the common process.

This collaboration must, in fact, begin during the requirement phase of the integration process:

1. Together decide upon the requirements of the integration;

2. Together decide how to collaborate using common parts. Even though it is always preferable for all the users involved to receive a positive personal return on their investment of effort, there is always a risk that some persons may be required to perform extra work to be able to provide others (from the other domain) with information. Within a group this might be acceptable, but the less people know of each other, the less knowledge they have of the needs of others, and the greater the risk of failure. It is thus even more important to ensure a positive personal return on investment for all when directing people from two domains to work together.

7.3.4.3 Cultural differences

Unfortunately, our experience is that PDM and SCM users seldom collaborate or even communicate with each other. The reasons for this may be several:

• Persons from both domains rarely meet each other. PDM users and SCM users work in different groups in different departments of the company and software developers have little contact with hardware developers.

• They usually have different backgrounds, interests, and goals ( technicians versus nontechnicians). For example, SCM users work closely with developers, and often it is software developers who also have the role of configuration managers. These persons tend only to see the software and not the entire product. PDM users, on the other hand, are often located closer to the product managers (who may even be nontechnicians, with economy more their primary goal).

• The terminology used is not consistent. Some common terms are interpreted differently by PDM and SCM users. An example is configuration control, which is the definition and management of product configurations for PDM users and the control of changes to a CI after formal establishment of its configuration documents for SCM users. Closer understanding across the domain boundaries is complicated by such differences in the use of terminology.

As a result, the two groups tend to confront each other rather than try to develop a collaboration. The impression gained is that both believe that their methods and tools are superior and that problems in the other domain can be solved easily by using their tools! Persons working in each domain do not understand the requirements of the other domain. Many software developers believe that SCM tools can manage data at the system level. PDM people, on the other hand, often appear to believe that software is a set of binary components only, as easy to put under the control of a PDM system as any other component. For vendors, also, the cultural differences are a difficult subject when discussing PDM and SCM with customers.

7.3.4.4 Building bridges

What can be done to make integration successful despite the cultural differences? Information is probably most important. Information can be directed to both groups to make them understand the benefits and needs of the other domain. Because it often is possible to continue to work within the same old tool after integration, it is quite easy to gradually introduce new functionality. Incremental deployment and a personal return on invested time will keep all involved positive to the change.

---