Principles of Quantitative Development

3.8 SUMMARY

During the course of its complex life, a trade undergoes several transformations and operations performed on it by various business units. As a software object, the trade services the information requests from these business units. For instance, product control may request daily P/L, market risk management may require the Greeks aggregated at different levels, the middle-office control units may need to set flags and put trades in operation queues based on status, and so on. All these requirements put together define and determine the architecture of the trading platform. As quantitative professionals, we need to understand the rationale behind these requirements and be able to prioritize them.

From our perspective, a trade is conventionally a software entity persisting in a database and loaded into a computer memory as an object. In a more modern architecture, a trade may be a distributed entity whose projections are served, on demand, by a trade data provider or service. Regardless of how we model it, the trade entity will have to satisfy the business requirements coming from the numerous corners of the organization. The only way to design a lasting, robust and maintainable trading platform is to anticipate and understand as many of these requirements as possible before we start implementing them.

Although we view the trade as a software object, ours is not the only perspective in the bank. The trade perspectives are paradigms that help various business units carry ...