The great thing about standards is that there are so many to choose from. (Daniel McCracken, I think).
There's 3, no 4, primary places programs end up. It's largely personal preference, but I have some guidelines I use. For whatever it's worth, here there are:
For a complete self-contained vendor environment, there's /opt. /opt is sometimes subdivided by product within vendor, as for example IBM and Websphere.
For a traditional approach, there's the /usr/local tree. A lot of Unix-style packages would build and install their packages into a subdirectory named for the package under /usr/local. I often put
Tomcat and
Ant there.
For really pervasive stuff, you can install directly into the /usr/bin and related directories. This is best done via the system's package manager (rpm, debian package manager, Solaris dpkg, etc.).
There's also the blended approach, where you install everything in one directory (/opt or /usr/local) and then softlink to present its system characteristics in their familiar locations; config stuff in /etc, logs in /var/log, workfiles in /var/lib and so forth.
The fourth approach is seen for applications that have a particular runtime environment such as Python or Perl. In this case, the packages normally install into a /usr/lib/<language> directory, such as /usr/lib/perl/site_perl.
CAUTION: according to the strict definition of the FHS, /usr should be read-only. Packages that have volatile storage requirements such as work directories, session info, etc. should assign those items elsewhere (normally under /var/lib).