You didn’t put money into test automation so that your QA engineers could spend Tuesday afternoon working out why a locator broke, and you almost certainly didn’t do it so that release day would turn into a group investigation into which failures are actually real. You did it because you wanted to move faster, catch problems earlier, cover more ground, and get to a release decision without that low hum of anxiety sitting in the background.

Somewhere along the way, though, quite a lot of teams have found that automation quietly became another thing that needs looking after. Regression suites take longer every quarter, test data expires at the worst possible moment, API contracts shift underneath you, UI changes take out a dozen locators at once, and failure reports still need a human being to sit down and interpret them before anyone can act on them.

That is not automation letting you down, and it’s worth saying that plainly before anyone starts blaming their framework or the people who built it. What has actually happened is that software delivery has moved on, and tooling that only follows instructions can no longer keep pace with the complexity of what it’s being asked to check. Quality engineering now needs something that can weigh things up, adjust when the application changes, work out what matters most on a given day, and improve over time instead of slowly decaying.

That is the gap Generative AI and Agentic AI are starting to fill, and it’s worth understanding what they genuinely do before deciding what to do about them.

A Release Day You’ve Probably Sat Through

It’s late in the cycle, the build has passed development review, the deployment window is a few hours away, and everyone is waiting on the regression report to land. When it does land, there are failures, and the room does that thing where nobody says anything for a moment because everyone already knows how the next two hours are going to go.

Some of those tests failed because a locator changed, some because the test data had gone stale, some because an API response now returns a field in a slightly different shape, and a handful might be genuine defects that nobody has spotted yet. The trouble is that at this exact moment, nobody knows which is which, so the team starts the familiar routine of rerunning the failures, digging through logs, comparing screenshots, checking whether the environment was healthy, refreshing data, and scanning recent commits for anything that looks relevant.

By the time all of that is done and the team finally understands what the failures mean, the problem was never really test execution. The problem was confidence, and confidence is the thing that traditional automation at scale struggles hardest to deliver, because it can give you a great many more tests without giving you any more clarity about what to do next.

Where Traditional Automation Runs Out of Road

Automation frameworks have earned their place, and there’s no sense pretending otherwise. Selenium, Playwright, Cypress, Appium and Rest Assured have taken enormous amounts of manual execution off people’s plates and made continuous testing a realistic proposition for organisations that previously spent whole weeks on regression cycles.

The difficulty is that these tools are brilliant at one specific thing, which is executing a script that somebody has already written, and they were never designed to do the harder work that sits either side of that. They don’t understand the context of a change, they can’t adapt when the application shifts underneath them, they have no opinion about which tests matter most for a particular release, and they certainly can’t look at a wall of red and tell you which failures deserve your attention first.

As the systems being tested get more interconnected, the cost of keeping the automation upright climbs steadily, and teams end up spending a larger and larger share of every sprint fixing scripts, managing data, chasing flaky tests and trying to trim regression suites that keep growing regardless. It rarely shows up as a crisis, which is precisely why it goes unaddressed for so long, but it drains real capacity from people you hired to think about quality rather than to babysit tooling.

The bottleneck in modern QA has quietly moved somewhere else entirely, because the constraint is no longer how much you can execute in a given window but how intelligently you can decide what’s worth executing in the first place and what the results are really telling you.

The Quiet Tax You’re Already Paying

Every broken locator, unstable test, out-of-date data set and ambiguous failure report takes a small bite out of your engineering capacity, and because each individual bite is so small, almost nobody adds them up. It builds gradually and unremarkably, in ways that look something like this:

• Half an hour gone investigating a flaky test that turns out to be fine
• Two hours updating locators after a front-end change that took ten minutes to make
• Most of a morning preparing test data for a scenario you’ll run once
• A release pushed back because nobody can say with confidence whether the failures are real
• A regression suite that keeps getting bigger without anyone feeling any better about shipping

None of these is worth escalating on its own, and that’s rather the point, because collectively they push the whole quality function into a reactive posture where the team is always responding to the last thing that broke rather than getting ahead of the next one. It’s the reason so many organisations will tell you, quite accurately, that they have automated their testing but have not automated their confidence.

From Test Automation to Autonomous Quality Engineering

The way out of this is not simply more automation, because more of the same thing produces more of the same maintenance burden, and anyone who has doubled the size of a regression suite already knows how that story ends. What’s emerging instead is something closer to autonomous quality engineering, where the system doesn’t just run the tests you gave it but helps you design scenarios, generate scripts, prepare data, run validations, make sense of failures, recommend a sensible regression scope and keep improving coverage as the product changes.

That shift is happening in three fairly distinct stages, and most organisations we speak to are somewhere between the first and the second.

Stage one: rule-based automation

This is where most teams live today, running predefined scripts that engineers wrote and engineers maintain, which works perfectly well for stable and repeatable scenarios but demands human intervention every single time the application changes in a way the script didn’t anticipate.

Stage two: generative AI

Here the speed of creation changes dramatically, because the system can produce test cases, automation scripts, SQL queries, API validations, synthetic data, assertions and documentation from natural language descriptions and technical specifications, which removes a great deal of the typing and boilerplate that used to fill an engineer’s week.

Stage three: agentic AI

This is where reasoning and orchestration enter the picture, with agents that can plan a testing workflow, carry out the tasks in it, look at what came back, work out why something failed, adapt when the application has moved and recommend what should happen next. It’s the difference between having an assistant who does what you ask and having a colleague who tells you what’s worth doing.

Generative AI: Taking the Grunt Work Off Your Plate

Generative AI is already doing useful work in QA teams today, and the applications are refreshingly unglamorous, which is usually a good sign that something is real rather than a demo. Teams are using it to turn requirements into test cases, build API automation directly from OpenAPI or Swagger specifications, write SQL and generate test data, produce assertion and validation logic, explain failures in plain language, generate automation code for Selenium, Playwright, Cypress and Rest Assured, tidy up test documentation and traceability, and find the coverage gaps that nobody had time to go looking for.

Scripts certainly appear faster, but the part that tends to surprise people is what their QA engineers start doing with the hours they get back, because risk analysis, exploratory testing, business validation and quality strategy are all things that need experienced people thinking hard, and those are exactly the things that get squeezed out when the week fills up with maintenance.

Generative AI doesn’t reduce the need for QA expertise in the slightest. It just means that expertise gets applied to the problems where it makes a difference.

Agentic AI: Deciding What Deserves Testing at All

Agentic AI takes this further by adding judgement to the mix, and it’s worth being concrete about what that looks like in practice rather than talking about it in the abstract. A testing agent can read a set of business requirements, work out which services are affected, find the related APIs, build end-to-end scenarios, run them, read the logs, form a view on the likely root cause of a failure, repair locators that have drifted, write up a defect summary that a developer can actually use, and tell you which slice of the regression suite is worth running for this particular change.

That changes the shape of the conversation your team has before a release. The question stops being how many tests you managed to automate this quarter and becomes something more useful, which is how intelligently you can decide what to test, when to test it, and how much confidence is enough to press the button. Getting a defensible answer to that last question is the real prize here, and it’s the thing that no amount of additional test execution has ever quite managed to deliver.

So Why Is Everyone Moving So Slowly?

Most QA leaders we talk to don’t need convincing that the problem exists, because they’re living inside it. They know maintenance is eating their capacity, they know the regression suite has become unwieldy, and they know that release confidence still comes down to somebody’s judgement at eleven o’clock at night. Change still happens slowly, and there are usually three reasons for it.

The investment you’ve already made

Years of work have gone into building the current framework, and rethinking it feels like putting a functioning thing at risk for an uncertain gain, which is a perfectly reasonable instinct. The good news is that AI-driven QA doesn’t ask you to throw any of it away, because it sits alongside what you already have and improves the design, maintenance, analysis and optimisation of the tests you’re already running.

The governance question

AI-generated tests and recommendations need reviewing, and leaders are right to ask about accuracy, data privacy and whether they’ll be able to explain a decision to an auditor six months later. These are legitimate concerns rather than obstacles, and the answer isn’t to wait until they resolve themselves but to build in the controls, the traceability and the human oversight from the beginning rather than bolting them on afterwards.

The trouble with proving return

Teams often struggle to build a business case, and the usual reason is that they’ve tried to price up a transformation of everything at once, which is both hard to justify and hard to deliver. It works far better to pick one area where the friction is genuinely painful, whether that’s regression optimisation, test data generation, failure analysis or self-healing automation, and get a measurable result there. One improvement you can point to will do more for the next conversation than any amount of strategy documentation.

Five Questions Worth Asking Before You Buy Anything

If you want a quick read on whether your QA function is in a position to get value from AI, these five questions will tell you most of what you need to know, and you can answer them from data you almost certainly already have.

How much of each sprint goes on maintaining automation?

If a meaningful chunk of every sprint disappears into fixing locators, updating scripts and stabilising flaky tests, then AI-assisted maintenance is likely to pay for itself quickly, because that work is repetitive, pattern-driven and well suited to being handled by something other than a person.

How often do regression failures need a human investigation?

If your team routinely spends hours working out whether a failure is a genuine defect, an environment problem, a data problem or just noise, then automated root cause analysis will take a large and very visible cost out of your release cycle.

How thoughtfully is the regression scope chosen?

If every release triggers the same enormous suite regardless of what changed, then you are almost certainly over-testing the parts of the system that haven’t moved and under-testing the parts that have, which is an expensive way to end up with less assurance than you think you have.

How quickly can you get fresh test data?

If preparing data is what holds up execution, or if it quietly limits which scenarios anyone bothers to write, then generated data will improve both your speed and the range of situations you’re able to cover.

How well can you trace requirements to coverage?

If answering that question means somebody sitting down with a spreadsheet, then you’re finding your coverage gaps far later than you should be, and this is an area where AI can surface missing scenarios and weak spots early enough for it to matter.

The aim of this exercise isn’t to find as many places as possible to apply AI. It’s to find the one process where the friction is worst and fix that properly, because a real improvement in a painful area will teach you more about what works in your organisation than a broad rollout ever will.

Why It’s Worth Starting Now

The commercial argument for AI in quality engineering has very little to do with tests running faster, which is a nice side effect rather than the main event. The argument that matters is that your release decisions get better, because the people making them have clearer information, fewer false alarms to wade through and a much better sense of where the actual risk sits.

Along the way you get the practical benefits you’d expect, which include less manual effort, more efficient regression cycles, defects surfacing earlier, faster triage, wider coverage and a release process that people trust. The more durable gain is that your QA team stops spending its time on repetitive maintenance and starts spending it on quality strategy, and that’s a change in what the function is for rather than just a change in how quickly it works.

Organisations that move on this early won’t simply have automated more than everyone else. They’ll have built a quality capability that adapts as the product does, and in a market where speed, reliability and customer trust are so closely tied together, that turns into a genuine advantage rather than an operational nicety.

What This Isn’t

It’s worth being direct about the things AI-powered QA is not, because there’s plenty of noise in this space and some of it sets expectations that nobody can meet. This isn’t about replacing testers, it isn’t about accepting machine-generated scripts without looking at them, it isn’t about taking engineering judgement out of release decisions, and it certainly isn’t about automating things simply because the technology now makes it possible to do so.

The sensible division of labour is that AI handles the high-volume, repetitive and pattern-driven work where it’s genuinely good, while your engineers keep hold of risk assessment, business validation, customer experience, domain interpretation, ethical judgement and the final call on whether something ships. That’s not a compromise position, it’s just what each side is actually good at, and pretending otherwise tends to end badly for everyone involved.

Where This Goes Next

Generative AI will keep getting better at helping teams create test assets, and agentic AI will increasingly shape how testing workflows are executed, analysed, repaired and optimised, which means the day-to-day experience of working in QA is going to look quite different in a few years’ time. The direction of travel is away from a function whose main job is finding defects before production, and towards one that provides continuous intelligence about quality to everybody who needs it.

In practice that means fewer repetitive scripts to write and maintain, less noise to sift through, faster analysis when something does fail, more sensible decisions about what to regression test, automation that survives contact with a changing application, and a much closer relationship between what your technical quality metrics say and what your business actually cares about.

Quality engineering has always been about more than catching bugs before customers do, but the tooling hasn’t previously made that easy to demonstrate. What’s changing now is that it’s becoming possible to build a quality function that lets an organisation keep innovating quickly without quietly trading away the trust it has spent years earning.

The Short Version

Traditional automation helped teams execute faster, generative AI is helping them create faster, and agentic AI is starting to help them decide, adapt and orchestrate their testing far more intelligently than a script ever could. Each stage builds on the one before it rather than replacing it, which is why none of this requires you to tear down what you’ve already built.

The next generation of software excellence isn’t going to come from automation on its own, because we’ve collectively spent a decade proving that more scripts do not automatically produce more confidence. It’s going to come from QA engineers and AI-powered systems working on the parts of the problem that each of them handles best.

None of this ends with AI replacing QA professionals, whatever the more excitable corners of the internet would have you believe. The people who work out how to use it well are the ones who will define what quality engineering looks like over the next decade, and that is a considerably more interesting place to be than spending your Tuesday afternoons fixing locators.

Book a free discovery call. 

The post The Future of QA: How Generative and Agentic AI Are Changing Quality Engineering appeared first on Sandhata.

Every product demo looks great on the surface. Sleek dashboards. Seamless integrations. Smooth customer experiences. 

But the surface isn’t what keeps your systems alive. The invisible layer of code underneath is what decides whether your business scales or stalls. 

In TIBCO BusinessWorks, that invisible layer is even more dangerous. Low-code promises speed. But speed without discipline is chaos, and chaos in mission-critical integrations doesn’t just break features. It breaks trust. 

Why Code Quality Is Your Only Real Moat 

Product features can be copied. UI design can be imitated. Even pricing strategies can be undercut. But code quality? That’s the one moat your competitors can’t replicate overnight. 

Ignore it, and you invite disaster. A global payments processor discovered this when one missed error in a BusinessWorks palette disrupted transactions across three continents for six hours. The fallout: millions in lost revenue and customer trust that never fully recovered. 

The Myth of Manual Reviews 

“We already do code reviews.”
That’s what most engineering leaders say until the outage happens. 

Manual reviews are slow, biased, and incomplete. A senior dev skims configs after a long sprint, misses an edge case, and rubber-stamps it. By the time feedback is shared, the code has already changed. The cost of fixing the bug multiplies tenfold. 

In BusinessWorks, relying on manual review is like hunting for a snake in a dark forest with a flashlight. You’ll miss the one that bites you. 

The Invisible Enemies Hiding in BusinessWorks 

Low-code hides landmines that traditional coding teams don’t see: 

• Hidden Logic Complexity: Nested workflows that turn simple changes into domino chains. 

• Tight Coupling via Shared Resources: A tweak in one global variable ripples across systems you forgot were connected. 

• Inconsistent Error Handling: One process fails silently while another crashes loudly. Neither predictable. 

• Redundant Activities: Old activities bloat pipelines and slow debugging. 

• Poor Naming Conventions: New devs waste weeks deciphering spaghetti-logic. 

A global logistics company ran headfirst into this wall. Years of organic growth created a codebase no one understood. When a partner demanded urgent API changes, no one dared touch it. Only after implementing automated checks and structured refactoring could they reduce lead times from weeks to days. 

Technical Debt: The Silent Tax on Innovation 

Technical debt isn’t old code. It’s a compounding tax on your future. Every shortcut, every skipped review, every “we’ll fix it later” accrues interest. 

• Teams avoid changes for fear of breakage. 

• Product launches drag. 

• Competitors ship faster. 

A financial services giant learned this the hard way. Engineers spent more time avoiding risks than writing features. After deploying CODI: 

• Over 300 hidden flaws were resolved in six months. 

• New hire onboarding time dropped by 70%. 

• Incident rates fell by half. 

Technical debt was crushing them. CODI became their interest-rate reducer. 

Enter CODI: The Low-Code Enforcer 

CODI isn’t just another “quality score” generator. It’s a scalpel for BusinessWorks. 

• Extraction & Deep Analysis: Every palette, process, and config is scanned. CODI spots inconsistent error handling, risky couplings, and structural weaknesses before they hit production. 

• Actionable Insights: Reports aren’t vague. They’re context-aware, telling you exactly what’s wrong, why it matters, and how to fix it. 

• Seamless Integration: Plug into Git or CI/CD pipelines. Every commit gets scanned automatically, making quality part of the daily workflow, not an afterthought. 

CODI doesn’t replace engineers. It amplifies them. Freeing senior talent to focus on architecture and mentoring while automation catches the low-hanging flaws. 

Case Studies That Prove the Point 

1. Telecom Operator: From Monthly Outages to Predictable Stability

For years, one of Asia’s largest telecom operators had accepted outages as “part of the job.” Every month, without fail, some unexpected break in their BusinessWorks ecosystem would bring down customer-facing services. Engineers were in constant firefighting mode. Leadership had even started budgeting for incident penalties because failure felt inevitable. 

The problem wasn’t that the team lacked skill. It was that their system had grown too complex to manually monitor. Shared resources caused ripple effects. Nested workflows hid bugs in plain sight. No amount of manual reviews could keep up. 

Once CODI was deployed, the change was dramatic. The tool scanned every process and configuration, highlighting hundreds of hidden flaws no human had caught. It exposed inconsistent error handling that had been silently crashing processes. It flagged tight couplings that caused failures to cascade across unrelated systems. 

Within six months: 

• Incident rates dropped by 50%. 

• Deployment anxiety turned into deployment confidence. 

• Engineering teams finally shifted their time from crisis management to innovation. 

Instead of preparing for outages, the telecom could plan new service rollouts with confidence, a cultural shift that restored both internal morale and customer trust. 

2. Financial Services Giant: Onboarding in Weeks, Not Months

In global financial services, time is literally money. But for one top-five player, technical debt had turned onboarding into a nightmare. 

Before CODI, new developers joining the integration team often spent three to four months just learning the quirks of the existing BusinessWorks environment. Naming conventions were inconsistent, error-handling rules differed from one workflow to the next, and tribal knowledge was the only real documentation. Senior engineers spent more time hand-holding than solving customer problems. 

The company adopted CODI to enforce automated quality gates at every stage of development. Instead of subjective, memory-driven reviews, every commit was scanned and flagged automatically for inconsistencies or risky patterns. 

The results were immediate: 

• New hires went from “confused observers” to productive contributors in a matter of weeks. 

• Senior engineers were freed from endless code walkthroughs and could focus on architecture and mentoring. 

• Code quality became objective, consistent, and scalable, no longer reliant on who happened to be available that week. 

In financial services, agility without risk is priceless. CODI allowed this firm to achieve both. 

3. Global Logistics Firm: Turning Risk Into a Competitive Edge

A global logistics leader had accumulated years of integration spaghetti. Different teams had hacked together workflows, shortcuts, and patches to keep pace with customer demands. The result was a fragile codebase no one fully understood. 

Every time a partner requested an API change, the team froze. Any modification risked breaking mission-critical flows. The company’s growth slowed not because of strategy, but because of fear. 

CODI became the turning point. By scanning and mapping the entire BusinessWorks landscape, it provided visibility into risks and redundancies. Engineers could now refactor with confidence, cleaning up old workflows and standardizing practices. 

The transformation was measurable: 

• Change lead times shrank from weeks to days. 

• The engineering team reclaimed its velocity and started saying “yes” to customer requests again. 

• What had once been seen as a “legacy liability” became a selling point in competitive bids. 

By demonstrating faster, safer integrations, the logistics firm won new contracts against competitors who were still bogged down by technical debt. CODI turned fear into leverage. 

Before CODI vs. After CODI 

Why Developers Actually Love CODI 

Nobody wants to write bad code. Most devs simply don’t get the feedback they need in time. CODI changes that. 

Instead of waiting for a scathing code review after the fact, devs get immediate, constructive guidance. Quality becomes a point of pride, not a punishment. Teams shift from “don’t break it” to “let’s improve it.” 

The Culture Shift: From Firefighting to Flow 

CODI isn’t just a tool. It’s a cultural inflection point. 

Once quality becomes embedded in daily workflows, it stops being a compliance checkbox. It becomes DNA. Teams ship faster, attract top talent, and win trust with every release. 

That telecom operator didn’t just reduce outages. They reignited their engineering culture. Developers stopped dreading deployments and started mentoring each other on best practices. 

The Cost of Ignoring Code Quality 

Avoiding quality investments today is gambling with tomorrow’s velocity. You might save a sprint now, but you’ll pay it back tenfold in downtime, churn, and attrition. 

Companies that treat quality as optional stagnate. Their best engineers leave. Their product roadmaps shrink. Their innovation dries up. 

Build What Lasts 

Low-code platforms like BusinessWorks promise speed. CODI ensures that speed doesn’t self-destruct. 

Here’s the offer to every leader reading this: 

• Catch bugs early, when they’re 10x cheaper to fix. 

• Reduce technical debt before it strangles innovation. 

• Turn software quality into your moat, not your weakness. 

Closing Line:
You’re not just building integrations. You’re building leverage. With CODI, you don’t just deliver faster. You deliver stronger. And that’s what lasts. 

To integrate with us, click here: https://www.sandhata.com/contact-us

The post TIBCO BusinessWorks’ Chamber of Secrets: Why Code Quality Is the Only Real Moat in Low-Code appeared first on Sandhata.

The post Sandhata’s DevOps Mastery: Digital Evolution Starts Here appeared first on Sandhata.

The post Unlocking Techno-Strategic Synergy: Solving Digital Dilemmas for Exponential Success appeared first on Sandhata.

DevOps Awards 2023

The DevOps Awards 2023 event, a distinguished gathering in the technology industry, took place at London on 25 October.

This prestigious event served as a platform to recognize and celebrate exemplary achievements in the realm of DevOps, bringing together leading organizations and professionals dedicated to advancing innovation, collaboration, and excellence in the field.

In the fiercely competitive global landscape, Sandhata Technologies emerged as the unrivalled victor at the DevOps Awards 2023, surpassing formidable contenders on a global scale. Amidst stiff competition from industry leaders, our triumphant win of three prestigious awards underscores the magnitude of our achievements. 

Navigating through a field of distinguished competitors, the recognition as the “Best DevOps Team of the Year,” “Best Use of DevOps Technology,” and “Best Cultural Transformation” solidifies Sandhata’s position as a trailblazer in the DevOps domain. This victory isn’t just an accolade; it signifies our ability to stand out and excel amidst the best in the industry. 

The global nature of this competition, with participation from prominent leaders, magnifies the significance of our triumph. Winning three awards amidst such formidable contenders is a testament to our unwavering commitment to excellence, innovation, and transformative cultural practices. 

This achievement not only positions Sandhata Technologies as a global force in DevOps but also highlights our dedication to setting new benchmarks and leading the way in the ever-evolving landscape of technology and innovation. 

Categories Won

The recent DevOps Awards 2023 witnessed Sandhata Technologies and Vodafone securing three prominent accolades: 

Best DevOps Team of the Year: Sandhata Technologies emerged as the Best DevOps Team of the Year, underscoring our dedication to innovative practices and collaborative work. 

Best Use of DevOps Technology: Our strategic implementation of technology positioned us as leaders in the effective utilization of DevOps tools and methodologies. 

Best Cultural Transformation: Recognizing the transformation in our workplace culture, fostering an environment conducive to groundbreaking ideas and innovation. 

Following the conclusion of the DevOps Awards 2023 event, Sandhata Technologies and Vodafone achieved a triple win, representing a significant milestone. Our forward-looking commitment is focused on raising industry benchmarks and driving advancements in the continually evolving DevOps landscape. 

For organizations interested in leveraging our expertise or exploring collaborative opportunities, we invite you to connect with us. 

The post Sandhata Triumphs Globally at DevOps Awards 2023: A Resounding Victory Among Industry Leaders appeared first on Sandhata.

When a single throw event is triggered, the data is processed without any issues. However, if multiple message events are thrown simultaneously, only the first one is successfully processed, while the others fail.  

This is because the message catch event is busy handling the first message event. 

We recently spotted this issue with Camunda 7’s message catch event. 

Unlocking The Solution To This Challenge 

Our team of experts fabricated a groundbreaking “Generic Message Buffering” logic, with which we’ve revolutionised the way messages are processed asynchronously, effectively resolving any scenario you may encounter.   

Fig. 1.1 unveils the powerful list of message catch events eagerly awaiting the trigger. 

Fig1.1

 In Figure 2.1, we present the logic for Generic Message Buffering. By sending a POST request, we can activate the BPM process described below. Additionally, we have the ability to specify the retry count and retry delay as request parameters. Once the request is triggered, we conduct a basic validation to ensure all necessary information, such as message name, payload, process instance id, and business key, is present.  

If all the required data is available, we proceed to send the message to its destination within the “Message Send Task” depicted in Figure 2.1.  

If the message is successfully picked up and processed by the message catch event, we encounter no issues.  

Fig2.1

In a situation where the message catch event is already occupied processing another message, throwing our own message will result in failure. This is a common occurrence in real-time scenarios, and it is up to the developers to determine how the flow should be handled in such cases. 

In our specific case, the failed message will be caught by the boundary event. The error message will then be examined in detail within the “Read Error Message” process (Fig 2.1). 

In the event of an error, we can:  

• Distinguish between errors that require retry logic.  
• Determine if it is a business error or a technical error.  
• Necessitate the involvement of technical experts, if it happens to be a business error 

When encountering a retriable error, we make an attempt to retry the operation. The number of retries and the delay between retries is determined by the input request. 

Potential Scenarios In Re-try

In the context of re-try logic, there are two potential scenarios to consider: 

• In one of the re-try attempts, the message can be successfully delivered to the end system. 

Fig 3.1

• Alternatively, if the maximum number of re-try attempts is reached without success, the message will be marked as an error. 

 If the maximum re-try attempts have been exceeded and the message still hasn’t been delivered successfully, it will require manual re-processing (see Fig 3.2). 

Fig 3.2

  Key Advantages  

• Streamlined Error Handling: By effectively managing busy message catch events, we can significantly mitigate potential errors during data processing. 

• Efficient Data Re-processing: Our approach allows for a substantial reduction in the amount of data that needs to undergo re-processing. 

• Versatile Solution: Utilizing the same bpmn models, we can easily adapt and apply them to various similar use cases simply by modifying the message name. 

 Optimizing Efficiency 

 In order to optimize efficiency, it is vital that both the target BPM and the message buffering BPM are connected to a centralized database. This will allow for seamless integration and streamlined performance. Maintaining a unified database instance is key to achieving optimal results. 

The post Generic Message Buffering | Camunda 7 appeared first on Sandhata.

Maitreya Gavkare, Agile consultant, shares a bit about his background, why he decided to move into the IT sector, and how it’s going so far!

Tell us about your role at Sandhata

I am working as an Agile consultant, primarily facilitating practical improvement initiatives and strategies for clients. To do this, I analyse and evaluate the organisation’s workflow and overall environment, discussing organisational shortcomings with clients, with the end goal of improving how they deliver customer value.

At the same time I facilitate adoption and embedding of the Agile mindset, values, principles, and practices to measurably support the delivery of business outcomes.

Why did you choose to go into IT, and what brought you into Sandhata?

Every organisation in today’s digital world be it aviation, telecommunication, manufacturing etc., has to have a strong IT department to support, develop and consistently maintain their world class products and services for their customers.

I was fascinated, interested and keen to understand and learn about how the digital side of every business works, which led me to choose an IT career.

Being part of such industry is exciting and challenging for me.

Joining Sandhata was a major stepping stone for me, as I transitioned into the IT sector. Before joining Sandhata, I researched the organisation and I found the team was extremely well versed with a range of clients in the IT sector. With a strong brand name and good expertise in the market, I believe it will help in a smooth entry for me in this industry.

What is something you are particularly proud of at Sandhata?

Sandhata is a highly respected and recognized company in the field. It has proven records of delivering some extremely critical and budget-heavy end-to-end IT transformation projects for big giants over the years.

I think all the credit goes to carefully understanding and developing the right capabilities and resources which have been proven a major competitive advantage and it’s something to be proud of.

What can prospective employees expect to find at Sandhata?

It’s fascinating to see the company grow by creating a wonderful collaborative culture between fresh talent and the experienced management team. The power distance is extremely low and that’s the best part of it and something I am proud of being part of the company.

What’s next for you?

I am keen in developing myself as an agile coach to develop efficient teams across Sandhata’s portfolio. I have already been given an opportunity to carry out certain critical activities within the team, which is exciting and it is something I am looking forward to.

The post We Are Sandhata – Meet Maitreya appeared first on Sandhata.

Quite possibly, the team is delivering the wrong stuff (which does not improve the customer experience), or fire fighting issues blind because they don’t have the right information at the right time. Without regular feedback, projects can go off course, the wrong features can be built, and sometimes the wrong issue can be “fixed”!

How does feedback help?

1. Regular realignment of work

Feedback provides a way a realigning the work which is being done with the business goals. It also increases efficiency in the team as it reduces the length of time wasted following the wrong path. The faster and more frequent the feedback is, the more useful it is, and the more time and effort is saved.

The diagram shows the difference between making fast, frequent changes and infrequent ones. When feedback is timely, only small changes in direction are required (i.e. less effort and rework), but when feedback is not provided until later, a bigger change in direction is often required (e.g. system redesign).

Infrequent/slow feedback means the journey from starting a project to achieving the goal is much longer.

Rapid feedback is one of the keys to unlocking more efficiency in your organisation.

2. Reduce Risk

The ability to receive fast feedback reduces risk when delivering and maintaining systems (and can reduce blame in the team). Fast feedback reduces MTTR (mean time to recovery) and therefore reduces the risk of a major issue causing business impact.

3. Generative Culture

Fast feedback improves the team culture and motivation. There is greater transparency, employees can see that their work is useful to the business and job satisfaction increases. We are motivated to do our best when we can quickly, clearly and reliably see what is working well and what is not.

4. Innovation

The ability to fail fast and quickly determine the busines value of a project fosters an environment where innovation is encouraged. Innovative ideas and solutions are very valuable for businesses and also improve job satisfaction.

What does fantastic feedback look like?

Fantastic feedback is:

• Good quality (accurate and comprehensive).
• Fast. Even better if it is continuous!
• Easy-to-understand (clear and focused without overloading or distracting with superfluous information).
• Relevant to the business objectives. For example measuring current state against a business-impact goal.
• Available to all users.

How can you improve efficiency in your team by enabling fantastic feedback?

1. Implement Continuous Deployment and automation

1. Automation and DevOps practices speed up processes by streamlining activities and reducing manual tasks
2. They provide automated results to reduce the likelihood of things being missed

2. Build and use Dashboards

1. Use dashboards to help your whole team get a better view of where we are now
2. Ideally enable comparison with short and long term goals

3. Build a Minimum Viable Product (MVP)

1. Building an MVP is often the quickest way to get real feedback from real users.
2. Feedback from real users enables you (and them) to learn how users actually use the product rather than how you think it will be used or the capabilities discussed during requirements gathering. This is super valuable.

4. Business line teams rather than functional teams

1. Teams which are aligned to the business needs are immediately more able to ask for and receive inputs directly from the business. This means the direction of the team can be constantly realigned to business goals and validated.
2. Reduce handoffs between teams by opening lines of communication and having multi-functional roles working together in one team.

Find out More

Feedback is a key tenet of DevOps principles. Here at Sandhata, we have supported many of our customers on their DevOps journeys, helping them to achieve their business goals.

Take a look at our DevOps services, read some of our customer stories, or contact us to discuss how we could support you!

The post Why is feedback fantastic? appeared first on Sandhata.

Digital Transformation is a revolutionary change in any industry or business which transforms it or creates a new type of industry completely. Digital disruption refers to the impact of new digital technologies and business models on existing goods, services, systems, and structures.

What is Digital Disruption?

Changing technologies have driven the complete transformation of consumer expectations and behaviour. Here are some examples:

• Airbnb has totally disrupted the hospitality industry. Traditional holiday booking agents are now clinging on to stay afloat.
• Netflix has helped to eradicate video rental stores from the market. Netflix is enabling more and more customers to cut their cable subscriptions disrupting the entire entertainment industry.
• Wikipedia is an example of knowledge-at-your-fingertips disruption. Gone are the days when we need to buy a newer encyclopaedia to learn something new!
• Digital cameras have disrupted filming and photo processing.

How businesses can disrupt by changing their path

In another context “Digital Disruption” can be taken to mean when a traditional player enters into a new business or industry. For example software-as-a-service, mobile banking, retail and healthcare etc.

Some examples of businesses changing path:

• Amazon started off as an online book seller but now they are the world’s largest cloud service provider.
• Google is now entering into the banking sector.
• Starbucks now offers a debit cards, disrupting the personal banking sector.

Data disruption

There is a third type of Digital Disruption too: big data.

Disruption due to big data is completely destroying conventional business models which have existed for decades. The amount of data available from different sources is growing steadily year-on-year, and is becoming accessible nearly everywhere. The potential for changes to business models and the way we live our lives is almost endless.

One such example is driverless cars. The existence of driverless cars is only possible due to the nearly unlimited data available from various sensory devices in cars, strong processing power, and fast reliable internet connectivity available on each and every corner. Collecting such data and processing it the right way has created driverless cars, which is slowly but surely disrupting the conventional automobile industry.

Learn more

Find out how we can help you take advantage of digital disruption opportunities in your business. Surviving and thriving in today’s digital economy demands no less.

Contact us to find out more.

The post Digital Disruption appeared first on Sandhata.

Are you unable to release changes as fast as you would like?

Are your teams stuck behind heavyweight processes slowing them down?

Is change expensive due to clunky, inefficient change management?

Our experience with a wide variety of clients has shown us that a heavyweight, cumbersome change management is one of the biggest blockers to achieving your DevOps goals and delivering change at the speed you need.

To solve this problem for our clients, we have created a fully Agile Change Management Process.

Accelerating, streamlining, and automating your change management process will remove the bottlenecks faced when trying to deliver change enabling you to unlock the true value of your DevOps initiatives. In our downloadable Solution Overview, we share the key features of a truly Agile Change Management Process, and how to get there.

Download your copy today.

The post Is your Change Management Process holding you back? We can help appeared first on Sandhata.