Service Virtualization – Sandhata

The Microservice Hangover

Pravin Durai — Wed, 22 Apr 2026 07:03:42 +0000

The microservices gold rush is over.

Teams that chased the pattern through 2019 and 2022 are now managing systems that take three engineers to debug a single failed transaction, require five teams to coordinate a two-line configuration change, and go down in four places when one database has a bad morning.

The original promise was real: split your application into independent services so each piece can be built, deployed, and scaled without touching anything else. When it works, it is genuinely powerful. When the boundaries are wrong, you do not get the benefits of microservices. You get all of the cost.

In 2026, the most important architectural question in Java shops is no longer “how many services should we build?” It is “do these boundaries actually make sense?”

“The right architecture is the one that matches the actual structure of your organization and your problem. Everything else is decoration.”

The Myth That Started Most of the Trouble

The assumption underneath most over-engineered microservice systems is this: smaller services scale better.

On the surface, the logic sounds reasonable. Less code, fewer responsibilities, simpler deployments. In practice, splitting a system into many small pieces does not make each piece faster. It adds a cost every time those pieces need to communicate. And in any real application, the pieces communicate constantly.

Here is what that looks like in a Java e-commerce system.

A user searches for running shoes. Fifty results come back from the Catalogue service. Each result needs a current price check from the Discount service. The Catalogue service, using Spring Cloud OpenFeign, makes 50 individual HTTP calls, one per product, before it can return the page.

Underneath this, Kubernetes is running, Docker containers are optimized, auto-scaling is configured. The page is still slow. The bottleneck is not computing power. It is the time spent on 50 separate “please respond to me” round-trips across a network. Each one is fast in isolation, 5 to 10 milliseconds. Fifty of them in sequence adds up to a visible delay on every single page load.

Plain English: What is a network round-trip?

Every time one service asks another for information, it sends a request and waits for a reply. That waiting time is called a round-trip. On a local network it might be 2ms. Multiply that by 50 calls and you have added 100ms to every page load before any business logic runs. Users feel this.

The Distributed Monolith: The Worst of Both Worlds

The e-commerce example above has a name: a Distributed Monolith. The services are physically separated, running in different containers on different infrastructure. But they cannot function independently. The Catalogue service is useless without the Discount service. If Discount goes down, the product page breaks. The system behaves like a single application, but with all the operational overhead of a distributed one.

This is the failure mode that is not discussed enough, because it does not look like a failure from the outside. The architecture diagram has all the right boxes and arrows. The Kubernetes cluster is running. Teams feel like they did the modern thing.

The tell is this: if two services must be updated together every time a feature changes, they are not two services. They are one service distributed across two repositories.

“The question is not how small can this be. The question is: if this service went down for four hours, what else would break?”

If the answer is “everything,” the boundary is wrong. Real service independence means a service can go down, recover, and catch up without any other part of the system losing data or failing its users.

Three Ways Java Teams Are Breaking Their Own Systems

1. Everything talks synchronously

Synchronous communication means Service A sends a request to Service B and waits for a reply before doing anything else.

When everything is healthy, this works fine. When Service B is slow or briefly unavailable, Service A is stuck waiting. Every new request to Service A backs up behind the previous one. If Service C also depends on Service B, it backs up too. The failure moves outward until the whole system is unresponsive.

This is how a slow email verification service takes down an order confirmation flow. The Order Service waits for a 200 OK from the Email Service before confirming the order. The Email Service is under load. Orders queue up. Users see errors. Nobody touched the Order Service.

Plain English: What is synchronous vs. asynchronous?

Synchronous is like a phone call. You wait on the line until the other person answers and responds before you do anything else. Asynchronous is like sending a text. You send the message and continue with your day. The reply comes when it comes. In software, asynchronous communication between services means neither side has to wait on the other to keep working.

The fix is to shift operations that do not need an immediate response to asynchronous messaging. Apache Kafka is the standard tool for this in Java ecosystems. Instead of Service A waiting for Service B, Service A drops a message into a Kafka topic and moves on. Service B picks up the message when it is ready.

There is a specific pattern that makes this reliable called the Transactional Outbox.

Plain English: The Transactional Outbox Pattern

When your Order Service saves an order to the database, it also writes a small note to a special ‘outbox’ table in the same save operation. A background process reads that outbox table and publishes the message to Kafka. Because the order and the note are saved together in a single database transaction, if the application crashes mid-process, the note survives. The message still gets sent. No orders fall silently into a gap between ‘saved to database’ and ‘sent to Kafka.’

2. The database is doing work nobody is watching

Spring Data JPA is the most widely used database tool in the Java ecosystem. It generates SQL queries from your code automatically, which saves enormous amounts of development time. It also generates queries you did not intend, at volumes you did not anticipate, if you stop paying attention to what it produces.

The most common problem is the N+1 query.

Plain English: What is an N+1 query?

Imagine you ask a library assistant for a list of 100 books. That is 1 request. Then, for each book, you walk back to the desk and ask separately who the author is. That is 100 more requests. Total: 101 trips to the desk instead of 1. In software, this happens when JPA loads a list of records (say, 100 orders), then makes a separate database call for each record to load the related data (the customer details for each order). One request to your application produces 101 database queries. At low traffic, this is invisible. At scale, it saturates the database connection pool and slows everything that touches the database.

The fix is to tell JPA to load related data in the same query using a JOIN, or to use batch loading. Both are straightforward once you know the problem exists. The challenge is that the problem is invisible unless you are watching the queries.

The rule is simple: every significant query your application runs in production should be reviewed. Enable SQL logging during development. Use tools like P6Spy or Hibernate’s built-in logging to see the actual SQL being sent to the database. If you see repeated queries with a pattern, you have an N+1 problem. Fix it before it reaches production.

3. When something breaks, nobody knows where

A request to a single-application system touches one codebase. When it fails, you look at one log file.

A request to a distributed system might touch eight services before something goes wrong. Which service failed? At what point in the chain? Was it slow, or did it return an error? Which downstream service caused the problem?

Without the right tooling, the answers to these questions require manually correlating timestamps across eight separate log files. This takes hours. In a production incident, hours are expensive.

Plain English: What is distributed tracing?

Every request that enters the system gets a unique tracking number (called a Trace ID) that travels with it through every service it visits. When something fails, you look up that Trace ID and see the complete picture: every service the request touched, how long each step took, and exactly where it broke. It works like a package tracking number, except for your API calls.

The standard for implementing this in 2026 is OpenTelemetry. It is vendor-neutral, widely supported in the Java ecosystem, and integrates with Jaeger, Grafana, Datadog, and most observability platforms.

The non-negotiable rule: if you cannot trace a request through your entire system on your local machine before you deploy, you cannot operate it in production. Observability is an engineering requirement. It should be built before the first service ships, not retrofitted six months later when something breaks in a way nobody understands.

The Decision Framework: When a Separate Service Is Justified

Before splitting anything into its own service, answer these four questions honestly.

Service Boundary Checklist

• Can this component be deployed without coordinating with any other team or codebase?

• Can this component fail completely without taking anything else with it?

• Does this component have a genuinely different scaling requirement than the rest of the system?

• Does a separate team own this, with no shared development dependencies?

If three or four answers are yes, a separate service is appropriate. If two or more answers are no, the service boundary is premature. Build a well-isolated module within your existing codebase instead, and revisit the question when the conditions change.

The Modular Monolith: The Most Underrated Architecture in Java

The industry spent five years treating “monolith” as an insult. In 2026, the teams shipping fastest are building Modular Monoliths, and they are outpacing their microservice-heavy counterparts on delivery speed and system stability.

Plain English: What is a Modular Monolith?

A single application, but with strict internal walls between business domains. The billing code cannot reach directly into inventory code. The order management module cannot call the user management module through a back door. Each module owns its own data, its own logic, and its own interface with the outside world. The boundaries are enforced in code. It deploys as one unit, so there are no network calls between modules, no distributed transaction problems, and no distributed tracing needed just to understand what a single user action did.

When a module grows to the point where it genuinely needs to scale independently or be owned by a fully autonomous team, extracting it into a real service is straightforward, because the boundary was already clean and well-defined.

A Modular Monolith is not a compromise or a step backward. It is the responsible default for any system that has not yet proven it needs the operational complexity of distributed services. The operational complexity of microservices is a cost you should pay only when the benefit justifies it.

“A well-structured Modular Monolith will beat a poorly partitioned microservice system in delivery speed, incident response time, and developer experience. Almost every time.”

Building Resilience Into What You Already Have

Distributed systems have failures. Services go down. Networks slow. Third-party APIs miss their response time commitments. The goal is not to eliminate failures. It is to make sure individual failures do not become system-wide outages.

Resilience4j is the standard Java library for this. It gives you three core tools.

Circuit Breaker

When a downstream service starts failing repeatedly, the circuit breaker stops sending it requests for a set period. Instead of continuously hammering a struggling service and making the failure worse, the system gives it time to recover. Requests during the recovery window get a fallback response.

Plain English: Circuit Breaker

Like a fuse box in your house. When a circuit is overloaded, the fuse trips and cuts the power to that circuit before the wiring catches fire. You fix the problem, reset the fuse, power comes back on. A circuit breaker in software works the same way. When a service is failing, you stop sending it traffic temporarily, let it recover, then gradually let traffic flow again.

Retry with Backoff

Many failures are transient. A service might briefly be unreachable and recover within two seconds. A retry mechanism automatically re-attempts the request a defined number of times, with a pause between each attempt. This handles momentary blips without surfacing an error to the user. The pause between retries (called exponential backoff) prevents the retrying system from overwhelming the recovering service with requests.

Fallback

A fallback defines what the system does when a service is genuinely unavailable. In a user registration flow, if the email verification service is down, a fallback might be: complete the registration in the database, queue the verification email in Kafka for when the service recovers, and return a success response to the user. The user is not blocked. The email goes when the system is healthy again.

These three patterns together represent the minimum viable safety net for any distributed system. None of them are optional once services depend on each other.

The Architecture Audit: Six Questions for Your Next Design Review

Run this before your next technical design session

• Are service boundaries drawn at domain lines, or at ‘it felt too big’ lines?

• Are services communicating synchronously for operations that do not need an immediate response?

• Are you monitoring the actual SQL that JPA generates in production?

• Can you trace a single user request across every service it touches, in under two minutes?

• Do you have circuit breakers on every external service dependency?

• Could your system be reorganized into a well-structured Modular Monolith without losing any meaningful technical capability?

If more than two answers are uncomfortable, the architecture review is overdue. These are not edge-case concerns. Each one represents a category of production incident that is entirely preventable with the right design decision made earlier.

The Principle That Settles Most Architecture Debates

Microservices are a solution to organizational and scaling problems that have already materialized. They are a destination, not a starting point.

The right size for a service is the smallest unit that can be genuinely deployed, owned, and operated independently by a team, for a clear purpose, without negotiating with anyone else. If that definition does not describe what you are building, the service is too small.

Every architectural decision has a carrying cost: the operational complexity you take on and maintain indefinitely. That cost is only worth paying when the capability you gain cannot be achieved any other way.

Build for the actual problem in front of you. The architecture should serve the business, not validate a technical preference.

Is Your Architecture Ready for What’s Next?

We help engineering teams audit their service boundaries, identify operational risk, and build the right foundation for scale.

→ Request an Architecture Review

The post The Microservice Hangover appeared first on Sandhata.

Sandhata’s DevOps Mastery: Digital Evolution Starts Here

balakarthiga muruganantham — Mon, 08 Apr 2024 11:49:08 +0000

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

Unlocking Techno-Strategic Synergy: Solving Digital Dilemmas for Exponential Success

balakarthiga muruganantham — Mon, 08 Apr 2024 09:44:19 +0000

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

Generic Message Buffering | Camunda 7

Pravin Durai — Tue, 11 Jul 2023 13:49:08 +0000

Imagine multiple messages waiting in a message catch event.

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.

Winner! Unicom Most Innovative Project 2023

Bronwyn Davies — Mon, 27 Feb 2023 12:37:15 +0000

We are proud to announce that Sandhata, in partnership with Vodafone, were chosen as the winner of “Most Innovative Project 2023”. The Unicom India DevOps Awards showcases outstanding achievement from organisations, personalities and solutions operating within the DevOps space.

At Sandhata most, if not all, of our customers are implementing DevOps ways of working. We support them to achieve the maximum business benefit from these initiatives, bringing our unique breadth of experience to overcome their most difficult challenges with innovative, game-changing solutions.

We adore innovation. We understand that ongoing innovation is the key to consistently meeting the customer’s changing needs and remaining competitive in today’s constantly evolving digitised market.

We are heavily focused on innovation at every level, both for our clients as well as internally. We believe that no improvement suggestion is too small and we coach all of our consultants to foster an innovative mindset.

Relentless innovation

The Multiplexer solution was developed to address the shortage of end-to-end test environments. Lack of environments was severely restricting Vodafone’s ability to test changes at the speed needed.

This was a multifaceted challenge with no known solution in the industry. Innovative thinking was required!

The solution was the Multiplexer. This intelligently enables the simulation of multiple environments, so that every project can perform end-to-end testing in parallel.

The Multiplexer is an example of true innovation – building a solution out of necessity which immediately meets a business need.

The Multiplexer solution has been so successful and valuable that it has been implemented across three other Vodafone domains as well. With each additional rollout, the total cost of ownership drops as efficiencies of scale are realised.

The Ceremony

Sandhata’s Head of India, Anand Rajagopalan, was pleased to attend the awards ceremony in person to collect the award.

This recognition adds another feather in our cap for our award-winning DevOps services.

Learn More

Sandhata are industry-leaders in delivering Digital Transformation and DevOps solutions to large organisations who are faced with unique, complex challenges and urgent business requirements. Learn how we can help you achieve your DevOps goals here.

To find out more about us and how we operate, take a look at our solutions, case studies or contact us.

The post Winner! Unicom Most Innovative Project 2023 appeared first on Sandhata.

SE Asian DevOps Awards 2022

Bronwyn Davies — Thu, 24 Feb 2022 16:29:02 +0000

Sandhata Technologies, in partnership with Vodafone, are very proud to have been announced as Runner Up at the South East Asian DevOps Awards 2022 for “DevOps Team of the Year”.

The UNICOM SE Asian DevOps Awards celebrate outstanding achievement from organisations, personalities and solutions operating within the DevOps space. The awards are judged by an independent panel of judges from some of the world’s biggest organisations.

What have we been recognised for?

The DevOps Team of the Year Award recognises the exceptional work that the team has done to transform the Integration Domain within Vodafone. This project has seen a complete overhaul in how we deliver in the Integration Domain by shifting the cultural mindset, strong collaboration with our delivery partners and industry-leading technical implementations. This project has paved the way for lasting excellence, building on our foundation of continuous change delivery, excelling through innovation, and continuous improvement.

Some of the technologies and capabilities introduced to the Domain include:

CICD with Jenkins pipelines
Mature config management with GIT
Full test automation and regression framework
Service virtualisation framework with RIT
Bespoke API directory with Splunk
Visibility with ELK stack
Migration to cloud AWS
And many more…

Throughout this project, the team showed a strong commitment to improving, upskilling and self-development to achieve their transformation goals. Their team ethos and cohesive team identity got them through the challenges, both technical and cultural, and resulted in a robust, well-implemented ecosystem of tools and practices which will provide value far into the future.

Thank you for your fantastic collaboration, VOIS. Well done to the whole team, and thank you for your continued phenomenal efforts on this project over the past year. You each deserve this award.

Learn More

We are industry-leaders in delivering DevOps solutions to large organisations who are faced with unique, complex challenges and urgent business requirements. Read more about how we can help you achieve your DevOps goals.

To find out more about our experience and how we operate, take a look at our solutions, case studies or contact us.

The post SE Asian DevOps Awards 2022 appeared first on Sandhata.

We Are Sandhata – Meet Varun

Varun Arora — Mon, 24 Jan 2022 15:17:38 +0000

Based in the UK, Varun Arora is a Project Manager at Sandhata. We caught up with Varun to find out more about his role, his journey so far, and his hopes for the future.

Tell us about your role at Sandhata

I joined Sandhata in 2021 as Project Manager, working initially for one of our telecoms clients. I am really enjoying my role as it opens the gates for both technical and managerial exposure with stakeholder management. The Sandhata teams have lots of technical experience and in API management, integration and DevOps and I am excited about getting exposure and learning in these areas to grow my career.

Did you study technology at university?

I did a Bachelor’s degree in Electronics and Communication Engineering from Amity University Noida. Those 4 years were full of learning experiences, enjoyment and exploring new things. That was when I first lived alone, cooked food, managed my life and finances day to day, and started to see how I can find happiness in each and every small thing. I finished my degree as a more mature person, confident enough to chase and achieve my dreams.

How did you get started working in IT?

I have been working in IT for 10 years now, starting as a software tester with Accenture (in Pune, India) in 2011. My first client role was on a BT Openreach project, where I performed various roles including manual tester and test design assurance. I quickly learnt to adopt to different roles in a short duration of time. I then moved into a business analyst role, working with architects to design workflows and trace requirements.

I learnt a lot in my consultancy role over 5 years, then moved in 2016 to Vodafone India as Project manager with VOIS.

My journey at VOIS was life changing as it took my learning to the next level. I worked in various areas including digital transformation, DevOps, service virtualization and cloud migration, working with new products such as TIBCO and Chordiant. I was working closely with one of the Sandhata teams, and was highly impressed with the technology and transformation that Sandhata was bringing to Vodafone.

Which projects are you currently working on?

The project I am currently focusing on will deliver Service Virtualization across a range of systems including integration and CRM applications. Considering the 3rd party dependencies and high impact of frequent unavailability, this project will deliver immense benefits to our client.

Why did you choose to join Sandhata?

My first experience of Sandhata was working closely with them at Vodafone India, where Sandhata was introducing automation, DevOps and full digital transformation. Trust me, the switch from traditional styles of delivery to DevOps was not an easy ride and I was really impressed with how Sandhata helped to transform the ways of working in the team, reducing manual efforts for deployment and creating a robust framework for the future.

“I wanted to learn from the Sandhata teams to broaden my skills, and be a part of delivering digital transformation for other clients in the future, so I chose to join Sandhata.”

What was your experience joining Sandhata during COVID?

During COVID, the major problem most people face when joining a new organization is difficulty in onboarding and asset allocation. With Sandhata, my experience was outstanding as Sandhata management (Kumar, Babji and Gopi) worked closely with HR (Suresh and Bharathi), keeping in continuous touch with me, to provide all documentation and guidance needed and ensure a smooth transition.

What’s next for you?

Joining Sandhata is the start a new phase of my career, and I look forward to delivering some great capabilities for our clients as part of the Sandhata team. I am very excited about the opportunities I have to experience new things, and develop skills which will mutually benefit me and Sandhata.

Learn More

If you are interested in joining Sandhata, check out our careers page for the latest job openings or contact us.

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

Finalist – European Software Testing Awards 2021

Bronwyn Davies — Tue, 26 Oct 2021 11:42:36 +0000

We are very proud to announce that Sandhata, in partnership with Vodafone UK, have been announced as finalists in the European Software Testing Awards 2021!

Our project, the “TIL Transformation Project – Test automation and Service Virtualisation” is a finalist in category: Best Overall Testing Project – Communication Sector.

Now in its eighth year the Deloitte European Software Testing Awards celebrate companies and individuals who have accomplished significant achievements in the software testing and quality assurance market.

Why does the TIL Transformation Project deserve this award?

Our Sandhata team, in partnership with Vodafone UK, have been working on the TIL Transformation Project for more than a year. It is a wide-sweeping project which has brought DevOps solutions and full automation to every part of the SDLC in the Integration Domain. This project continues to deliver benefits for the team as new capabilities are introduced.

This year, Phase 2 of the project has focused on Test automation and Service Virtualisation. The build, deploy and release automation capabilities which were part of Phase 1 provided a strong foundation for us to implement the next stage of automation.

The test automation framework is extensible and will cater to the 1000+ APIs within the Integration domain, enabling full regression testing to be performed, which was previously not possible. In addition to a service virtualisation framework spanning the backend dependencies, we also delivered a fully automated API Directory which provides self-service capabilities to the whole team, and an innovative solution to handle test environment constraints.

Our team has worked hard for this finalist nomination, and this project resulted in a fantastic solution for our client, Vodafone UK. Good luck to our team and to Vodafone UK on awards night!

We are looking forward to the awards ceremony on 9th November 2021.

Learn More

We have been working in the System Integration space since Sandhata was founded in 2005 and we have broad and deep expertise in this area. Our skills in Test automation and service virtualisation are well established and we are expert at aligning automation with DevOps and CICD to achieve lasting, tangible business value.

To find out how we can help you, take a look at our solutions, case studies or contact us.

The post Finalist – European Software Testing Awards 2021 appeared first on Sandhata.

Winner! Best Automation Project 2021

Bronwyn Davies — Fri, 15 Oct 2021 14:16:08 +0000

We are thrilled to announce that we have been crowned winners at the Digital Tech Leaders Awards 2021!

The Computing Digital Technology Leaders Awards exist to recognise the achievements of the individuals and companies who are really making it happen at the coal face of the digital technology stack: from website design and coding to UX and project management, from scrum masters and product managers, all the way up to the CDO.

Our Sandhata team working in partnership with Vodafone UK have been recognised for the TIL Transformation Project.

The winning project

Our TIL Transformation project has been announced as the winner in “Best Automation Project” category.

The TIL Transformation Project was recognised for the far-reaching and profound changes it has brought to the Vodafone UK Middleware platform. This project has already delivered full end to end build and deploy automation. This year we built full test automation and regression capability, a service virtualisation framework spanning the backend dependencies, a fully automated API Directory which provides self-service capabilities to the whole team, and an innovative solution to handle test environment constraints.

This project continues to boost the Middleware platform to the next level, introducing fundamental change and new capabilities which will ensure that the Middleware platform is able to meet the ever-changing needs of the business in the future.

The awards night

Members of the Vodafone UK and Sandhata teams were at the awards event to collect the award. It was a pleasure to be able to celebrate together on this occasion, especially since we were unable to do so in 2020.

Learn More

We have worked closely with many Tier-1 organisations on their DevOps journeys, to bring about lasting transformation and cultural change.

To find out how we can help you, take a look at our solutions, case studies or contact us.

The post Winner! Best Automation Project 2021 appeared first on Sandhata.

Sandhata selected as finalists in two categories at the European Software Testing Awards 2020!

Bronwyn Davies — Thu, 03 Dec 2020 17:01:18 +0000

Sandhata Technologies, in partnership with Vodafone UK, are very proud to have been announced as finalists in 2 categories at the European Software Testing Awards 2020.

Now in its seventh year the Deloitte European Software Testing Awards celebrate companies and individuals who have accomplished significant achievements in the software testing and quality assurance market.

Sandhata, in partnership with Vodafone UK, has been nominated as finalists at the European Software Testing Awards 2020 in 2 categories:

Best Overall Testing Project – Communication
Testing Team of the Year

A bit about the projects we are being recognised for

The Best Overall Testing Project – Communication category recognises the TIL Transformation Project which introduced both Test automation and Service Virtualisation to the integration Domain.

Vodafone’s business-critical Middleware (VF-TIL) has been through a monumental transformation to reduce cycle times while drastically increasing quality and stability. This project has delivered Test Automation, Service Virtualisation, and embedded cross functional dashboards into the team culture.

We have also been chosen as finalists in the Testing Team of the Year category.

This category recognises the incredible achievements of the team who have delivered the new test automation and service virtualisation capabilities as part of the TIL Transformation Project. The team delivered full integration of test automation and service virtualisation with the existing CICD capability enabling one-click deployment with full test execution performed, utilising SV where required.

Just one of the immediate benefits is more than 90% reduction in average Test Cycle Time from a few weeks to days. In addition to this, the team have embraced cultural changes which will continue to pay dividends for many years to come.

We look forward to the live online awards ceremony, which will take place on Tuesday 26th January 2021. We hope you can join us at the ceremony!

Learn More

We have been working in the System Integration space since Sandhata was founded in 2005 and we have very broad and deep expertise in this area. Our skills in test automation and service virtualisation are well established and we are expert at aligning automation with DevOps and CICD to achieve lasting, tangible business value.

To find out how we can help you, take a look at our solutions, case studies or contact us.

The post Sandhata selected as finalists in two categories at the European Software Testing Awards 2020! appeared first on Sandhata.