Interview with Gábor Antóci – Engineering Manager at Saltech Consulting

What technologies have you worked with before Pega?

It was always changing. When I started my career as a developer, I mostly worked with C++, Perl, PHP and Python. Later on, when I started to move towards the management direction, I began working with Java and during that time, I was also involved with large systems, as well as with mobile phone centers.

All in all, I would say my main background is mostly business software, which I started around 15 years ago, mainly with business infrastructure and business development. As more and more business-like platforms and technologies came together, I worked with ERP systems, mostly Oracle and Microsoft Dynamics AX. Eventually, we also started working with virtualization technologies, cloud providers like AWS, within that the AWS services, Dockers and CICD, among others. 

What drove you to Pega and low-code?

What I found interesting about Pega is it provides an efficient way of solving problems I usually have, or had, in my career. 

It’s optimal for BPM, BPA, which is normally the current problem in every business, considering they want to automate and be more efficient. It’s a great platform to solve these types of problems. 

In one way, a positive aspect about low-code technology is that it allows you to concentrate on the essential aspects; on the real business processes, explaining them, and afterwards, taking part in the solution. In Pega, it all comes together almost immediately. 

Certainly, it doesn’t mean coding is not necessary, because you continue having the algorithmic problems that you have to resolve, but that is what we enjoy as developers. 

It is important to acknowledge, however, that it is a fairly complex technology platform to learn. Starting is simple; mastering it takes time, like with every technology.

From your point of view, what are some of the benefits of Pega, in contrast with other technologies you have used?

It’s very efficient for companies with large numbers of transactions, or if there are many manual processes happening. In these cases, Pega is helpful because you can flexibly create a solution – based on the company’s needs – and you can present them rapidly. Yet again, it depends on the problem. If it’s one in which you can’t find the right tool for, then Pega makes it easier to develop, to communicate with the customer as well, and it allows them to see their problem being solved promptly and effectively.

Pega has its own place and domain to solve within the business.

What are the domains of Pega, more specifically?

Some processes within a company are not that well covered with other tools. For these cases, at Saltech we develop complete solutions – based on Pega – that fill those gaps, while also helping to create solutions that are more user friendly; more intuitive for the normal business user.

Sometimes these processes need to be replicated many times, and there is a need for speeding up the development process for instance by providing automations out of the box for you. I believe this is very important for the near future of the industry, because businesses need fast and efficient automations more and more. 

You have worked developing a team of specialists before you started working at Saltech, what do you think would be the main difference between a Pega developer and a more traditional developer?

I would say there is no difference, because as a Pega developer you still need to create algorithms, understand data structures, creating an abstraction layer between those, and so forth. They have most of the same responsibilities a traditional developer would have. 

Alternatively, because it is for business processes, having a business mindset is undeniably necessary, as well as truly focusing on the problem and the solution at hand. This doesn’t mean that is not important in traditional development, but I believe it’s particularly relevant with Pega.