Likewise, if your business colleagues were instrumental in selecting an application but you know it's going to be difficult to introduce the app into your existing architecture, then you must say so up front, informing everyone involved that they're probably stretching time lines or increasing costs.
You're not being "part of the team" by agreeing to all of their demands at the beginning of a project; you're risking the project. I agree with the CTO I recently spoke with who said, "The goal is to serve the end customer of our business." But too many IT people--including many in top positions--tell businesspeople what they want to hear instead of what they need to hear.
Yes, there will be times when customization will give you functionality your competition doesn't have--to support a new line of business, for instance. But to customize something that applies throughout your industry--or something even more generic, like a customer or prospect database--will only cause you headaches without much gain. For such applications, a product sold to 20 or 200 other enterprises will offer everything you need; you just need to adjust business practices.
You will also be called on to implement systems that use a database your organization doesn't support. Again, this is fine, as long as the database is underpinning a vertical-market product with only one or two vendors, not something generic.
It is a difficult path to walk down, but you must insist that business colleagues quantify their needs so you have something to compare to the up-front and ongoing costs of customization. Adding code to an application or machines to a data center costs money. If the customization will save hundreds of man-hours a year, then it might be worth extending the project deadline by six months and taking on those costs. But everyone must be on the same page.