Okay I would strongly recommend you check out the following:
(1) Ensure your Production Database is seperate from your Reporting database. An OLTP (ie: Online) Database should be seperate from a reporting (OLAP) Database for load reasons.
(2) Your OLTP Database should typically be indexed less than your OLAP Database as index updates slow down inserts and updates.
(3) Ensure all calls to the database are via Stored Procedures rather than any type of SQL query. ie: You need to protect the database server from someone or something (eg: badly written app) doing SELECT * FROM TABLE and doing complete table reads, or queries with loads of joins etc.
(4) It may make
(5) You mention that the Server ..." is actually structured to entertain corporate level business needs and bulk requests are generated by different type of applications like web, data engines and many other applications that fulfill the business needs. " This implies to me that your Server is doing alot of work. SQL Profiler can be used to determine what the Server is actually doing, and where the cost in terms of performance resides.
(6) I also recommend doing some perfmon analysis. Stats such as CPU, Memory, Network queues and Disk queues are useful.
(7) Run a DBCC CHECKDB every so often and resolve any.
(8) If your data is changing often, updating Statistics is another useful thing to look at.
(9) When the SQL box is going nuts it's useful to check which process is using up most of the CPU. If it's sqlservr.exe (ie: the SQL Server service) then it's probably useful to do an EXEC sp_who from SQL Query Analyser and see what's running and also check whether there is any lock contention.
These are just some simple things to do. But remember you need to work hard to protect the Server from any unusual, unecessary work so I would look at that as an absolute top priority.
Best of luck.