Skip to content

Investment platform for individual and institutional investors

for UK-based corporation

SCHEDULE CALL

About the project

Investment platform for individual and institutional investors to trade ETFs within tax wrapper accounts for a UK-based corporation.

Client

Undisclosed

Project duration

Undisclosed

Client’s website

Undisclosed

Project scope

Platform for individual and institutional investors

Business challenges

Business oriented, innovation department of our client’s company was put under extreme pressure to deliver platform for individual investors to trade ETFs.

Originally, most of the business and non-functional requirements remained undiscovered. It was a joint journey to learn the business domain and figure out the way to put financial data into the clouds.

 

Business Solution

We started with 4-5 people team to transition PoC development from the US to Poland. In the early days, our goal was to delivery MVP quickly to gain initial traction.

As a group, we had to discover not only requirements that flew from various directions but also a safe way for financial corporate to operate in the new environment driven by rapid development, short feedback cycles and Agile way of thinking. Over time, cooperation grew into a real partnership where both parties jointly form backlog based on experience, business needs, and mutual trust.

 

Roadmap

On client’s side we had five stakeholders with different views on top priorities for upcoming quarters. We helped them to visualize all their ideas and then come up with a goal they want to achieve. In the next step, we asked them to assess as a team on how each of their ideas matched the goal.

At the end of the session, the scope for an initial version of the product was identified. We drew a roadmap of all other supplementary features and planned their releases on the timeline.

 

Facilitating corporate change

After the initial period customer wanted to replicate our approach and tools we used for other projects. Pragmatic Coder’s team has served as facilitator of this process by building proper CI/CD infrastructure and processes around it that would allow for greater collaboration with external teams along with creating a flexible cloud infrastructure fully supporting the concept known as “Infrastructure as a code”.

 

Product ownership

Initially five teams working on three different products had just one Product Owner. This person often did not have enough time to explain and refine the requirements to the teams. It also happened requirements used to be communicated to the teams by different people.

During the reviews stakeholders were surprised and asked the teams why they worked on those requirements but not on the other ones. We observed this pattern a few times and proposed to the client to change teams’ structure a bit and hire a single Product Owner for each team and streamline all requirements only through them. As a result, teams became more productive as they knew exactly what priorities

 

Project flow

We worked in six small teams with 4-5 developers in each team. Five of them worked on three different products and one team took care of infrastructure for product teams. Each team had a product owner from the client’s side.

The teams worked in two weeks iterations. During each iteration, we aimed to achieve a specific business-oriented goal. At the end of each iteration, we showed to our customer a working software addressing the goal planned for that iteration.

After the demonstration we gathered feedback from the stakeholders about the delivered product and spoke about next development steps.

Once a quarter the teams met with client’s product stakeholders for a planning session where all current priorities were discussed. All involved people met face to face in one place. The client was responsible for bringing business goals they wanted to achieve and ideas on how the goals could be achieved from a business point of view.

During the workshop client’s representatives and engineers agreed on the most important items from the list of priorities for the upcoming quarter and selected those that team will be working on. During the next step, teams planned their work in more details using popular techniques like event storming or user story mapping. As a result of this exercise, the teams had a rough idea of how much time would be needed to achieve their goals. They also identified potential impediments and dependencies with other teams.

After this part all teams came together again and synchronized their plans. At the end of the entire session, the team and stakeholders spent an hour on thinking how next quarter planning might be improved so it would be more informative, efficient, productive and engaging for all participants.

 

Product differentiator

The client asked us to restrict some operations for a certain group of customers. Similar requests repeated ones or twice again.

We analyzed our backlog to see if there are any other similar requests waiting in a queue. Based on that analysis we asked our PO additional questions about the nature of the problem and proposed to create a solution to restrict specific operations to multiple customer segments. We prepared a matrix of different combinations of restrictions for different groups of users on the account and user level. When the feature was validated with end-users it turned out it became a good product differentiator on the market.

 

Microservices implementation

Our goal was to implement microservices in a way that guarantees data consistency in the complex financial domain. We wanted all of them to work independently with a good amount of data redundancy so that failure in one place was not visible to the end-user.

We knew that it’s absolutely crucial to establish guidelines for cross-cutting concerns such as – monitoring, configuration, contract validation etc. We run multiple sessions across developers to make sure everyone is on the same page. Technologically, we chose Spring Boot + Spring Cloud powered by HashiCorp and AWS tools.

Continuous delivery

Apart from a business change that needed to happen, we knew that continuous delivery to be effective in the microservices world has to be scalable and reliable.

We knew that our Jenkins instance will be modified by different teams. That’s why we selected Groovy DSL powered by our own Groovy component library to deliver code as a solution to that problem. Thanks to that we are able to setup Jenkins instances together with all jobs and pipelines under 5 minutes.

Infrastructure

We wanted to have infrastructure that will be used over decades as a means to transition legacy, corporate business into the cloud. We leveraged the scalability of Kubernetes and created a separate small team of DevOps and Developers. Their sole goal was to deliver infrastructure as a code.

We knew that we will host multiple different projects so ease of change, transparency and auditability are key drivers. We used AWS, Terraform, Chief and multiple open-source tools
to deliver on that promise.

Standalone R&D team

Pragmatic Coder’s team was acting as an almost standalone R&D branch, holding great control over most of the technical and architectural aspects of these systems.

Products we were working on were the first cloud-based, fully distributed (microservices) products ever made by the customer, so somewhere along the road the Pragmatic Coder’s dedicated software development team adjusted from simply developing standalone product to setting up a set of tools and practices that were later scaled up and reused by other parts of the customer’s company.

Get In Touch

Let’s bring the future closer together
Address

Address

Aleja 29 Listopada 20 31-401 Kraków Poland
Connect

Connect with us

Contact

Please contact us at