Learn more
Podcast

Advice Architects Ep. 2 with Anton Dovgobrod, INSART

The Heroes of WealthTech

Responsive AI
September 19, 2022

In this episode, we talk with Anton Dovgobrod of INSART about the key factors that drive success when building wealthtech solutions and software engineering projects.

 

When starting to build APIs, Anton says it's important to design a contract between API consumers and the underlying system being accessed. Consider the business needs of users as well as security and authentication requirements. Good requirements can be the difference between success and failure in any software project and Anton suggests that hiring business analysts in the early stages of a project can end up saving money down the line.

 

Finally, make sure you use a tool that can help your team track changing requirements. Project management starts with defining what “done” means on a project and what success will look like for users of the ultimate solution. In a post-COVID digital environment, having daily and weekly meetings that keep teams aligned are critical for success. Having a project plan, especially when it comes to team members changing throughout the course of a project, is an easy and often overlooked way to increase your likelihood of success.

 

Listen to the full episode below or you can also listen on Apple or Spotify.

  

For more information about Anton Dovgobrod, you can find him on LinkedIn, or check out the INSART website.

For more information on ResponsiveAI’s solutions for advice providers, contact us.


Day Wachell:

Welcome to Advice Architects. This is Day from Responsive.And today we are speaking with Anton Dovgobrod, CTO of INSART, a WealthTech focused solutions development business, with roots in Ukraine and America. Big disclaimer, Responsive is currently working with Anton's team and we are huge fans. Welcome to Advice Architects, and good evening, Anton.

Anton Dovgobrod:

Thank you, Day. It's a pleasure to talk with you. Haven't talked for a long time, I believe. But I already saw some hints, some topics, that you prepare. I believe it should be pretty interesting discussion.

Day Wachell:

Awesome. Well, before we get into the meat of the inquiry, we run a quick Advice Architects questionnaire, just to give the listeners a sense of who you are, and what you do, and what your vibe is. So to start off, what's your job title, and then what do you actually do?

Anton Dovgobrod:

The first question, it's an interesting question. So, ChiefTechnology Officer. But second question, it's better than first, because everybody understands this in different ways, and this position covered indifferent companies in different ways. So I'm specifically in INSART, my core goal is to organize well-structured and ready to go solution development teams.So, share knowledge expertise across the teams, organize architecture approaches across the whole company, and drive different processes connected to not just solution development, but technical communication between different departments.

Day Wachell:

Awesome. And how long have you been doing that for?

Anton Dovgobrod:

In position of Chief Technology Officer, it's my third year at INSART. Before, I was INSART, in position as solution architect. So, part of my responsibility is transferred to technology.

Day Wachell:

Awesome. And why do you care about wealth tech? Why do you think wealth tech matters to the world?

Anton:

I really believe that financial freedom, it's something that every person trying to reach.

So starting from people and why it's important for people to even understand Wealth Stack either, it's first of all, financial freedom.And Wealth Stack is one of the keys to financial freedom. So pretty important to bring such things, to masses, to advertise it. And it can help many people to reach their financial goals, and actually the results get the financial freedom.

Day Wachell:

That's why we care, as well. So our listeners, many who are advice architects often have to build advisor workstations, WealthTech solutions, using more than one system or piece of software. And a big piece of making things work is, connecting the dots and getting all these pieces to play nice together. That's where the heroes of WealthTech solutions developers come in. Today I wanted to ask you a few questions about the key aspects of solutions development, and find ways for wealth managers and WealthTechs to work smarter. So first, what are APIs?

Anton Dovgobrod:

So in any case, it's a connectivity between one system and another system. And given opportunity, one system part, for example, to talk, which is with each other. And probably even, for example, web APIs right now is the hottest point, because we are living in digital world and amount of data is growing day to day. Amount of systems is growing day to day. And according to this, we have more API integrations, more API endpoints, and really need to work somehow with them.

Day Wachell:

Okay. So, from your point of view, when you're working with these different kinds of APIs of all shapes and sizes, what makes them good, bad, or ugly?

Anton Dovgobrod:

When you ask this question, good, bad, or ugly? I start thinking about Italian westerns. And it's really shown in which API world we are living right now, because it's pretty open ways. People are talking about web and communication across the network. There is really wide range of ways, how to communicate. You can use XML or RPC even, you can use Swamp, you can use RPC, you can use GraphQL, or even you can use REST. And REST is good example of wild west, because it's just an architectural approach and is out of some strict standards, and everybody understands REST in the different way. So that's how I feel like this sentence in general. I can go deeper in, I believe you want to, just ask. Let's focus on one word or some specific term.

Day Wachell:

Okay. If WealthTech and institutions are planning to build APIs for their products, how should they make those plans and how should they think about building new APIs?

Anton Dovgobrod:

Pretty important thing here is, when we are talking about build, it's important. So before API design happens you need architecture. So first of all, it's pretty important to design the API. So I'm a pretty big fan of API first approach. When we designing API first and after that started the development, like API design should be definitely part of some more bigger solution design, focus on some specific API. So it's important to design this contract, because API server is not only one thing that we want to implement. We want to satisfy some other parts, like list of API clients. And there should be contract, that agreed by both sides. So that here coming in API for design approach, when the specification for the data model, specification for end point happened first. And it's reviewed, it's agreed by both sides and after that, development happens.

So for sure, I believe if such kind of approach happened in every wealth stack, we'll be able to decrease the amount of issues and problems. Another pretty important thing is to start thinking about API, it's more from security perspective. Start thinking from the beginning that, there is no way to build new authentication, new authorization APIs. So even if your app work in some internet, better to start thinking about else methods, better to start thinking about ACL from the very beginning. And implement at least some basic authentication and design authorization. What data will other sites see, what users will see or their clients will see, on the very beginning. And that's really helped to save the data later, with some data lakes, data bridges, with some third party person who's trying to hack the system itself, and can prevent him to get the whole data. Probably he have the simple token,I'm already talking about new authorization APIs, and then hasn't pretty much.So design first, thinking about security at first thing, put it in the design.And it's make your API on a better level, for sure.

Day Wachell:

Thanks so much. And so when we're going into design ofAPIs, what are some common mistakes that are made or missed opportunities? How can teams be successful in asking the right questions, when they're designing an API? What are the things to focus on?

Anton Dovgobrod:

Yeah, pretty good question. When a team start thinking about design, first mistake is trying to focus on something. Like some teams say, "Hey, we need to start developing things only when we have complete data model." Or for example, "We have to start designing things when we have agreed endpoint, request response object." So the first tip here, is to use a different approach in different situations. If you, for example, do not have yet the full picture about data model, let's start with endpoint design and general request response, object design. If you already have data model understand that, how application will interact with data, how entities will look like. Okay, great. We can design the schemas, define the fields, define what data types of are in these fields, and later come to endpoint design.

Again, I'm really jumped through to some REST for APIs, but it's not the key to success even. For sure, you need to think about what approach the better for this situation or that situation. Because in some cases, gRPC can be used. In some cases, probably better to start with GraphQL.For example, if you have lots of different connected entities, that you plan to get by one request, think about GraphQL. If you need to work just with endpoints and stateless is your key, great, let’s work with REST. So also another tip is, at the very beginning, start thinking about what type you really need, for your current situation.

Day Wachell:

Okay. So, it sounds like you've got to start somewhere and start with what you know, the problem to solve is often larger than the knowledge.Folks like you and I, know that requirements are everything, how good they are, how bad they are, really determines the success of a project and the success of relationship between two businesses working on a project. In the terms as simplest as possible, can you explain to our listeners what requirements are, and why they're important to what you do?

Anton Dovgobrod:

So, it's kind of a contract between different people who planned to implement such kind of things. And from this explanation, it's ready key to success. So it's pretty important to have understanding, who are those stakeholders, who are those requirements’ users, who will use those requirements later. And having this understanding, you can create great contract requirements. So going deeper, for sure there is different types that you definitely should put there, like functional requirements, non-functional requirements. Inside of it, it can be transitional requirements, operational requirements, technical requirements. But the main key and key here, is to describe things that really needed in later system working process. Because it's also some common mistake when, for example, business analyst sit in, even together with stakeholder, and the business analyst creates 100 pages document with full requirements. Everything is there according how systems should work, how data types should look like, what business flows will be there, et cetera.So everything described in detail.

But at the result, everything happened in different way.You should be ready that requirements are changing. So it's one of the key thing, that requirements are changing. Because our main goals is to create the great business product to solve some business problem, and business trying to reach some window of opportunities, and the windows of opportunities sometimes are pretty small. So it should be fast. That's why it should be some balance between something that definitely should be implemented, and good explanation, how it should be implemented. That's a perfect explanation of requirements in this example.

Day Wachell:

What is the risk of bad requirements? What happens to a project if we don't get good requirements?

Anton Dovgobrod:

Good example from life, one team was owned by the requirement that was well prepared, prepared by one site. Isn't [inaudible] waste or requirements transferred for. Development team, "Hey, take a look." And they check the requirements itself. It seems pretty good, pretty solid. But during the implementation, one thing was losing, and another thing was losing, third thing was losing. They understand that. And as a result, coming to the release, for sure if there's no communication with stakeholder. Team doing the assumptions, because they want to make the product, and the result product was working a bit different way from expectation itself.So here's an example of bad requirements, and under the bad requirements, non-discussed, non-agreed requirements by both sides. So that's I believe, the most weak point.

Day Wachell:

How does a team like yours at INSART, help with requirements and make that requirements gathering process stronger?

Anton Dovgobrod:

First of all, we have already prepared processes forgathering requirements, discussing requirements with stakeholders, and provide the requirements to the development team. The holder of this process is usually a business analyst, sometimes it's full-time person in the project, sometimes is part-time person in the project. But this person really helps to save time of project manager, because in many projects in classical way, project manager take care of taking environments from stakeholders, taking requirements from clients. And after that, transfer to dev team, but business analysts can do a great job and can save time from both sides. Again, having the right processes.Another thing important thing is, approach is how to keep requirements. So we already have talked that requirements are changing and we should put it as a default thing. That's why using some tool like influence, or any other tool that can help requirements or showing them, so important to have different versions.

Understand the changes, see the changes, history. And having the right tool, that we usually propose to clients or client already have some tools, so we can use and apply best practices and approaches, to use that specific tool. So version requirements, use specific tool to help them talk with the team, like participate team in requirements discussion at the very beginning. All this together make the great circle of perfect products that can happen.

Day Wachell:

Awesome. So what advice do you give to businesses you're working with, to get better at requirements? How can your partners get better at this process, on their side?

Anton Dovgobrod:

Don't hesitate to hire a business analyst just for halftime. I know It sounds pretty obvious, but it really saves time, nerves, and later even sometimes money on the after release process. When we come to the after release fixes.

Day Wachell:

A hundred percent agree with you on that one. So we talked about requirements. Once we get our requirements or don't get our requirements, we've got to manage time and we've got to manage the project. And there's never enough time, always. So what are the biggest mistakes you see in project management, that harm outcomes?

Anton Dovgobrod:

First of all, it's not defining definition of “done”things. I believe it's one of the biggest mistakes. So not define definition of done for some specific tasks or goals, it really can distract them. It can cause unpredictable result at the end, because nobody know where the thing is sending. And what are its key points? How to reach specific goal or a specific task, how to finish it. So it's accorded some point to point thing. Another thing important to think about teams, and to today, we really work in post-COVID environment. Where, we have decentralized team, many team members working remotely. So really important to keep a set of ceremonies. It sounded pretty obvious, but sometimes people forget about that. And with team synchronized once per week, and well that once per week, everybody understand that they're moving in some wrong direction.

So ceremonies, day to day work, day to day communication, having proper communication channel, see how the team health is. Try to look on any productivity instrument, dashboard, or down charts, if you using that, anything. So the project manager and the project management process should definitely include this health check, day to day health check, how things are going. That help to prevent really big issues. When again, time coming to the release them or anything, that be coming through.

Day Wachell:

What are the biggest risks that hide out in the forest to project timelines, and how can you get ahead of those risks?

Anton Dovgobrod:

No project plan. I believe, no project plan, at the very beginning. So no project plan, carries different risks. So when you know what to reach to, it's the thing that you will, by default, fail later. So planning at the very beginning, as early as you start doing your project plan, your roadmap is better, it's safer for you. For sure, you should think that, you will change something. Like second sprint in the plan, probably you will change it, when you come to it, or third sprint in the plan. But when you see whole picture, it's much easier to prevent failures on the middle. Another important risk, is to try to include best factor in your planning. So definitely plan, when we are talking the human factors, we are definitely humans. The people, our engineers are working in the team.

Usually, we still do not have robots there, that's sad.But still that's why we should include some class factor. So everybody in the team, we should have replacement. We should have somebody who are sitting near behind and ready to provide help. In this case again, helping really much good requirement that we're talking, at the very beginning. Because person who replacing in some case, can easily start working on things. It's about onboarding process that can also help you mitigate this risk, because fast onboarding, can help you pretty fast input person, and also can mitigate this risk.

Another risk could be in environmental stuff. So you should really prepare environments in the very beginning, before you even start working on some feature. Specifically, when you have really big projects and you have set of teams, you have set of environments. And you plan to implement some feature, you need some insulated environments. And team coming to get this environment, at the beginning of the sprints when they start working, it's already too late. You should have environment before you start actual work.That's why it's important to make the plan, solution design where, "Hey, here should be some environmental changes. We need some separate environment todo verification, to run our integration test." For example. So it's another thing, can mitigate the reason itself.

Day Wachell:

Awesome. So the talent onboarding, getting people in position, and making sure your environments are ready to rock and roll. I just want to say right now, we've been super impressed with how you guys have been managing the project and just creating results. So just want to give that shoutout.

Anton Dovgobrod:

Thank you so much. We were training for more than 20 years.

Day Wachell:

Yeah. Awesome. So we never want to be here, but sometimes projects get behind schedule. Maybe there was scope that we missed or the client missed, or something's happened. What's the best thing to do when you're sitting there and you realize, "Oh geez, this is not going to be on time." What do you do, how do you manage that up, how do you manage that down? What's the best thing a tech leader can do in that context?

Anton Dovgobrod:

For sure. First thing better to not come to this situation.But we can say that it is possible at all. So there are different factors we can predict everything. We can do risk management. For example INSART, we actually do it, but still there are factors that can even... For example, by the way, we were talking about APIs, third-party API. Change their API and just say about that, in day before they push the significant change. All authorization, all endpoints changing. And like they say, by email, they update, "Hey, we are going to update API. You need to make changes."And tech leader with seeing that, he for sure holds his head by the hands, because the team should change half of their scope.

Day Wachell:

Oh, man.

Anton Dovgobrod:

Yeah. By the way, it's example from real life.

So, what can we do there, for sure, it's really important, we saying it for every manager, not sitting quiet, not trying to solve the problem by yourself. In many cases, in many situations, it can come you to the fail state and everybody will list. So first, when you identify on the early stages, something going unpredictable way. Definitely there is people who can help, so ask for help. For sure, explain what's happening. And by two or three people, it's much easier to start thinking about some problem, and find more resources for more people to start firefighting. So second, it's firefighting. So firefighting, the thing happened, don't panic, and you really need to be calm.You already say about the problem. You already find the firefighting team who will help you to fight here. And you start again with a calm hat, start looking at the problem and do some plan. So, action points per person, that everybody understands, start working by this plan.

For sure, it's already not about some sprint plan and etcetera, here is coming on the scene as some work and band approaches. So you have these list items, action points that you didn't define, and everybody in firefighting team trying to solve them as fast as possible. So you come into another mode or fighting mode, and that's helping to save... I don't want say lives, but money definitely.

Day Wachell:

Okay. Final question, the deep question of the episode. If you could give any advice to CTOs or heads of IT, for businesses you've worked for, what would the advice be?

Anton Dovgobrod:

That's a philosophical question. Pretty hard to give some advices, because many people have different responsibilities and even city or chief technology officers, many people doing different things. But general, I believe advice is still, even if you are CTO of pretty big company, it's no matter you're a CTO of company, it's 100 people, or 500 people. I believe the best key to the success... The key to the kingdom is the talents. The people who you are looking for, who you are hiring, for your nearby positions. So it's the most challenging thing to find the good person, to find the talent. But I believe getting this skill to finding talents, who can help you to reach your goal, your team goal, your company goal, it's can be really key thing to success.

Day Wachell:

Thank you so much, Anton. Really great talking to you today about solutions development. Thanks for having a late night with us, we appreciate that too.

Anton Dovgobrod:

Day, it was great conversation. Many interesting topics.

ABOUT THE AUTHOR
Responsive AI