Dear community,
a daily job of a product manager and architect is the challenge on how to meet business requirement with the standards available in the FIX world and the treatment of change within your trading product.
Simultaneously it is quite often the case that the business analysts or even the business people themselves repeatedlly and utterly already suggest a solution like „Let’s Choose a User-Defined-Field“. Technically rather undernourished people even let you know to „Just add the additional value to the field and seperate in a CSV like manner“. Yes: Two information in one field! To explain the importance of a clearly defined syntax to those guys is necessary time and again.
Now, although User Defined Fields are an accepted solution within FIX in many cases then after a deep dive into the FIX fields universe it is in most cases possible to express the business requirement at least by the existing standard.
It is not only the importance of a clear messaging syntax but also the importance of a clear concept in terms of
a.) messageing model
b.) data persistence and
c.) presentation (GUI
being tightly linked to each other in a system architecture.
The target of a product architect is to keep the product customizable for a long future period of time and even meet the most uncommon requirements you did never even think of there are two ways:
1.) Change the standard, submit a request or
2.) use a bilaterely agreed User Defined Fields.
The first solution may take longer to instantiate than your project or requires addional efforts to achieve it. The second one is a quick and dirty one only and it i shelpful only on the messaging side.
Yes, only the messaging side because you also have to keep the b.) and c.) in mind and th lack of integration often makes it difficult to manage the multi customer complexity under the umbrella of one single (trading) tool or product.
Many words for an introduction but I suggest it is helpful to understand why the following part is added.
Working with the combined concept of the StrategyParametersGrp and ATDL for some time I feel like this is a very helpful and also quite simple approach to meet the challenge of change and complexity very quickly.
If we decouple the concept from its business relation and think of a general concept of passing any parameters in a message, pass it on between the componets within our system and also present it to the user we only need to establish one single new group in the FIX standard. For reference here lets call it
CustomizableParametersGrp. With one extension: a repeatable Tag 847 should be integrated to allow and seperate more than one group of key-type-value members within the construction.
Which are the advantages of this concept?
Advantages
1.) Easy to integrate in your FIX messaging solution
2.) Describes Information persistable in one data table by the tupel of a.)key b.)data type c.) value
3.) Allows to implement the editable parameters presentation even with drop down selections and provide constraints by generating and integrating the code with your ATDL parser.
4.) Quickly respond to generic requirements popping up
Disadvantages:
1.) From an academic point of view it is not completey a pure and complete model driven concept. (But all you need is there)
2.) Once part of the standard it would undermine the FIX concept of the tag=field standard and the community could loose control of a commonly agreed industry driven development. If so how to rule that out.
3.) Is there any potential for conflicts with the orchestra initiative? If so how to rule them out ?
Summary:
Learning from the use of ATDL and StrategyParametersGrp I asked myself whether this brilliant concept is also feasable for a wider intention if use. It is definitely possible to meet the need for a (set of) User-Defined-Field in a more educated way. Not only in terms of messaging but also as an already well established model driven design feature in the management and code control of a multi customers system as a whole.
Apologies if this is a post with a content discarded long ago or if the concept is not compatible with FIX philosophy.
Regards
Ulrich