The Olympic motto “Citius, Altius, Fortius”, meaning “Faster, Higher, Stronger” is a great reflection of our life acceleration in every aspect.
We can see it on the example of the Tour de France, a bicycle race that has been held annually since 1903. Over the years, the average speed of the race significantly increased, due to advancements in technology, training methods, and the physical capabilities of the cyclists.
So, in 120 years, the race speed almost doubled. The same acceleration influenced other areas of our life. The advent of smartphones, high-speed internet, and social media has made it easier to communicate and access information, leading to increased expectations for speed and efficiency in every area.
Change-Adapted IT Architecture
The closer to the customer, the “change appetite” grows, and IT architecture must be able to support such dynamics of change on every layer.
Let’s think of IT architecture as a building, where the base is core banking systems, data, and other infrastructure components. At this layer, change is very complicated and costly. Moreover, it is not really visible to users, so the appetite for change here is quite low, as represented by an arrow in the image below. At the same time, it should give the capabilities for and support more frequent changes that happen in the upper layers.
Clients expect us to release new products and services sooner, the companies that first come up with something new and innovative win a share of the market, and so on. But how can we meet those expectations? How can we produce software products faster?
The next layer is APIs. In our building metaphor, we can compare them to a room layout. Changes are more feasible here, but still not as frequent as in the upper layers.
As to Processes and UI, we compare them to interior design and a piece of furniture, respectively. The appetite for change at these layers is quite high, because users directly interact with them. Just as with some premises, users may judge UI by its color. They are not much concerned about what is going on in the base as long as it performs its functions, but they perceive and notice external features in Processes and UI.
From the point of view IT solution creators, we need to build the architecture so that changes in UI or Processes could be introduced fast and with minimum overhead, not causing negative effects for lower layers.
Tech Approaches to Architecture Layers
What are the requirements for each Architecture layer to provide for quick changes? First of all, the core layer needs to provide consistent, reliable, and accessible data to be easily used in any processes or UIs. Next, APIs should be reusable for various interfaces to streamline and unify development.
An example of how a business can facilitate and promote such an approach. A company I used to work with created a wiki with all their existing APIs. So, if anyone needed some data from those APIs, it was very easy to look through existing components and find something that could be reused.
Since two bottom layers are like a foundation and are quite complex, they usually require more engineering efforts to them.
Two upper layers, on the contrary, should be easily configurable. Due to high dynamics of change, low code solutions are preferable, since they allow making quick changes on the surface and not spend a year to refresh the interface.
What Else Matters: People and Processes
Focusing on technology, we should not forget about other components of efficient and fast-paced product development: people and processes. Some companies try to implement innovative technology without aligning it with people’s skills, mindset, creativity and without changing the existing processes. This is a way to lose the benefits provided by the technology.
Aiming to create a fast-paced team, it’s important to adapt your people’s mindset for innovation, develop the required skills. People need to be open to change and have the skills to make it happen.
Another advice is to look for business people with an understanding of the technical aspect & vice versa. Thus, the flow of knowledge between business and tech happens. It helps to save time and money for “translation” in both directions.
In terms of processes, we need cross-functionality, iterative development, and agility.
When all components function as we described, the system acquires the key ability – the ability to experiment. In experiment – innovation, new products, and better focus on clients’ needs can be achieved.
We cannot know for sure what will work for users, so the whole system – including architecture, processes, and people’s mindset – should be ready to experiment. And make mistakes without putting a lot of money at stake. The cost of a mistake must be minimized, then the “metabolism” of the system increases and the company can develop faster and focus on real customers’ needs.
An example of such l experimenting from my experience. A company was not sure if they needed a bot in messengers for bank operations service. However, it was cheap to try with a low-code tool they were piloting, so they did. In just a few months, the company had 100 thousand clients using the service. That made it clear that some segments of clients actually needed such tool and the company then developed a strategy for messengers as a channel l, knowing who used it and what purposes.
AUTHOR
Head of Partnerships and Fintech at Sigma Software (SE)
Hanna Khrystianovych serves as the Head of Partnerships and Fintech Program Manager, responsible for managing the Partners’ Products revenue stream. Her primary objective is to establish partnerships with innovative product offerings that will enrich Sigma Software’s value proposition to both current and prospective customers. With an extensive background of over 15 years in Telecom, Banking, and IT, Hanna is a subject matter expert in Banking and Fintech domains.
Want to hear more? Keep up with all things Nordic fintech and subscribe to our newsletter!
