MetaFluent Design Philosophy

The MetaFluent architecture embodies a few basic principles. Achieving these is not easy but has big payoffs for customers.

  • Use standards where possible

    Standards lower development and operating costs, shorten the learning curve, and improve interoperability. If a well-known standard exists that could solve a particular problem, we will use it creatively to make life easier for our customers. An example is our use of JMS as a market data API. Developers with no market data API experience can be subscribing or publishing market data in minutes.

  • Give the customer control over data models

    It's all about the data. We're not in the data business; our customers are. The customer should control the models for the data it uses. We keep our designs free of assumptions about the data model. Support for flexible naming and data symbology is a fundamental design choice.

  • Keep things simple for developers

    Customers have better things to do than solve problems that vendors create. Our products should make life easier for our customers. Our technology should be as transparent and unobtrusive as possible. An example is our simple multi-stream topic convention for supporting a range of collections, from Thomson Reuters chains to yield curves to portfolios.

  • Engineer lower operating costs

    Development costs are just one part of the overall life-cycle costs for a system. We design with the operating environment in mind, as well. This means building features into the product to support diagnostics, version migration, and other capabilities that keep costs down and make the administrator's job easier. For example, our JMS API implementations that use our server report deployment (e.g. API implementation and version number) and operational data (e.g. message rates and processing time) back to the server

  • Integrate with existing systems

    Our products are never deployed in a vacuum. We design with the assumption that our products need to interoperate with existing systems throughout the enterprise. This requires our products to be flexible and not incorporate arbitrary assumptions about the operating environment. We should introduce as few dependencies as possible.