This short example follows one typical implementation of a DAM system. While this example won't go into too much detail, it contains enough information to serve as a rough guide. All of these topics are covered in this chapter, so if you need more help with each step, refer back to the previous sections. Information about choosing the right product has already been covered in previous chapters and won't be discussed here.

•  Test the solution
•  Prepare the setup
•  Prepare the users
•  Deploy the software
•  Automate your processes
•  Integrate your tools

We are once again looking at GreatGames, discussed in previous chapters. They are a mid-sized company with 50 users and a mixed setup of mainly Windows XP and some Mac OS X machines. The server will be a Linux machine, with a dedicated file server running Samba.

Testing the solution

After reviewing the requirements, GreatGames decides to use Superbranch, a (fictitious) Open Source SCM able to manage binary assets. The main advantages are the cost of the software (it's free) and good support of development tools. Since there is no specialized support for artists, their feedback is especially important during the testing.

Since GreatGames is not able to test a whole production spanning two years' runtime, the team decides to set up a small group of users who are going to test the software with assets from the previous production. Since there is currently a bug fix—a patch—in production, the users decide to produce the patch with the system.

The team consists of:

•  Two programmers
•  One 2D artist
•  Two 3D artists
•  One project manager.

Adam and Albert, the administrators, set up the server with the data from the previous project, and everyone on the test team gets a client installed on their system.

During the test it becomes obvious that the system is difficult for artists to use, since some of the system's functions a

Adam and Albert run extensive load tests on the system, using automated command line clients. The software behaves quite well under load and seems to handle the amount of data from the last project without any issues. Questions regarding the configuration and backup of the system are quickly answered with the help of the large user base on the Internet.

Peter, the programming leader, reports that programmers are extremely satisfied with the functionality and the integration into their programming tools. Most things work as expected and even though there is some missing functionality, what is there is enough for them to work with the system.

The project manager, Sam, is not convinced though, since there are few tools to help him to monitor the progress of the project. The patch is produced without any problems however, and after getting feedback from everyone, Sam gets the impression that even the artists were able to get used to the system after a while. Since the artist team at GreatGames is used to learning complicated tools, it seems it will not be such a problem for them. Although there are many missing features, the administrators report that the system is very stable, so Sam decides to give the software a try in the next project.

Preparation of the setup

Once the decision has been made, Adam and Albert start setting up the production server. Since they have already been through the configuration process, they finish quickly. But the production of the next project has already started, and they realize they can't just spend a day copying over data onto the production server and then installing the clients on each machine. Therefore, they decide to move the data onto the asset management system team by team. This allows them to install only a few machines per day, making sure that, at worst, only a few users are prevented from working.

Using the database from the software test, Adam sets up a backup system with both tape backups for long-term security and hard disk copies for fast data restoration. Since the data volume is quite high, he also updates the network backbone to a faster standard.

After running some tests on the system, doing backups, and trying out how long it takes them to restore a damaged system, Adam and Albert are confident that the system will work during production.

Preparing the users

Albert installs the clients on each machine. Since at least one user from each team participated in the test, these users are asked to train everyone on their team. Using the test setup that is still running, they explain all the features that are useful to their colleagues and conduct tutorial sessions with each of them. After a day of training, everyone is confident that they can start working.

Deployment of the software

With the clients installed and the servers ready, Adam starts moving the data to the DAM system. As soon as the move is started, the old file servers are made read-only, so changes will have to be made on the new system.

This works smoothly until he gets to the artists. The amount of data is so large that he has to halt production for half a day. Luckily the team is still in the concept phase and the artists can easily spend a productive workday using paper and pencils. From then on, Adam and Albert relocate data during the night, eating pizza and drinking plenty of coffee.

Review of the system

After using the new DAM for a month, Sam, the project manager, starts evaluating the setup. As he had already seen during the testing phase, the programmers had no problem with the system at all. Some artists were annoyed in the beginning though, and tried working around the system as much as they could. This led to situations where data was missing on the central server.

Sam spends some time in discussions with these “problematic” users and their team leaders and finally convinces them to accept the system. It takes some additional training and a few configuration adjustments from Albert for them to realize the system's benefits and start using it properly.

Some bugs in the software itself are slowing down production in some cases, and Adam starts looking on Superbranch's website for fixes. Since none can be found, he compiles a list of these issues and gives them to each user. With this list all users are able to work around the issues most of the time.

On the administration side, there were no serious issues except for one crash of the RAID system, which was replaced within two hours. With the hard disk backup, Adam was able to restore the system quickly, with only the data that was created within the six hours before the crash lost.

Automation of processes

When it becomes clear that the system itself is working well, Sam sets up a list of process improvements and automations together with David, the lead artist, and Peter from programming.

Peter then writes a set of scripts with the help of Adam to automate these processes. Not everything runs as desired, but some of the most tedious tasks can be automated. Sam decides to accept the fact that some things still have to be done manually.

Integration of tools

One big issue left is that the artists have to cope with unfamiliar tools and thus they are not working efficiently. Since the DAM system chosen is not artist oriented, they sometimes even have to use command line-based tools to submit the data they are working on. In some cases they produce large amounts of files, which then have to be selectively imported into the DAM. To solve these problems, David pulls in two programmers who have been working on the in-house tools before. Together, they design an integration that helps the artists to store and access data in the DAM without having to worry about the details. This actually works quite well, but the task consumed a large amount of the programmer's time. And even after one month of usage there are still bugs that the programmers have to fix. But the artists are mostly happy!

Looking at the implementation at Superbranch, it becomes clear that not everything is ideal. For example, the DAM system was not the best solution for the artists, forcing them to get used to a complicated work environment. The additional time spent integrating the in-house tools cost large amounts of work time. On the other hand, there were few problems with the system itself, and the production was able to finish without any issues.