The triple firewall/IPS layer doesn't make too much sense to me, unless the various devices have disjoint sets of functionality. If there's no opportunity for code or malicious activty "between" two of the devices, and they really are just plugged in back-to-back, it seems like a giant waste of money.
A more traditional architecture would be something like:
Internet->Firewall/IDS->Web server tier->App server Tier->(optional firewall/IPS)->database
That optional firewall between the app server tier and database isn't really that useful, but is required by PCI and potentially other regulations. Simple access controls or a software firewall on the database server makes more sense to me for most environments rather than a dedicated separate firewall.
A more complicated, but potentially useful setup would be to use a web/proxy "bastion host" tier:
Internet->Firewall/IDS->web/proxy server->Firewall/IDS->application servers->(optional firewall/IPS)->database.
In my opinion, the above setup only makes sense if the firewall/IDS between your bastion host is able to do more than simple stateful packet filtering. If the IDS functionality inside that Firewall/IDS can look inside HTTP packets and only allow a set of defined behaviors between the web/proxy tier and the application server tier, then it might be worthwhile.
Note that any of the firewall/IDS tiers can be be implemented as software firewall running on the destination host. This simplifies networking greatly and scales better than hardware security solutions. You do give up the centralized "choke point" for monitoring all traffic, but that is often a requirement to scale up. I doubt Facebook or Google passes all their traffic through any firewall tier - the security functionality simply has to be distributed at that scale.