From an architect's point of view: Software architecture and the role of the architect in fintech solutions
The role of an architect in software companies is both a challenge and a pleasure - otherwise, it would be difficult for anyone to decide on the role of an architect.
When I look back all the way to my humble beginnings and beyond, I've had the opportunity to see how much paradigms and platforms have changed - but the essence has always remained the same.
That is why I decided to approach writing this text like making a Zen lunch - I will write a little about what is passing, mostly about what is current and a little about what is yet to come.
The complexity of software development problems is constantly increasing, but it always keeps pace with the development of new methodologies and tools at our disposal.
What is architecture in software development?
One of the key elements in the software development process is the definition of architecture, which we have long viewed as an important but somewhat nebulous concept. And so were the descriptions of the software architecture:
- Architecture is something that is difficult to change
- "Architecture is something about important things... whatever they are" - Ralph Johnson
- Architecture is the blueprint of a system
Therefore, it was unclear how to become a software architect - there was no precise career path for the role.
The best definition of architecture that I have come up with is that it consists of:
1.System structures
2. System characteristics
3. Decision
4. Design principles
What exactly does that mean?
System structure refers to the architectural style in which the system is implemented (layered architecture, microservices, monolithic system, etc.).
The characteristics of the system are the criteria for the success of the solution, they are orthogonal to the functionality and are often referred to in English literature as "ility's" (availability, reliability, testability, scalability, security...).
Decisions are made in the form of rules to determine how the system is implemented – e.g. that only the service or domain layer has direct access to the database.
Design principles differ from decisions in that they are not hard rules but rather guidelines such as that in a microservice architecture asynchronous communication between services is preferable to direct calls.
Therefore, the role of the architect is:
1. To make decisions
2. Continuously analyzes the architecture
3. Follow the latest trends
4. Ensures compliance with decisions
5. He has experience and is familiar with various technologies
6. Possesses domain knowledge as well as interpersonal skills
Last but not least, architecture and the architect are much more concerned with the question of why, not how.
(R)evolution of software architecture
Back in 2000, when I entered the world of fintech, sophisticated solutions with specialized and connected components were already present, but a completely acceptable system architecture in the industry was also one where both the presentation layer and the application and domain logic were located in one executable application that communicated with the database directly where it was possibly part of the business logic in the form of procedures.
For the first time, I received a direct question from a client in 2003 about one of the important features like code coverage with unit tests.
Those were roughly the last years for such a style, and it was then that they began to insist on a multi-layered structure with a precisely defined service layer in which there was a domain (business) layer that was isolated as much as possible and which the presentation layer accessed in a standard way.
Isolation became the keyword and that principle remains unchanged to this day.
Isolation implies not only layer isolation but various forms of independence from infrastructure, databases, etc.
There was an accelerated development of forms, which grew into standards, as well as frameworks that implement those standards, whether it is service communication, ORM solutions, integrations, etc.
And today?
Today, when the cloud infrastructure has matured when we have containerization and orchestration, all the conditions have been met to provide features such as availability, scalability and many others in a standard way by decomposing problems through microservices.
Why is the fintech solution architecture special?
Fintech is a term used for any solutions in the field of financial operations.
Specifically, it covers banking, capital markets and payments, among others. It is quite a broad area of very diverse domains, but which share some common characteristics and this is really visible in the context of architecture.
Namely, there are absolutely crucial features such as:
- availability 24/7
- high performance
- tightly tailored security
- test coverage
- integration with other systems
Also, all solutions are very domain-intensive, because the world of finance is very complex in terms of products, participants, legal frameworks, various analyzes of a large amount of data, etc.
As big demands demand big solutions - fintech has always been oriented towardS innovation and new technologies.
Where are we now?
Fintech domains are often very connected and it was often the case that one (enterprise) solution covers more than one domain.
Today we can say that there are two trends:
1. Decomposition and specialization
2. Integration of the resulting components
There is no silver bullet in architecture. An architecture that suits one solution and the group of people developing it may not suit another.
However, in order to follow the mentioned trends and requirements, it is natural that the structure of new as well as the transition of existing systems in fintech should be a microservice with the cloud as the target platform.
The layered architecture and isolation we mentioned are still valid for a specific microservice.
A very important methodology in defining the responsibilities of such components is domain-driven design (domain driver design), because the decomposition into microservices is usually carried out by subdomain boundaries.
Integration, on the other hand, allows users to tailor a solution that fully matches their business model by simply selecting components from the offer.
So what makes a good software architecture?
There are many criteria for good software, but for me one stands out before the others:
For me, good software is one that we can endlessly refactor and extend to keep it current.
An example from the past is the UNIX operating system created during the golden age of AT&T Corporation.
What is his secret?
Simple design.
Solving a complex problem with a simple design is a recipe for longevity. We face such challenges every day and when faced with a problem we often react as optimists or pessimists.
I almost read something good that has been shaping me for a long time:
We are all trained "solvers", that is, people who look for solutions to difficult problems, and the good thing is that every problem has a solution.
A word about process and methodologies
Software development is a team.
A team is not a collection of individuals with predetermined roles. It is a living organism that functions as a whole.
Whether it's a scrum team that can be fed with two pizzas and enjoys shared ownership of the component (service) it develops, or a broader product-wide team, or an even broader organization-wide team, it must possess a spirit that motivates and makes people enjoy working with each other.
We create agile, iterative processes thanks to which we can guarantee the success of the results. At the heart of agile development is an agile team that has all the members necessary to translate domain knowledge into implementation and confirm the quality of the solution. All stakeholders are present in the process, so feedback is always current. Today's view of system architecture and other design and modeling processes fits perfectly into the agile methodology.
The architect's place in that process is definitely in the team. Namely, the process in which the architects made decisions and left the implementation to others turned out to be wrong, both in terms of the quality of the solution itself and the feedback.
However, an architect differs from other developers in terms of his breadth of knowledge, and as the path to the position of architect usually leads through other positions in development, he has already acquired depth. It is a common mistake for an architect to create a framework while others are waiting, so he has to share the work with others and develop a proof of concept rather than the entire framework.
Let's also say that most design features, decisions, and principles can be validated in a well-designed CI/CD process, and that's why there are numerous tools.
Where will we be?
And the end? Well, there is no end.
There is only a new beginning.
We are at the dawn of new technologies. Among them, of course, is artificial intelligence and the promise that every device will have software. Our phones already have specialized AI chips that change the way people interact with them, or help us do some things (taking photos, for example) better.
And so, a new chapter was created, a different type of software development. In the fintech world, AI is leading to the creation of new roles where software agents replace human ones. There are great expectations from blockchain technology and smart contracts, which should simplify the process of executing financial transactions.
Instead of a typical conclusion, because as I said - there is no end, I would recommend one book to future and current architects:
- Fundamentals of Software Architecture: An Engineering Approach 1st Edition, by Mark Richards (Author), Neal Ford (Author) (O'REILLY)
Text author:
Željko Tešić, Software Architect FIS Securities Finance Trading and Collateral Platform
