nctionality, configurability and ability to be integrated will also contribute to gauging the package's viability. A package's technical architecture will also affect its viability. Whether an application employs a multi-tier, Web-enabled architecture or an older, Chapter 5 - The Enterprise OSS Platform less flexible architecture that will require rework, for example, is a huge consideration. This topic will be covered in more detail in Chapter 6. Package Direction. Once an IIC has evaluated the application's track record, it should look at the vendor's plans for the future of the package. For example, what is the vendor's development schedule, and is it aligned with anticipated future needs? Does the vendor have the expertise and resources to meet its goals? Does it make technical sense that the application will evolve the way the vendor promises? Price. The IIC also needs to look at the total cost of ownership, including license, maintenance and configuration aspects. Long term maintenance and configuration costs are discussed further in Chapter 7. 4.1 Common Pitfalls Though package selection decisions are most often determined by functionality, it is important not to overlook the vendor's track record and the application's flexibility. Though it's nearly impossible to generalize about a vendor's performance, there are a few areas that tend to cause the most problems. The first is the vendor's inability to deliver its application. We mentioned earlier that some vendors' business models, for various reasons, do not scale. In some cases, they have overextended themselves, taking on more projects than they have skilled people to staff. If the vendor does not have sufficient training resources, internal staff, or knowledgeable implementation partners, the application will be difficult to implement successfully and on time regardless of how good it is. The second major problem area is the inability to integrate the application the vendor. Some applications are delivered with poor APIs, or none at all. It can also be