Having sound technology platform architecture in place is key to supporting a firm’s business model. 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 business world 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.
PLATFORM ARCHITECTURE
A forward-looking technology platform architec-ture 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 Exhibit 1 fulfills these criteria.
BUSINESS LAYER
The first layer, called the business layer, handles all business interactions. It can be subdivided into three categories, that is,
- 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.
FUNCTIONAL LAYER
The second layer, called the functional layer, implements encapsulated modules of specific business functionalities. Each functional module provides a specific business functionality. There should not exist any a priori limitations onto the complexity of the functions provided, as long as the complexity is encapsulated in a transparent way.
For example, one such functional module in an asset management technology platform architecture could implement the calculation of the risk parameters, like tracking error or Sharpe ratio, of an investment portfolio. The business layer would identify the specific portfolio onto which to perform the calculations and which calculations, for example, tracking error, to perform. The service layer would provide the necessary data and support services, portfolio holdings and pricing time series.
Well defined interfaces, so-called APIs, to both the business as well as the services layer round-up the definition of each functional module.
SERVICE LAYER
The third layer, called the service layer, provides data and services to 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, that is,
- configuration services,
- data management services, and
- cross-functional services provided by customizable plug-ins.
Configuration services provide configurable information, like, for example in the case of an asset management technology platform, 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 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. A cross-functional service is a functionality, for example a calculation, that is used by multiple functional modules. For example, a plug-in could provide risk figure calculation services that can be 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.
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.
CHALLENGES
- The first key challenge to address is changing the mindset of software developers to adapt to a 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.
SAMPLE APPLICATION
Consider a portfolio construction application offering customized portfolios based on investor preferences and security forecasts. The business layer is made up of the three components
- handling the investor’s preferences,
- forecasting security performance, and
- initiating the construction of customized portfolios.
In addition, the business layer includes an exception handling process called upon when the portfolio construction module fails.
The functional layer provides an algorithm constructing a tailor-made portfolio given investor preferences and security forecasts.
The service layer provides functions for retrieving the configuration information, that is, the data structure describing the securities static data, the forecasting data, and the investor’s preferences, and saving as well as retrieving instances of investor preference and security forecasting data.
Exhibit 2 illustrates a possible portfolio construction application using the technology architecture framework presented.
LESSONS LEARNED
- 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.