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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

The post The Microservice Hangover appeared first on Sandhata.

There’s nothing quite as frustrating as hearing “We’re almost there” when it comes to DevOps automation.

For most enterprises using PEGA, especially in complex, regulated environments like telecom, “almost automated” really means:

• Partial scripts that break mid-way.
• Teams are stuck doing sunrise and sunset checks manually.
• Rollbacks that aren’t rollbacks at all (just a rushed “fix forward” scramble).
• A deployment process so fragile it feels like defusing a bomb with oven mitts.

our client was no different. Their PEGA AOM and VADR systems had become a labyrinth of partial automations, manual file drops, and endless approvals.

When 14+ engineers are stuck pushing buttons, no one’s innovating

Let’s put some numbers on it.

At one point, our client had 17 separate pipelines in its PEGA deployment chain: 12 for AOM and 5 for VADR. But only PEGA artefacts were automated; SQL scripts and CSV files still needed manual intervention.

14+ people were directly involved every time they pushed an update. That meant:

• Long hours on calls coordinating manual steps.
• Higher chance of human error.
• Slow response to production issues.
• Engineers who should be building value are stuck babysitting deployments.

They needed a system that didn’t just look good in a slide deck but actually worked reliably in the real world.

Phase 1: Proving the concept (but still chained to manual tasks)

The first push was to introduce PEGA Deployment Manager (PDM).

Code deployment? Automated.
Configuration files and database updates? Still manual.

This partial fix did reduce some of the friction, but didn’t break free from the core problem: too many manual dependencies.

It was like adding an electric starter to a car that still had flat tires. Better, but not good enough to win any races.

Phase 2: The real leap , End-to-end Azure DevOps automation

Our client knew they had to go further.

Phase 2 wasn’t about tinkering; it was about rethinking deployments from the ground up:

• Code and package deployments are now fully handled by Azure DevOps pipelines, integrated tightly with PEGA’s PRPCServiceUtils.
• CSV and file deployments? Automated. Files pushed from SharePoint to S3 are picked up and deployed instantly, with no human in the loop.
• SQL and database scripts? Automated and version-controlled. No more manual approvals at midnight or rushed fixes.
• Rollbacks? Properly integrated, tested, and reliable. 

Even restarts and sanity checks have been moved to automated pipelines. Python scripts run server restarts and log cleanups seamlessly. Automated sanity reports pull data from CloudWatch, AppDynamics, and PEGA; then roll it up in one clear, consolidated email.

The final piece? A transparent Azure DevOps dashboard that gave leaders a real-time, no-excuses view into every pipeline, every environment, every deployment.

How our client Quietly Rewired Its Entire Software Delivery Model, By Ditching Manual PEGA Deployments

This isn’t a story about shaving a few hours off a release cycle. It’s about removing friction that teams had accepted as normal for far too long.

When our client moved to a fully automated, end-to-end deployment model for PEGA, it forced a shift that went beyond engineering. It reshaped how product, operations, and delivery teams worked together,and what they expected from their own processes.

Here’s what actually changed.

1. No More Crowds Around the Button

Before automation, deployments looked like this:

• Fourteen engineers involved
• CSV files passed around like hot potatoes
• SQL scripts manually reviewed
• People chasing approvals
• Artefacts manually pushed
• Everyone hoping it wouldn’t break in production

That wasn’t resilience. It was ritual.  Every extra person added more surface area for errors,and more chances for something to fall through the cracks. With a fully automated pipeline, those tasks didn’t get reassigned. They got removed.

No one had to “own the deployment” anymore.  It ran in the background. Quietly. Predictably.
The engineering team got their time back,to write code, fix real problems, and stop treating Friday releases like a dare.

2. Rollback = One Click, Not One Crisis

Ask any team what “rollback” really means and you’ll usually get some version of:

“We just fix it forward and pray.”

our client changed that by baking rollback into their deployment pipeline,not as a last-minute patch, but as a normal, tested, version-controlled step.

When something went wrong, the response wasn’t:

“Okay, everyone get on a call.”

It was:

“Just hit revert.”

No scavenging through old backups. No rewriting scripts. No late-night war rooms.Just one confident step back to a known-good state.

3. The Speed Boost That Didn’t Come at the Cost of Sleep

It’s easy to talk about velocity. It’s harder to show how that speed actually helped.

For our client, deployment lead times dropped by over 60%. But that wasn’t the headline.

The real impact showed up when:

• A critical update reached customers in days, not weeks
• A partner integration was fixed before it even became a problem
• A new feature went live while competitors were still gathering approvals

Speed mattered because it was sustainable. It didn’t rely on heroics. It didn’t come at the cost of sleep.  It was baked into the system.

4. From “Let’s Hope We’re Covered” to Actual Audit Readiness

In regulated industries, manual processes aren’t just inefficient.
They’re dangerous.

Every undocumented fix, every email-based approval, every untracked config change is a liability waiting to surface during an audit,or worse, a breach investigation.

Before automation, our client’s compliance trail was scattered:

• Half in spreadsheets
• Some in email chains
• Some just… lost

Now?

Every deployment step is logged.
Every change is version-controlled.
Every approval has a timestamp and an owner.

If the auditors show up tomorrow, the answer isn’t.

“Let us pull together some reports.”

It’s:

“Here’s the full record.”

Risk didn’t vanish, but it became visible and manageable.
And that changed how everyone,from compliance officers to security teams,slept at night.

5. Finally, Everyone’s Looking at the Same Dashboard

Here’s how it used to work:

The engineering lead sent a Slack update.
The release manager shared a spreadsheet.
The PM forwarded an email.
And the exec still had no idea what stage the deployment was in.

Now, our client has a single source of truth.

With Azure DevOps dashboards and real-time deployment tracking, leaders can:

• See what’s going live today
• Check which releases passed quality gates
• Spot where something’s stuck, before it becomes a blocker

No more piecing together the truth from four different channels.
No more surprises in Monday standups.

This kind of visibility builds trust , because everyone’s reading from the same page.
Operations isn’t chasing updates. Business isn’t left in the dark.
And engineers don’t waste time explaining what’s already visible on the board.

The bigger win: unlocking engineering focus

When you remove repetitive manual work from talented engineers, you’re not just freeing up a few hours; you’re fundamentally changing the trajectory of what your teams can accomplish.

At our client, DevOps engineers had become the last line of defense in a system overloaded with manual checks and fragile processes. Every deployment cycle meant long calls, manual CSV file pushes, cross-team sign-offs, and the constant anxiety of “what if this breaks production?” Instead of building new capabilities or optimizing services for end users, they were stuck running playbooks that felt more like insurance policies than engineering work.

By automating the entire PEGA deployment lifecycle from code and package promotion to database and file configurations, including restarts and sanity checks, the engineers could finally shift their focus.

Here’s what that looked like in practice:

Proactive reliability engineering: Instead of reacting to incidents after each release, the team began investing in improving system resilience, strengthening rollback strategies, and tightening monitoring for early detection.

Accelerating innovation: Engineers were able to dedicate time to refining pipelines further, integrating advanced automated tests, and contributing to platform improvements that previously sat at the bottom of the backlog.

Enhanced cross-team collaboration: Freed from the grind of manual approvals and handoffs, DevOps engineers became strategic partners to development and product teams, influencing architecture decisions and delivery timelines from the start, not just at the deployment gate.

Talent retention and morale boost: Top engineers don’t want to be button-pushers. By eliminating repetitive tasks, our client reduced burnout and increased satisfaction, turning DevOps roles into high-leverage, intellectually rewarding positions.

Faster customer-facing improvements: With operational friction removed, teams could push meaningful updates and new features to production faster and more confidently, directly impacting customer satisfaction and business agility.

In short, automation didn’t just make deployments faster; it fundamentally redefined the role of engineering within the business.

The DevOps team went from being perceived as “the deployment team” –  always fixing, always patching –  to becoming force multipliers who empower the entire organization to move at the speed of market demands.

That’s the real value: unlocking the strategic potential of your most skilled people, and finally letting them do the work they were hired (and want) to do.

What does this mean for you

If your team is still stuck in “almost automated” deployments, here’s what you’re paying for:

• Slow feature rollouts that frustrate business stakeholders.
• Higher operational costs from wasted engineering hours.
• Increased risk of errors, outages, and compliance violations.
• Talent attrition, as top engineers tire of being “click monkeys.”

What our client achieved with Sandhata wasn’t a magic overnight fix. It was a systematic, phased transformation that replaced manual drudgery with automation precision and turned deployment from a dreaded bottleneck into a competitive advantage.

Want to see where your real bottlenecks are hiding?

Most organisations think they know where their delays come from; they’re almost always wrong.

We’ve helped large enterprises (like our client) expose their hidden inefficiencies and rebuild pipelines that don’t just work, but work brilliantly.

If you’re tired of “almost automated” and ready for deployments that actually deliver, let’s talk.

One last thought

You don’t need more “best practices” slides. You need a concrete, step-by-step plan that actually sticks.

We know how to build it. Let’s make your deployments as fast, reliable, and invisible as they should be: https://www.sandhata.com/contact-us

The post How our client Transformed Their PEGA Deployments From Manual Headaches to Fully Automated Wins (Without Burning Out Their Ops Team) appeared first on Sandhata.

This Women’s Day, Sandhata took a bold step away from tradition. In a resounding departure from convention this Women’s Day, Sandhata embarked on a trailblazing journey, led by the organization itself in honour of its remarkable women employees.

Sandhata chose purposeful action to empower women far beyond the realms of the workplace.  Recognizing the evolving ethos of this significant day, Sandhata’s leadership redirected resources towards carefully selected charitable endeavours.

This decisive move underscored the organization’s unwavering commitment to championing causes that resonate with its values and drive tangible, meaningful change. The unveiling of Sandhata’s partnership with a specific organization soon followed, serving as a testament to the company’s steadfast dedication to advancing the lives of women beyond the confines of its walls.

It became a celebration of collective strength and a stirring call to action, inviting all to contemplate the transformative potential of purpose-driven support.

Beyond the Walls: Extending Our Impact

In a transformative stride echoing Sandhata’s ethos of purpose-driven action and community empowerment, Sandhata planned to bolster impactful women’s charities in both India and the UK. This strategic decision, made in homage to Sandhata’s exceptional Women of Sandhata (WOS), marks a pivotal leap towards amplifying the organization’s impact beyond organizational boundaries.

Inspired by the resilience and dedication of Sandhata’s women, several representatives took proactive measures to identify deserving charitable causes. Among them, the Indian Chennai Charity emerged as a beacon of hope, dedicated to uplifting and empowering women in the Chennai community, at Children’s Home of Hope. 

As part of the organization’s commitment to effecting tangible change, these representatives embarked on a visit to witness firsthand the transformative impact of the organization’s initiatives.

The visit provided a poignant insight into the lives of women whose stories of resilience and triumph over adversity serve as a testament to the power of collective support and opportunity. It was a stark reminder of the profound impact achievable through collaboration and purposeful action.

This gesture epitomizes Sandhata’s core values of compassion, empowerment, and community
engagement. By investing in initiatives that empower women and foster positive change, the
organization not only honors the remarkable contributions of its women employees but also
reaffirms its commitment to creating a more equitable and inclusive society, locally and globally.

Beyond Borders: A Global Commitment

In addition to Sandhata’s endeavors in India, its UK team made a substantial contribution to the
empowerment of women to the Wonder Foundation UK, an organization dedicated to supporting
women and girls through education and training programs. This gesture underscores Sandhata’s dedication to effecting change on a global scale, ensuring that women everywhere have the opportunity to thrive and succeed.

Through these concerted efforts, Sandhata aims to extend its support beyond its immediate community and contribute to the empowerment and well-being of those in need. As an organization that values its women employees, Sandhata believes in uplifting others and creating a positive impact wherever it can.

This Women’s Day, Sandhata celebrated the spirit of giving and compassion that binds its community together.

The Sandhata Experience: Amplifying Empowerment:

We’re thrilled to highlight the experiences of Sandhata’s India (Chennai,Pune,Hyderabad,Bangalore)& UK employees who participated in the chosen charity events:

The post Sandhata Reimagined Women’s Day: Empowering Through Impact 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.

In this 3-day event in Guildford, UK  we encouraged and inspired our people to embrace eco-friendly lifestyles while focusing on the importance of human values and quality of life.

People of all ages, from young children to adults, participated in a rejuvenating event surrounded by the beautiful woods of Guildford. The Manavata volunteers provided healthy and nutritious food with love and care.

Manavata planned and executed a diverse range of activities for this retreat, ensuring a dynamic and memorable experience for all participants.

We embarked on an unforgettable journey and escaped the hustle and bustle of technology with our Day One trekking and nature walk.  The children connected with nature and learned the value of their beloved ancestors and parents. We immersed ourselves in the enlightening Pada Puja ritual and received blessings from our loved ones.

We wrapped up the day by indulging in group meditation and rediscovering inner harmony.

Women Of Sandhata At Manavata  Event

Joining the event, the Women of Sandhata (WOS) team seized an invaluable opportunity to connect with individuals who share their vision for a brighter, more inclusive society.

The post Sandians at Manavata 3H Family Retreat, UK appeared first on Sandhata.

One of our internal continuous improvement teams have recently launched an exciting new project:

Gini – A chatbot for Sandians

This chatbot is a first-line support system. It was built to assist Sandians with some of their internal tasks and to relieve load from support teams. Gini is configured with single sign on (SSO), and has integration with HRM tools.

We have enabled self-service for many common queries, including:

• IT support issues
• HR related questions such as policy information
• Timesheet assistance and user guide
• Internal training support
• Finance and salary queries

Our chatbot has helped to reduce the number of similar queries which are received by the support team and HR team, amongst others.

Innovative Solutions

At Sandhata we foster the innovative mindset which encourages people to always look out for things to improve.

The idea for the chatbot was born from the awareness that certain queries were being asked very often. We wanted to enable self-service for Sandians and to improve the efficiency of internal tasks. A team was setup to understand the current state and design a solution. The resulting chatbot, Gini, was designed and built by our in-house teams.

This chatbot is an example of the way we embrace innovation in Sandhata. We are continually improving our systems and processes to streamline the way we work, provide a better experience for our employees, and in turn, enable better customer service.

The post Sandhata Gini – Our internal chatbot appeared first on Sandhata.

Besides delivering specialised consulting services to a wide range of clients, we have doubled down our focus on our employees. We have taken the opportunity to meet up face to face as much as possible and put on more events than ever to build team spirit and collaboration.

Here is a quick run down of some of the things which happened in 2022.

Our People

Since Sandhata’s formation in 2005 we have fervently donated and supported our chosen charity Manavata. We kept this up in 2022.

Many of our team in Hyderabad participated in a blood donation camp. The team also turned out to support World Bicycle Day in June. This draws attention to the benefits of using the bicycle — a simple, affordable, clean and environmentally fit sustainable means of transportation.

We were very proud to be recognised as a Great Place to Work this year. More than 80% of Sandhata’s employees rated Sandhata as outstanding across all categories: credibility of management, respect for people, fairness at the workplace, pride, and camaraderie. More than 90% of our respondents said they have a strong sense of pride that they work for Sandhata.

Many of our team have been craving more face to face interaction. We have brought the teams together with a very successful family day in the UK, and a week-long event in Chennai with team building, sports, games, speakers and prizes!

In September 2022 we opened a new office in Hyderabad’s popular IT corridor.

Wellbeing

With the past few years being so tough, we have had a firm focus on our people’s wellbeing. We have run numerous events with this in mind including:

• desk workout sessions
• Zumba online
• Fun and stress busting events e.g. spin the wheel, Fun Friday, scavenger hunts
• Workshop on emotions

Ten members of UK team also participated in the JP Morgan Corporate Challenge 2022. The 5.6k run around Battersea Park was a great motivator for the team to get fit and a really fun team building event.

Babji Vundavilli, keen painter and COO Sandhata paid tribute to Queen Elizabeth II by helping to paint a mural of her in London.

Sandhata Premier League

This year saw the first Sandhata Premier League tournament. The event saw 8 teams competing across a range of events to lift the trophy.

Events included performance, cooking, truth and lie games, poetry and videography. It required teams to give it their all and think of creative solutions to problems.

The tournament brought together people from different teams, geographies, skill sets and customers. It truly brought Sandhata together. We are looking forward to SPL 2023!

Women of Sandhata

In March 2022, on International Women’s Day, we launched our new women’s network: Women of Sandhata.

Since the launch of the Women of Sandhata network, we have provided face to face events for women, external speakers, workshop and training sessions, and social and networking events. Since 2020, we have increased the percentage of women employees at Sandhata from 15% to 30%. We hope the Women of Sandhata network will help us reach 50% women in Sandhata.

Expanding our Technical Offerings

In April 2022, we launched our new API Platform. We are now able to support our clients better by providing them with API services or a fully hosted API Platform. We have been releasing new APIs for customers throughout the year.

We have also launched our Instagram channel this year to give a glimpse into life as a Sandian.

Award? What Award?

We have had a bumper year for awards in 2022!

We are proud to have been chosen as:

• Winners – Best “DevOps Service Provider”at DASA DevOps Awards 2022.
• Winners – “Best Use of Data” and “Transformation through Technology” at the UK Business Tech Awards 2022.
• Highly Commended – “Leading DevOps Vendor” at the DevOps Industry Awards 2022.

• Janani Priya, Sandhata test analyst, wins Graduate Tester of the Year 2022.
• Winner – Deloitte Technology Fast 50 India 2022.

Roll on 2023

We are really looking forward to where 2023 takes us!  Follow us on Instagram, LinkedIn or Facebook to hear our updates first!

The post Goodbye 2022 appeared first on Sandhata.

Janani Priya joined Sandhata Technologies in 2020, as a trainee analyst. Since joining the team, she has seized every opportunity given to her, been proactive in upskilling herself on technologies and project-specific information, including completing self-led training in her personal time. Janani has worked on projects including microservices and API testing, system and integration testing, and both manual and automation testing.

Janani has also been a great contributor to Sandhata internally. She takes ownership of activities outside of her daily role, for example blogging (here and here), employee advocacy, mentoring, and assistance with management of Sandhata’s women’s network.

She is incredibly self-motivated, a hard worker and quick to learn, and she has great potential.

Janani has come such a long way in less than 2 years since she joined us. We are so grateful for your hard work and commitment to Sandhata, Janani. Thank you!

The post Janani Priya – Finalist for Graduate Tester of the Year 2022 appeared first on Sandhata.

More than 80% of Sandhata’s employees completed the Great Place to Work survey, and rated Sandhata as outstanding across all categories: credibility of management, respect for people, fairness at the workplace, pride, and camaraderie.

More than 90% of our respondents said they have a strong sense of pride that they work for Sandhata.

Great Place to Work® is the global authority on workplace culture. Since 1992, they have surveyed more than 100 million employees worldwide and used those deep insights to define what makes a great workplace: trust. Their employee survey platform empowers leaders with the feedback, real-time reporting, and insights they need to make strategic people decisions.

The Institute serves businesses, non-profits and government agencies in more than 60 countries and has conducted pioneering research on the characteristics of great workplaces for over three decades.

“At Sandhata, everyone knows that the most important part of our business is our people. From the founding of Sandhata, we have always strived to create a welcoming, supportive environment and prioritise integrity in all our interactions with our employees. We are very proud to have received this public recognition of our outstanding workplace culture.”
– Babji Vundavilli, COO

In India, the institute partners with more than 1100 organizations annually across over 22 industries to help them build High-Trust, High-Performance Cultures designed to deliver sustained business results. Hundreds of CEOs and CXOs from India Inc. are part of the great place community that is committed to the vision of making India a great place to work FOR ALL^TM.

The Institute’s research shows that great workplaces are characterized by great leadership, consistent employee experience, and sustainable financial performance. These organizations can deliver a consistent experience to all their employees irrespective of their role, gender, tenure, or level. Their leaders believe in the vision of creating and sustaining a Great Place to Work FOR ALL and role models being ‘FOR ALL’ Leaders.

Learn more about Great Place to Work® and on LinkedIn, Twitter, Facebook and Instagram.

Are you ready to take the next step in your career with Sandhata?

Find out more about joining our team. 

The post We are Great Place to Work – Certified! appeared first on Sandhata.

Sandhata put forward a 10 person team for the recent JP Morgan Corporate Challenge 2022.

The team spent the day together in the office getting psyched up for the run over a shared lunch.

Some of the team were regular runners, but for some it was the first time running!

It was great fun, although a bit hot, and all the team members completed the run successfully.

Looking forward to next year!

“Love this race as running with 15,000 runners is always fun! This year is special as 10 of my team members joined with me ”

Babji Vundavilli

“In running, it doesn’t matter whether you come in first, the middle of the pack, or last. You can say ‘I have finished’. There is a lot of satisfaction in that.”

– Pravin Durai

“In everyone’s life always a moment comes when you can either quit or say to yourself ‘I can do this’. Similar feeling I was having yesterday. It doesn’t matter when it started or ended, I did it! My first marathon ”

– Amrita Sriwastava

“Life is a race, whether it’s corporate or personal. I finish every race and enjoy those moments.”

– Mayank Gupta

“It was a really fun event, and great to participate together with the Sandhata team. Hopefully we can field a bigger team next year ”

– Bronwyn Davies

“If I’m free, its because I am always running.”

– Avinasha Shukla

“It was a really different experience running with the team representing Sandhata, 100+ companies across the UK, massive crowd, evening race – amazing experience! Babji was so inspiring for any young runners. Although I was a bit tired before the start, the energy of the crowd really pushed me hard! Well done team!”

– Subhas Chandra

“Running is never boring, it always brings the best out of you. It teaches you perseverance and to just give that extra and push yourself, challenge your limits. Whether it is sunny, cloudy, cold, a run is always re-energizing. I consider myself lucky to have teamed up with brilliant people from team Sandhata! Very well done everyone, we are all finishers! Cheers to that!

– Vikas Dange

“It’s my first 5k and it felt so great crossing the finish line. I thoroughly enjoyed it. A great experience running along with thousands of other runners. Realised how much fun it is to run.”

– Bharat Muppidi

The post Go Team Sandhata! appeared first on Sandhata.