After a solid growth of the Ebury business, it was clear that the new demands would require a reliable infrastructure, a scalable software architecture, and a robust data strategy. A modern architecture has the added benefit to be a great motivator for the technical team.
As a result, headed by our CTO Victor Tuson, the senior leadership team met to create the Ebury Technology Strategy – one comprehensive guide to our engineering teams regarding how to approach general software development.
The first step is clearly to define what we want to achieve and how to measure what we will call success. At Ebury, we already have a metric-driven way of working for our tech teams, and each is accountable for the results. Therefore, our definition of success is built on top of the key performance indicators, for example:
- Epic lead times meeting our quarterly timelines.
- Quick pull requests cycle time measured in days.
- Availability SLA of 99.9%.
- Bugs and action points from incidents closed in two sprints.
Then, it is possible to understand the guiding principles that will help the teams achieve those goals. We created four of them that we will explore in the following sections.
One of the current standards in the market is the concept of a micro services-oriented architecture, but it can be misleading to assume that this approach will solve all your problems. So, we defined what we wanted to achieve in this specific principle.
First, we want to build decoupled software components that can communicate through APIs or domain events – avoiding shared databases or multiple unrelated domains. Then, we need consistent interfaces and dataflows to avoid accidental complexity and simplify the business processes. Finally, we want a solid fault-tolerant infrastructure that does not jeopardize the entire business because of isolated failures – everything using the best observability tools and practices available.
Fig 1.: Example of how we remove features from legacy systems.
Naturally, we also defined the success measures that could help us ensure that we are on the right path: technical debt in every team’s backlog, legacy repositories linearly decreasing in size, domain-driven designs, and number of new components created.
You build it; you run it
Inside Ebury, we have an agile way of working and a well-established development life cycle. However, we don’t want just to go fast but also to keep our features safe by following a set of technology controls.
We also have a code ownership culture that promotes knowledgeable individuals to be responsible for a specific software component or service. And then, every service is owned by a particular team, avoiding shared ownership.
Fig 2: The developer is responsible for the entire development experience.
The last step is to have a platform team building the tools and improve the development experience for the teams to run their software efficiently.
Similarly, a few success measures validate how we build software: time to restore services after incidents, number of high severity incidents, time to production of new services, etc.
Build or Buy
The decision to build a software component or buy an external product is essential in our process. We definitely want to build differentiation, which is at the core of our business and should be less inclined to invest much time, energy, and money in developing features that are not essential.
Also, we have a yearly budget planning that is revisited quarterly and tracked monthly. It is a crucial success metric that we are not overspending the budget but also investing it in headcount growth, professional services, and licenses/products.
At Ebury, we have a robust governance culture resulting in four success measures: plans vs. actuals, cost of maintenance, technology budget spent, and third-party management.
Last but not least is our remote way of working, the new standard most people are looking for. Although the pandemic has accelerated the adoption by some companies, we were already working remotely before.
We drive the work remotely by driving many incentives to the teams and developing all needed competencies. Also, the team topologies are designed to meet the domains we have, using a platform as a service infrastructure team distributed around the globe.
We hire talent where the talent is!
The entire team is working towards our OKRs. We can measure the result by employee satisfaction, the low attrition numbers, all colleagues hired by referrals, and a quick onboarding experience.
Looking at the horizon, the mission is already set – not only for the product but also for the engineering team in terms of maturity. Ebury wants to be in constant evolution with the ability to measure it positively.
If you are excited about our next steps, please check our careers website!