Right now there is a huge chasm in your product team between your application developers and your network admins. The application developers (appdevs) spend a lot of time and effort building up an application. Then, once they are satisfied that it's ready to launch, they begin talking with the network admins about the best way to install their application, how to upgrade it, how to scale it once it's a big hit. While the appdevs are crafting the application, the network admins are busy building servers, installing operating systems, preparing their "house" for a new baby that they hope won't be too cranky and will sleep through the night right from the start. The two teams are often very disconnected, one hands off to the other.
The network admins work on very expensive, specialized equipment that allows them unlimited control over the traffic that flows through the network. They can use iRules and policies to effectively manage their traffic. Sometimes these rules inject client scripts or html into web pages. Most of the time the appdevs aren't even aware of the advantages that network side scripting can bring to their applications. If you've ever had to write a mod_rewrite rule and make sure that the change to it and synchronized to every server in your farm, you can appreciate being able to write a single iRule that will do the redirection for you. Up until now, only the server admins had access to the BIG-IP's in their organization and they were responsible for writing and maintaining the iRules, even if those iRules were application specific. Now with LTM VE, the appdevs can see how taking advantage of iRules can change the way they architect their applications. Appdevs can run a copy in their development environment with the production iRules running and save some time during deployment. They can work with the system admins to virtualize access to different services they are consuming in their applications.
On past projects, I've had to maintain several configuration files that basically just told the application where to look for certain servers or services. One set for development, another for testing, one more for load testing, one for staging, and finally the production section. Some times each section would have multiple sub-sections in case we needed to work with different combinations of servers and services. For example, you may want to consume a production service, but store the data in a development database to reproduce a bug. You may need to load a customers data set and test your changes against production data to test the bug fix. Being able to work with the network admins to set up app pools in a LTM VE means not having to juggle multiple configurations. You can point at a single location and let BIG-IP LTM VE do all the work.
Joe has a great article about setting up your laptop to do development with BIG-IP LTM VE.
