This is the first blog from FIXdom, a small company which already exists for over a year now and tries to make the world a better place by offering harmonisation and standardisation services to the financial community. Electronic interfaces are often neglected in companies, especially when it is about internal interfaces between different applications. There is absolutely no reason not to use standards internally as well as externally but their relevance is often only recognised for external, customer-facing interfaces. Using standards externally is seen as part of the marketing effort as it suggests easier connectivity to the service provided.
Internal interfaces are left to the individual teams to sort out without much internal guidance. The objectives are expressed in time and effort and not ease of testing, maintenance etc. Without the adherence to a single standard it is simply natural that teams come up with their own terminology to express the functionality they are implementing. This ends up in different teams speaking different “languages” requiring some kind of “translation” when it comes to the development of an interface between them.
This results in a significant additional effort to bridge that gap on an ongoing basis, not just for the initial development and test. Usually, the team with the bigger clout inside the company wins and is able to define the terms used for the common interface. Note that interfaces always depend on the applications at either end, i.e. they do not belong to any single application even though every application has to implement its end of that interface. One team may have minimal conversion effort from the interface into its internal data structures but the company pays the price due to the other team having a much higher conversion effort. The fact that a larger company typically has a multitude of (internal) applications with possibly hundreds of bilateral or multilateral interfaces means that there is a huge potential for savings by moving to a single standard for interfaces.
However, this requires a specific kind of organisation where there is a single, independent team supporting all others with the development of (standard) interfaces. The support needs to include the role of an arbitrator in case of conflicting targets. The good news is that a standard is the best arbitrator as there is often no “right” or “wrong” and the standard has taken a decision one way or another a long time ago. Everybody can simply follow it without losing face. Anybody who has been involved in discussions between IT teams needing to agree on the details of a common interface knows what I am talking about…
The lack of standards for the documentation of interfaces is another area of concern where there is also a huge potential for savings. As with terminology, two teams will choose at least two different ways of documenting the same thing. I say “at least” because the same team may change their approach every time a new application (with or without interfaces) needs to be developed. It can be as simple as the given skillset of the team members that makes the difference. Nobody likes to write documentation, yet little effort is invested in automation, harmonisation and standardisation.
Automation is most relevant for interface documentation and less relevant for business requirement or functional specifications. Interfaces need to be specified on a technical level for developers, testers, and users. Lack of automation means manually documenting messages, fields and values of an interface. It also means taking a cut&paste approach when compiling documents such as a technical specification, a test case document, or a user guideline. Some types of documents should exist prior to any implementation effort. But almost any implementation will result in detailed changed that have to be made along the way. Especially for interfaces, there may be additional attributes that need to be conveyed. A manual approach is very likely to result in errors and inconsistencies across documents. This is no rocket science and just common sense but there is still a significant lack of automation in the financial industry when it comes to documentation of interfaces.
Harmonisation is different from standardisation as it does not require to adhere to an external standard. Harmonisation is about internal alignment of approaches and technologies that may or may not be based on externally available standards. It takes away some of the flexibility of teams in favour of reducing the overall cost for the company. It requires an organisation that has a (possibly virtual) centralised function to support and monitor the teams. This in itself is quite a challenge and needs to be part of a company strategy. A central team mandating approaches and technologies has to be part of the teams in one form or another in order to gain their acceptance. Note that harmonisation does not have to include the tools that are used by the different teams as this can be a highly contentious issue. Tools are not essential for one team to understand the output of another team. It is all about terminology and layouts when it comes to documentation.
Standardisation goes beyond harmonisation and should be applied where possible as it reduces the need to debate the merits of doing things one way or another. Standards may not always be the most efficient way of doing things but they significantly reduce the cost by supporting the re-use of software artefacts for example. When it comes to interfaces they also offer a standard language for communication, e.g. people know that a FIX ExecutionReport message stands for a notification of events related to an order or quote, either as a response to the submission of a request or as an unsolicited notification from the counterparty. Terms become placeholders for business concepts and can always be accompanied by “local” terms as part of the documentation to further ease the understanding, e.g. “reserve orders aka iceberg orders.”
As you can see there are a lot of areas worth looking into and FIXdom would like to be a part of that. As co-chair of the FIX Global Technical Committee for the EMEA region for many years now, I feel honoured to be involved in the further development of FIX as a global language for the financial markets around the world. The capabilities of FIX have been significantly increased in recent years and now it is time to spread the word and support the FIX Trading Community to benefit from them. Feel free to post a comment, I welcome your feedback!