Middleware in the investment management industry

Wikipedia defines middleware as “software glue” that binds mutually independent software systems. There’s no loose definition of muddleware – the messy goo that cobbles together disparate parts in a kludge that becomes harder to manage over time. Typically, this muddling through leads to several opaque systems, each with its own ad hoc design. In turn this adds to the complexity that was sought to be solved at the outset. With no uniform user interface in place, these systems themselves become loose pieces in need of gluing. The cycle repeats. In contrast, good middleware rids end users of the stickiness from Elastoplast overload, and helps them derive maximum benefit from the systems it connects.

Two software engineering design ideas provide pointers for the selection of firmwide middleware. Getting the selection right maximises the chance of an investment firm spreading the return on deployed systems widely across the enterprise. Getting it wrong enhances the risk of underperformance and overinvestment in workarounds. The design ideas are drawn from pattern architecture and user interface design.

Pattern architecture is a popular approach to professional software engineering. A ubiquitous pattern is MVC (Models Views Controllers) which outlines a protocol for the separation of data models, views and “controllers”.  Data models contain the structures in which underlying data is represented. Views offer decoupled representation of the data – with the possibility of multiple adaptable representations of the same underlying data. Finally, controllers are the functionality that regulates the user’s interaction with the data. By separating this functionality from not only the data but the presentation layer, revising any aspect of the system implementation leaves data modelling and representation intact. Overall, three-way separation localises the effects of revision, limiting unintended effects. The objective is to implement the MVC pattern in an enterprise architecture.

The second insight comes from Larry Constantine and Lucy Lockwood, the authors of six influential principles guiding user interface design. Given that middleware is a software-to-software interface, it is worth applying these principles. They are:

• Structure: The organisation of components should be intuitively appealing. Related components should be grouped and familiarly modelled.
• Simplicity: The interface should be minimal and cached in the user’s language.
• Visibility: The tools for effecting required functionality should be immediately accessible – not encapsulated in logically irrelevant modules.
• Feedback: The system should provide users with information about the impact of their actions and relevant changes in context if these could affect user interaction.
• Tolerance: The system should be fault tolerant, allowing recovery from error.
• Reuse: Functionally similar behaviours should be presented by a single component reused in different contexts, rather than independent modules that are made to resemble each other.

Taken together, these two insights suggest a guideline for identifying durable middleware. Muddleware is software that crosses principles of interface design. In the investment industry, the cost of these infractions is especially onerous, and goes beyond mere look-and-feel violations.

We should apply these principles with fluidity in mind. The Constantine/Lockwood sextet was written with embedded systems in mind. These systems are characterised by a stable context. The underlying system architecture is known at the time of development, and – importantly – is immune to subsequent change by third parties. Similarly, the presentation layer is known and immutable. Middleware, in contrast, requires feedback from underlying systems that may change over time, and a suite of presentation applications that varies not only over time, but also between users at the same points in time – depending entirely on the preferences of the users in question. Good middleware will lend itself to the addition and removal of component software without crossing the design and separation principles.

Good usage of the MVC model allows the flexibility needed to maintain a durable interface. Separation of data from functionality addresses the concerns around structure, as the modelling is allowed unconstrained by concerns of functional implementation. Good interplay between views and controllers allow the context-sensitive feedback required by the interface model.

Separating the presentation layer (views) from independent data models allows the re-presentation: by implementing multiple views of the same data the system allows users with different “language” to have intuitive representations of the data without replicating or modifying the underlying data structures.

In implementing MVC it’s worth considering the simplicity principle – specifically the requirement that software idioms should be presented in the end user’s language. To this end, middleware that couples to third-party software at the data and presentation layers is preferable to systems that do only backend coupling, forcing the user to be acquainted with a proprietary set of representation models. Similarly, directly exposing a host of a depositories at the data layer allows the user to model in a familiar environment.

Middleware is often improvised, with popular applications like Excel linking different applications. A problem with this approach is that the software is not customised to present flexible separation of models, views and controllers. At first glance an application like Excel is an alluring choice for low-cost middleware. Since spreadsheets are modelled on the blank slates, the application is designed with loose representation constraints in mind. The presence of an all-purpose, easy-to-use macro language like VBA suggests limitless possibilities for controllers. The weak point is separation of data – which is not explicitly provided for in a spreadsheet. A consequence is that data manipulation in a spreadsheet application is usually too closely linked to the representation.  Structures like pivot tables are presented with viewing in mind, but relational structures are absent. This defers structural encoding to the presentation layer, a step too late. As a result, these “architectures” often violate the redundancy principle, as the structure is recreated several times at the presentation stage, rather than once in a reusable module of the data layer.

In summary, as the enterprise architect, it is always a good idea to keep asking: Am I implementing middleware or muddleware?

• Read more under:
• BankingTech
• InsurTech