Why plain coding and not using enterprise integration tools is not the way to do (many) things right in IT

Why plain coding and not using enterprise integration tools is not the way to do (many) things right in IT

Developers that actively work with integrations and frends share their peer-to-peer opinions and experiences. This time, Paweł Kowalski from HiQ Gdynia shares his honest and casual observations on old vs. new ways of monitoring and Quality Assurance (QA) processes.

Imagine for a moment that you are a developer. It's easy. Just drink a lot of coffee and put some matrix wallpaper on! So... Now you are asked to constantly make sure that whatever functionality you have developed some time ago is working as designed (Quality Assurance aspect). Let's say it's one of the core functionalities of your platform, and without it your business will surely collapse. Simplifying it a bit more: Let's say it is a login functionality (in more complex cases it might be a happy path, data entry, or something else). It might be a closed environment, or internal network. Sounds easy, right?

What do you do?

1. In most cases you would create a separate tool, code it, compile it, maybe use some external library, prepare documentation, handover it to support, and pray that the IT department does not forget about it, because what if the tool built to check the tool breaks? Does it mean you should design a tool *to check a checking tool*? And usually it needs to be a tool because applications for IT monitoring as "check-something" just monitor Central Processing Unit (CPU) and Random-access memory (RAM). And here you deal with multiple browsers and the simulation of an actual user.

Usually what happens is that functionality eventually breaks, and nobody notices it because server with a tool is down, support is late and you are likely to end up being chased at 3:00 am being asked why it's not working for a week.

2. Now imagine you have some magic tools. Or a friend. Or frends. With the help of which you just draw something like this:

As a result you have designed something that is understandable by both business and support. You did it in 5 minutes (actually I did, and it was 5 minutes literally). And it comes with the additional features to ease up you work:

• If something fails or breaks, you can notify the team. You can use SMS, e-mail, or any other provider you use. As a result, support will be aware of an issue in a timely manner and act fast. You might even add yourself in 1 minute by using Graphics user interface (GUI), save and publish;

• Then you might connect it with Jenkins or other automatic releases to production so it runs every time you deploy. No more surprises;

• You might want to update JIRA test tasks, easy! Use JIRA API;

• You can use low-code in a task. There is nothing FRENDS specific so if you know your .NET you already know FRENDS;

• Already have some test suites? Integrate them inside FRENDS or add new ones. You can launch command line so you might even use JAVA, nodeJS, C++, Selenium ;) Whatever is your weapon of choice;

• Then you might run it in a testing environment in seconds with different environment variables;

• If you want to run it manually, you just click this:

• You will be able to see a complete history of processes as well:

And what comes to the documentation... Well, it has already been done automatically in a design phase!

And here comes the question: Why are not people doing it the second way?

The second way offers so much less ambiguity, it's self-documenting, saves so much on down-time of an application. Better customer experience.

Speaking for myself?

I've been myself there a long time ago, and I was building processes the first way myself. Belive me or not, you do not want to follow anymore the first option in today's modern world :).

Why the first way of doing things still prevails, you may wonder. Well, I think it's not that developers would not like to do it a smarter second way. Usually, what I have noticed, it's the business that does not provide the right set of tools. Maybe it's due to the lack of awareness or a learning curve (which is almost non-existent)? I don't know.

Please notice that this example was only a testing scenario. Imagine how many more processes related to your business you might do this way! For exmple, informing operations about a new lead opportunity, or synchronizing your business applications... Sky is the limit.

In summary:

Option (1) involves people from support watching your monitoring-tool, they don't know the code or a process, you need to purchase additional machine to monitor the state of your app, and write documentation separately. And it still might break.

Option (2) involves DEV tooling where you outsource a part of monitoring responsibilities. It's pay as you go, or license-based, and it always works: One place. Multiple environments. Production and User Acceptance Testing (UAT). Unlimited processes. Multiple applications. Almost immediate service level agreement (SLA). Great support. Large community. Compliant with security and internal environments (closed/self-hosted).

And please note that those kind of tools actually do not take job from your developers. Such tools help them succeed, instead, but if you really don't have time, we have a team that can design and deploy processes for you ;).