Having a sound technology platform architecture in place is key to support today’s investment management business. A forward-looking platform should separate business requirements from technology aspects. It should also encapsulate complexity and be flexible enough to allow changes in supported offerings and associated business processes to be implemented through configuration management rather than software releases. A three-layer application architecture composed of a i) business layer, ii) a functional layer encapsulating complexity, and iii) a service layer allows leveraging in a simple and efficient way services and data, fulfills these criteria.
The fast pace at which today’s investment management business evolves requires a technology platform architecture capable of handling change efficiently. Indeed the times are gone where a development cycle of 12 to 24 month for introducing new offerings are sustainable. In addition, pressure on the cost side, requires looking for lean and flexible approaches.
A forward-looking technology platform architecture needs to meet three key criteria:
- It should separate business requirements from technology aspects.
- It should encapsulate complexity in order to maintain its manageability.
- It should be configurable and extensible without requiring software releases.
The three-layer approach shown in Figure 1 fulfills these criteria.
The first layer, called the business layer, handles all business interactions. It can be subdivided into three categories:
- The graphical user interfaces,
- business processes, and
- exception handling.
Changes in business processes, like adding an audited control point to an existing process, should be solely implemented in the business layer, leaving the remainder of the application landscape untouched.
The second layer, called the functional layer, implements encapsulated modules of specific business functionalities. Each module provides a specific functionality. There are a priori no limitations to the complexity of the function provided as long as the complexity is encapsulated in a transparent way.
For example, one such module could implement the calculation of the holdings of a fund portfolio. The business layer would provide the specification of the portfolio’s characteristics, like tracking error and number of holdings. It would also provide forecasts on the potential funds to be included in the portfolio. Data and services, like calculating tracking errors, would be provided by the service layer.
Well defined user interfaces to both the business as well as the services layer round-up the definition of each module.
The third layer, called the service layer, provides services and data to both the functional as well as the business layer. It is important noting that the service layer is much more than a standardized database. It is made up of three categories of functionalities:
- Configuration services,
- data management services, and
- cross-functional plug-in services
Configuration services provide configurable information, like, for example, supported asset classes, that are valid across modules but modifiable through the course of the life-cycle of the platform without requiring software releases. Configuration information should be versioned and organized in a hierarchical way.
Data management services provided a transparent interface to data. They encapsulate provider specific data structures. To avoid over cluttering the service layer, the number and interface complexity of services provided should be kept rather small.
As it is not possible to think of all potentially required services beforehand, the service layer should provide a framework for adding new cross-functional services in a plug-in like way. For example, a plug-in could provide risk figure calculation services that are used by different modules, like a market forecasting module, a portfolio construction module, or a client reporting module.
Advantages and challenges
Implementing a multi-layer technology platform architecture provides numerous technological as well as business related advantages. But, as with all changes, it requires a change in mindset of the application developers to fully exploit its advantages.
- The architecture imposes a separation between business and technology aspects. This separation allows focusing on core capabilities and implementing changes in a transparent way. For example, a change in a functional module algorithm does not require a re-engineering and associated testing of the remaining components of the application.
- The complexity required by today’s business challenges is encapsulated in modules keeping the overall architectural complexity at a manageable level. For example, sophisticated derivative valuation algorithms can be implemented and made available to the business layer through well-defined simple interfaces.
- Services, modules, and business processes interacting only through well-defined interfaces impose an architectural discipline on any application using the platform, thus avoiding hard to maintain ad-hoc solutions.
- Building on a configurable platform offers flexibility for change without re-engineering requirements. Data structures are configured rather than being hard-coded.
- One of the two key challenges is changing the mindset of software developers to adapt to this lean multi-layer platform architecture.
- The second major challenge is implementing a sound governance structure with respect to the services provided by the service layer.
Consider a fund module construction application deriving customized fund modules based on investor preferences and fund forecasts.
The business layer is made up of the three components
- handling the investor’s preferences,
- forecasting fund performance, and
- calculating fund modules.
In addition, the business layer includes an exception handling process called upon when the fund module construction fails.
The functional layer provides an algorithm constructing a fund module given investor preferences.
The service layer provides functions for retrieving the configuration information, that is, the data structure describing the fund static data, the fund forecasting data, and the investor’s preferences, and saving as well as retrieving instances of investor preference and fund forecasting data.
Figure 2 illustrates a possible usage of such a fund module construction application.
- Separating business functionalities from technology allows each stakeholder to focus on his core capabilities.
- Encapsulating sophisticated algorithms into transparent functional modules makes the complexity required by today’s business needs manageable.
- A configurable architecture in which the data models are configured rather than hard-coded makes the approach ready for future changes.