In a real world IT operation, we never buy hardware by itself. Instead, we buy a workflow/process, starting with the application(s) we need to support, and then buy whatever hardware we believe we need to support it. So we always start from some base requirement imposed by the application.
To do your assignment, I would suggest looking at some of the business applications out there like sales/contact trackers, etc. Most of them these days have web frontends, and offer ios/android apps as a (paid) feature option. Typically the marketing material for the application will list requirements. You can use all of the material you find, the marketing and requirements documentation to pump up your assignment. The typical requirements will tell you what operating system it runs on, what storage type it uses (by file, flat file, SQL, or something else), any oddball IO devices (like card swipes, scanners, printers, dongles,etc).
Using the information will make it a lot clearer what you might need to buy. Bear in mind, 700 people may sound like a lot, but IT-wise, that’s a pretty small workload. Remember, only a few of them will be using the app at any given moment.
Also, bear in mind, how you build it depends more on how mission critical what it does is. If the Company can’t run without the application, then it needs to be built to tolerate equipment failures, power failures, the stupids, etc. IT Pros don’t build systems with single points of failure anymore.
In a larger shop, this probably wouldn’t result in any new hardware spending. Instead, the systems tech would spin up a couple of virtual machines out of their VMWare farm, build an iSCSI LUN on their datastores, then install an OS, the application, configure it, and move on to the next one.
So, define your requirements, and lets see what kind of suggestions you get to solve the what-to-purchase problem.
