Variations for Package Implementation

Packages these days are incredibly configurable. SAP, the most popular enterprise application package, has more than 10,000 configuration options in its setup tables. The net result of this (besides running up the billing rate of people who know what these settings mean) is that you impose meaning on the application by setting these parameters. Figure 9.3 shows the major tasks in an application package implementation. Most of them are similar to the custom development described earlier.

Figure 9.3: Typical tasks in a common off-the-shelf (COTS) package implementation.

There is no substitute for experience in these cases, but what we'd advise anyone to do would be to build a semantic model of the system as you intend to implement it with the package. The elicitation process for this model will be similar to the process you would go through for a custom system. The model will help with scoping the implementation. (Sometimes its not obvious which of the many modules in a package you want to implement; for example, do you want to implement the vendor's pricing algorithm, which is based on a complex set of tables, or is the algorithm you have hard coded into your legacy system more appropriate?) It will help with the inevitable data conversion and systems integration, and it will help rationalize your conversation with the experts you have assisting with the implementation because you won't remember what values you authorized for the 10,000 variables and certainly won't be able to predict their interactions.

With the growing popularity of XML, it is likely that most vendors will publish at least an XML version of the public semantic model interface of their packages. SAP (the largest of the enterprise package software vendors) began supporting XML with its 4.6c version.^[52]

^[52]See http://www.sap.com/solutions/r3 for further information.