Developing modern apps for financial markets – Part 4: Architecture and Development


The obvious truth is that sooner or later, every project has to leave the design phase and enter the creation process.  But we prefer a more refined approach: in our work at GFT, development and architecture planning do not start after the design phase – instead, they both form a crucial part of the entire process, conducted in parallel with all requirement definitions and discussions. To learn how we manage to do this successfully, join me in the final part of the Developing Modern Apps for Financial Markets Series!

This part of our work is driven by the architect – an experienced technical specialist, whose task it to translate requirements and application design into a concrete architecture plan and technology stack. Before we take a closer look at their job, check out our video that covers the entire story behind our series in less than 3 minutes!

The role of an architect

Since the very beginning, the architect is involved in defining requirements – asking detailed questions that should be considered and that can affect the implementation.

The topics discussed usually include:

  1. Any non-functional technical requirements, such as: target platform, performance, size of datasets, accessibility etc.,
  2. Everything related to integration with 3rd party systems and data exchange,
  3. The data source that will be used to feed the application,
  4. Libraries, frameworks or any other tools that should be used by the development team.

Based on the above information, requirements and conversations with stakeholders, the architect prepares an application architecture plan and defines the technology stack that will meet the client’s needs.

The additional, not-so-obvious role of the architect during the project kick-off phase is to be the person responsible for the “technical sanity check”. There has to be someone that makes sure that the requirements agreed with BAs and UX designers are actually implementable, or their estimated implementation time is within the client’s budget and timeframe. This way, the architect’s feedback can be quickly incorporated in the design phase – which in turn prevents problems that may occur later.

Another task before the architect is to cooperate and stay in touch with architects on the side of the client, in cases when the project requires integration with other services – or simply supervision. This is especially crucial if we plan to have a project handover at the end.

Architecture planning

First, having completed the initial client interviews and information gathering stage, the preliminary high-level technical requirements are defined.

Does the client need a web-based or a native application? Will it be used on multiple devices, including mobile hardware? Does it have to work offline? What kind of data will be displayed and how will the communication between the app and the remaining systems work? What will be the source of data?

These and other high-level questions enable the architect to prepare the foundation of the application’s architecture.

Further down the road, once a more detailed project specification is agreed, and elements such as screens, application modules, data structure, 3rd party services etc. are defined, the architect is able to translate them into a much more detailed architecture plan. This usually includes a close-to-final application structure, data structure and communication schema.

 

At this point, the technology stack is usually agreed on. Our usual practice is that the development team in Poland, aided by the architect, prepares a set of quick POCs to test and evaluate possible tools and select those that match the client’s requirements best.

The actual development process can start here as well. With all basics defined, the nearshore development team can start setting up the development environment and the actual implementation.

The final part of architecture planning is about defining the detailed application structure. Screens (or mock-ups, if final designs are not yet available) are divided into components, data flow between them is agreed on, and services for communication and different business domains are being defined.

This part of architecture planning is usually done in an agile manner. When new screens or modules are being added, the process is repeated, and a new functionality is incorporated into the existing application structure.

 

The Commodity Market Overview application

Technology stack

The process described above has been used to design and create the Commodity Market Overview application as well.

Discussing the initial requirements, we have defined the core goals that we wanted to achieve:

  1. The application should be easy to use on multiple devices, including tablets,
  2. It should provide a responsive interface and native-like user experience,
  3. The application should be usable offline, so the person showing it does not have to be concerned about internet connectivity,
  4. The data will be loaded from an exported data set,
  5. The application will be data driven, offering rich data visualisations,
  6. We should use a technology stack that matches our company’s skills set and tools that we use in our everyday projects.

After several discussion, we have decided to create a web application, using Angular as the main application framework and TypeScript as the programming language.

This technology stack provides us with the portability and ease of use of web applications (write once, run everywhere), combined with the solid, modern, component-based architecture foundation that comes with Angular.

Additionally, using TypeScript, a strictly typed version of JavaScript, gives us a huge burst in terms of development performance, tools and bugs prevention.

To address the remaining requirements, namely: the ability to work offline and native-like user experience, we decided to adopt a fairly new solution, called Progressive Web Application (PWA).

PWA is a set of technologies that allows us to not only create an offline–friendly application but also to make a web application installable on the client’s device – just like a typical native application.

The last thing to decide on was which data visualisation tool we would use. This was a crucial decision, since the whole application was meant to be built around this feature.

After several discussions with our UX team, and after reviewing initial concepts of charts and graphs, we decided to use the D3 library.

D3 is a library that provides a fairly low-level API for creating data rich visualisations. While being an advanced tool that is not so easy to master, it also provides developers with almost limitless possibilities, plus we knew that we have several experienced D3 developers at GFT Poland who would aid us if needed.

 

Application architecture

Having all the topics above agreed on, we were ready to sketch the high-level application architecture.

In the next step, using a typical cycle of analysis – design – architecture, the team was able to create a detailed architecture and structure plan for every upcoming application screen and functionality.

Cooperation with BA and UX

As we mentioned in the beginning, the architect and the development team do not work on their own – in fact, they cooperate with the BA and UX teams on a daily basis.

Their work during the kick-off phase has already been described, however, it does not end there. Even the best planning phase is not perfect: not all cases can be predicted, some functionalities look good on paper, but have to be modified after the implementation, priorities change and so do the requirements.

Similar things happened, for example, when we were testing our approach to calculating relative values for a comparison chart. Our initial algorithm was not working properly for some edge cases. Only after several brainstorms with BAs and different tested solution, we were able to agree on the one that is currently used in the application.

From the UX perspective, the initial visualisation of trends and predictions on the chart was not readable for big datasets. After a discussion with our UX team, we were able to agree on a cleaner, more readable solution.

Interactions like this are not something special. All projects, especially those conducted in Agile methodology, have to face changing requirements. Consultations between the three main project layers: Development, Business Consulting and UX happen almost every day. Being able to do them on site, face-to-face, without any communication obstacles, vastly increases the project’s performance and quality.

Final credits

This is the last part of our blog series on the Commodity Market Overview application. Thank you for staying with us. We hope you found it useful and that we managed to shed some light on how great modern apps for financial markets are created at GFT. If you have any questions, or if you want to share your feedback or personal experiences, don’t hesitate to drop us a line in the comments or on our Linkedin profiles, available below!

Last but not least, I’d like to send thanks to all people involved – the fantastic teams working on the application itself, as well as the colleagues helping in all initiatives happening around the project.

Part 1 – A Case Study by Damian Sosnowski
Part 2 – Business Analysis by Marcin Myszkowski
Part 3 – The UX Process by Małgorzata Barska
Part 4 – Architecture and Development by Damian Sosnowski

The Team

Business Consulting

Joanna Aleksandrowicz Principal Business Analyst, Head of Business Consulting Job Family
Marcin Myszkowski Senior Business Analyst

User Experience and Design

Małgorzata Barska Principal Designer, Head of UX Practice

Architecture and Development

Damian Sosnowski Principal Architect, Head of Digital Job Family
Damian Bachórz JavaScript Developer
Michał Dzik JavaScript Developer

Marketing

Maciej Sopek Senior Content Marketing Specialist