KPIs – Sandhata

APIGEE: The Swiss Army Knife of API Management (and Why Your Business Should Care)

Karthikeyan Dhanapal — Tue, 12 Aug 2025 12:23:24 +0000

Think of your business like a thriving city. You have neighborhoods (applications), roads (data connections), and commuters (users and services) moving back and forth every day. Now, imagine if every road had its own toll rules, speed limits, and traffic lights, all designed by different contractors. Chaos, right?

That is where Google Cloud Apigee steps in. It acts as your city planner, traffic controller, and security chief for all things API. It does not just open the gates between your systems. It manages, secures, and optimizes every interaction so your “city” runs smoothly no matter how big it grows.

In practical terms, Apigee is an enterprise-grade API management platform that supports REST, SOAP, gRPC, and GraphQL, making it the equivalent of a universal translator for your digital ecosystem.

It is not just about making connections. It is about keeping those connections secure, scalable, and profitable.

The API Lifecycle: Apigee’s Playground

Managing an API without structure is like trying to run a restaurant without a kitchen order system. Orders get lost, chefs step on each other’s toes, and customers wait far too long. Apigee solves this by guiding APIs through their full lifecycle:

Design – APIs start life with the OpenAPI Specification, written in JSON or YAML. This is your blueprint, like architectural plans before you build a skyscraper.
Develop – Apigee’s API proxy stub acts like scaffolding for developers, preloaded with policies for security, rate limiting, and more.
Secure – Guard the doors. Apigee bakes in security via OAuth, JWT, and IAM without developers having to reinvent the wheel.
Deploy – Launch your API with minimal friction and the confidence it will not crumble on day one.
Publish – Expose your API to consumers through portals that make onboarding painless.
Monitor – Keep a hawk’s eye on performance, availability, and anomalies with Apigee’s monitoring tools.
Analyze – Use insights to improve API performance and plan future updates.
Monetize – Turn APIs from cost centers into revenue streams by packaging and pricing them like products.

This is not theory. With Apigee, these steps are not just manual checklists. They are woven into the platform’s DNA.

Apigee API Proxies: The Bouncers and Concierges of Your Data Club

Imagine you own a nightclub. You do not let just anyone wander in backstage, and you also make sure VIP guests get the premium experience.

That is what Apigee API proxies do. They sit between your consumers and your backend services, controlling who gets in, where they go, and what they can do once inside.

Flows: The “routes” data travels through inside your API.
Variables: The behind-the-scenes notes your system keeps, like a bartender remembering your drink order.
Conditions: “If-then” rules, for example, “If you’re on the guest list, skip the line.”
Policies: Prebuilt, reusable rules for security, rate limiting, and transformation.

And when things go wrong, Apigee’s Trace Tool works like CCTV footage, showing every step a request took so you can fix issues fast.

Variables & Conditions: The Rulebook

Variables in Apigee are like game stats, constantly updated with information on the player (request), environment, and score (response). These can be predefined or custom, allowing you to control the flow with surgical precision.

Conditions let you act only when the rules fit, like opening a bridge only if the ship’s height is under a certain limit. You can chain conditions using AND or OR, or even go full detective mode with JavaRegex for advanced pattern matching.

Policies: Automation With Brains

If variables and conditions are the rules, policies are the automated referees. They are XML-defined chunks of logic that Apigee runs only when conditions are met.

For example, a Quota Policy might cap requests to 1,000 per minute per user. That is like letting people into your shop but not allowing anyone to clear the shelves in one go.

Flows: The API’s Commute Map

Every API call in Apigee follows a “flow,” like a train route with stops.

First stop: Proxy Endpoint, where requests are validated.
Next: Route Rules, which decide which backend service to send it to.
Final stop: The backend system responds, and the flow reverses to deliver the output to the consumer.

The point? Structure and predictability, even when your APIs are juggling hundreds of thousands of calls per minute.

API Security: Because the Internet Is Basically the Wild West

If APIs are the highways of your digital city, security is the border control. Apigee doesn’t just stand at the gate; it verifies passports, scans for contraband, and keeps detailed logs of every crossing.

Three key players:

1. OAuth Tokens

Think of OAuth like valet keys. It lets someone drive your car (use your API) without giving them your full key set (credentials). The authorization server issues these tokens, controlling access without oversharing.

2. JSON Web Tokens (JWTs)

JWTs are like sealed envelopes. The sender signs and seals it, the receiver checks the seal before trusting the message. If it’s tampered with, it’s immediately obvious.

3. Cloud IAM

Google Cloud’s Identity and Access Management is your HR department for API access , assigning roles and permissions without handing out master keys to everyone.

Why Apigee?

There’s “good enough” API management, and then there’s Apigee-level API management.

Apigee isn’t just a gateway. It’s:

A governance engine – Catching misconfigurations and rogue traffic.
A monetization toolkit – Packaging APIs into products you can actually sell.
A multi-cloud navigator – Keeping performance steady even if your backend lives in multiple environments.
A scalability beast – Handling API spikes like a champ without sacrificing speed or uptime.

For enterprises dealing with high API call volumes, external partner integrations, and security-sensitive workloads, Apigee is less “nice-to-have” and more “why-didn’t-we-do-this-sooner?”

Real-World Use Cases

Where Apigee shines:

High API Volumes – E-commerce during Black Friday. Payment gateways on salary day.
Modernizing Legacy Apps – Wrapping old systems with fresh APIs without ripping them apart.
Multi-Cloud Ops – Serving customers from AWS, Azure, and GCP without missing a beat.
Digital Transformation – Accelerating change without security breakdowns.
Microservices Architectures – Keeping dozens of services talking without mix-ups.
Enterprise Security – Meeting compliance while staying developer-friendly.
API-Driven Apps – Powering platforms whose business model is the API.

Conclusion: Apigee as Your API Business Partner

Basic API gateways are like opening your backyard fence and letting anyone walk in. Apigee is more like building a guarded, ticketed, monitored park — complete with CCTV, staff, and a profit-making gift shop.

Its full-lifecycle management ensures your APIs aren’t just “live” — they’re performing, secure, and aligned with business goals. Whether it’s handling unpredictable traffic spikes, protecting sensitive data, or turning APIs into revenue-generating assets, Apigee has the tools and governance to make it happen.

In an era where every business is a tech business, your APIs aren’t side projects. They’re critical infrastructure. And infrastructure deserves professional management.

Apigee doesn’t just help you manage APIs — it helps you manage growth, security, and opportunity.

Because when your digital city is growing faster than ever, you don’t just need roads — you need the whole traffic management system. And that’s exactly what Apigee delivers.

Your APIs are already the lifeblood of your business. Now it’s time to give them the management, security, and performance they deserve. Let’s design your digital city together, starting today.

Talk to Our API Experts → https://www.sandhata.com/contact-us

The post APIGEE: The Swiss Army Knife of API Management (and Why Your Business Should Care) appeared first on Sandhata.

Sandhata Forms Partnership with Splunk

Roohi Razi — Wed, 01 Sep 2021 16:37:20 +0000

1st September 2021– Sandhata announces new partnership with Splunk Technologies to work together to provide bespoke dashboards and self-service analysis capabilities to its customers. Sandhata is using Splunk’s market leading machine-learning analytics capabilities to turn data into answers, and give businesses the real-time, actionable data they need to make the right decisions.

The Splunk platform has been integrated fully with Sandhata’s DevOps Innovation Platform on the Sandhata cloud environment. The DevOps Innovation Platform environment allows Sandhata to provide customised demos to their clients, giving the clients an idea of what they could achieve in their own systems, with no upfront investment.

Dashboards are key enablers for collaboration within and across teams, and they are excellent at driving the application team in the right direction. Other capabilities of dashboard include easy access of log view with all search functionalities, one-stop shop for all application data, enabling immediate self-service analysis and connect details for each service in one place.

About Splunk

Splunk’s market leading data platforms are widely used across a wide range of industries, focused on enabling clients to thrive in the age of data. Splunk has a large, engaged developer community and provides enterprise-grade expertise and support to its clients.

About Sandhata

Sandhata is a global technology integrator, specialising in all aspects of DevOps. With a team of highly skilled professionals, they deliver Advisory, Management and Technology consulting innovation for clients in some of the most demanding, regulated industries. With a genuine dedication to helping their clients navigate the IT landscape and introducing technology that will support their strategic goals, Sandhata is able to modernise every aspect of service delivery and offer guidance through the challenges of making the right strategic decisions.

Sandhata also supports clients in managing the many aspects of change that come with transforming IT infrastructure or operations. Through working closely with many of the world’s most forward-thinking organisations in Finance and Banking, Telecommunications and Retail, Sandhata has helped them create and maintain a sustainable, secure and compliant digital business.

Learn more about Sandhata’s DevOps services.

The post Sandhata Forms Partnership with Splunk appeared first on Sandhata.

Introducing the Sandhata DevOps KPI and Analytics Advisory Service

Bronwyn Davies — Thu, 04 Jan 2018 10:20:55 +0000

4th January 2018 We are very proud to introduce the Sandhata DevOps KPI and Analytics Advisory Service – a unique service approach that aims to empower your DevOps and Agile teams with structured and automated metrics to help you achieve your strategic objectives.

In recent years, DevOps has become an established methodology that has helped countless businesses to accelerate their output and improve IT delivery.

However, while DevOps as a concept has become more commoditised, many organisations are struggling to achieve the change they had hoped for, and are unable to confidently report how successful their DevOps initiative has been.

The Sandhata DevOps KPI and Analytics Advisory Service is designed to support organisations to achieve the maximum business benefit from their DevOps programme by ensuring that business impact and strategic progress is accurately measured every step of the way.

With the help of our tailored outcomes-driven KPI framework and experience working with a range of strategic goals, we provide businesses with a greater chance of DevOps success.

Want to learn more?

Download the Sandhata whitepaper Building an Outcomes-Driven KPI Framework or contact our team.

The post Introducing the Sandhata DevOps KPI and Analytics Advisory Service appeared first on Sandhata.

How we built a Live DevOps Innovation Platform

Bronwyn Davies — Wed, 10 May 2017 11:45:10 +0000

We recently announced the arrival of our Live DevOps Innovation Platform built in-house here at Sandhata. I wanted to share some of the tools we have used for it so far, as well as my personal experiences on this platform, as it has been very interesting and a big learning experience for me.

The DevOps Innovation Platform project was launched in August 2016. We began by building a very simple application, called Sandhata Bank, using public APIs available from the Open Bank Project. This meant we didn’t have to build an entire banking back-end.

The foundations

The first few weeks were spent designing and building the environment, configuring our Docker setup, and building a Continuous Delivery pipeline framework using Jenkins.

From there we have continued to integrate open source tools, including:

Gradle for build automation
SonarQube for quality control
Junit for unit testing
Karma and Selenium for web testing
BIRT for transactional dashboards
Zabbix for monitoring

Enterprise products

Once we had a good working open source model, we started to incorporate enterprise-licensed products. We have analysed the market and sought to include the products we believe are industry-leading in various areas.

So far, in addition to the many open source products, the Platform features:

AWS as a cloud provider
digital.ai Deploy for deployment automation (formerly XebiaLabs XL Deploy)
digital.ai Release for release management (formerly XebiaLabs XL Release)
IBM Rational Test Workbench for Message Based Test Automation & Service Virtualisation
CA DevTest for Test Automation & Service Virtualisation
TIBCO BWCE for micro services
CA Test Data Manager for test data management
CA Agile Requirements Designer for Requirements Modelling & Test Case Design
CA API Gateway or API Management
TIBCO Spotfire for KPIs and business intelligence

DevOps principles

From the very beginning, we have followed DevOps principles of continuous improvement and collaboration in working as a team. We started out using Phabricator as our task management system, while following Agile practices (sprints, scrum meetings etc). We have since progressed to using Agile Central as our task management system as it offers more mature features.

This open way of working has allowed us to evaluate more than 30 different tools and has given each team member responsibility for their area of focus and the tools available.

The DevOps Innovation Platform project has been a great opportunity for every member of the DevOps Platform team to work with many new technologies and gain a real breadth of skills. Each person has been involved in researching the wide spectrum of new technologies and building POCs to gain deeper understanding of the products, whilst helping to ultimately decide which tools should be included.

Continuous customer feedback

I personally have found this process incredibly interesting, and a great opportunity to get my hands on some of the hottest tools around. With each tool and process addition to the Platform, we have demonstrated these to our clients, and their feedback has kept us eager to keep going.

Our conversations with clients and partners have been so enriched by this Platform, as it allows us to easily demonstrate our understanding and experience of each focus area, that it is a springboard for meaningful discussion.

Plug-and-playground

The other brilliant aspect of this Platform is that it is a working, complete real-life application ecosystem. So when new tools come along, we already have the perfect playground to download, install, and play around with the tool to get up close and personal with it. As we already have hands-on experience with the tools, we can provide better, completely personalised advice to clients based on our breadth of experience with the different toolsets available.

We are working on enhancing the Platform as I write, and adding new features and tools all the time.

I look forward to keeping you up to date with our new additions as they come through!

Want to know more?

Take a look at the Platform page or contact us on +44 20 7680 7105 for a no-obligation product review.

The post How we built a Live DevOps Innovation Platform appeared first on Sandhata.

Introducing the new Live DevOps Innovation Platform

Bronwyn Davies — Wed, 26 Apr 2017 05:30:02 +0000

In 2016 we started creating a live DevOps innovation platform internally in Sandhata. We have been working hard, with the goal of creating a platform which incorporates DevOps principles and practices across the whole delivery lifecycle. We want this platform to demonstrate various aspects of the delivery lifecycle, and expose the inner workings – so that the platform can be used to help others get a headstart on their continuous delivery journey and also plan their DevOps strategy based on our working example.

On this platform, we have built a fully-featured application called Sandhata Bank. This is an evolving implementation of our knowledge and interpretations of best practice. Some of the principles and technologies demonstrated are:

Smart infrastructure and environment using containers and cloud

Docker
AWS
TIBCO BWCE (microservices)

Continuous business risk assessment using continuous testing

CA Test Data Management
CA Agile Requirements Designer

Controlled, secured and accelerated release automation

XL Deploy and XL Release
CA Release Automation

Continuous monitoring and optimisation using Sandhata’s outcome-driven KPI framework

TIBCO Spotfire

Over the past few months we have started using this platform in our conversations with customers, and it has really enriched our discussions, enabling us to show customers our solutions rather than just telling them.

What’s on the roadmap?

We have big plans for our DevOps innovation platform, and we are excited about adding new technologies and new processes to it.

In the short term, our plans will focus on:

Building a microservices application
Introducing microflows and API management
Enhancing the KPI framework based on our industry-leading expertise
Implement continuous operations and continuous feedback loops
Incorporating our Swift in a Box service – to show how service virtualization can speed up delivery

Is there anything specific that you would like to see in the innovation platform?
Contact us to let us know, and we will add it to our roadmap.

Want to know more?

Get more information about the DevOps innovation platform HERE.

The post Introducing the new Live DevOps Innovation Platform appeared first on Sandhata.

Dashboard Everything

Bronwyn Davies — Wed, 08 Jul 2015 15:59:17 +0000

Across all application teams, but particularly those who are trying to embrace DevOps principles, dashboard technology has an important role to play. Dashboards are key enablers for collaboration within and across teams, and they are excellent at driving the application team in the right direction. They can be the boost that your team needs to get to the next level in your DevOps journey.

Just some ways that dashboards can help your team:

Automating the collection and display of data means that we cannot become subjective in our successes and failures, as there is no way to hide from the numbers. It is difficult to argue with raw data, especially when it is unambiguous and displayed for all to see.
A well-designed dashboard can help to determine the success level of a release, which ensures that it is in everybody’s interest to have successful releases which provide business value.
Dashboard technology can help the team culture move to where you want it to be by highlighting things which may be being overlooked at the moment.
They unify the goals of all team members (dev/test/ops etc), and starts/keeps them working in the same direction.
Once the data collection is automated, more accurate, reliable measurements means problems are more transparent, people can see them and talk about them with no blame.
When things get better, then the material and hard facts are available to publicise and evidence the progress that has been made.

The best way to start if you are unsure what to display, is to dashboard everything: if numbers are available and they can be easily charted, put them on a graph. It will soon become obvious which data is useful and which is not. This will then drive ideas of what to monitor and improve goals. Dashboards need to be evolving so they stay relevant and people continue to look to them to be informed.

Team dashboards are those which are for the whole team (dev/test/ops etc.) and should be application based. The other most common type of dashboard is for ops analytics, which generally display data about the performance of a system or its components and can be low level e.g. CPU usage. I will focus on team dashboards in this post.

In my mind, there are 3 ways to setup team dashboards:

1. Display data which is purely driven from the business goals. This helps to ensure that what is being delivered is in fact what the business needs. These dashboards can keep team members unified and constantly encourages everybody to think about the business value which will be gained from a particular delivery. This can trigger ideas for how to achieve more business value even outside of project scope. The dashboards can also drive consistent status reporting, to ensure that both ops and dev are reporting on the same data and being rewarded based on the same goals. This prevents both ops and dev highlighting their individual successes and glossing over anything which was less successful.

Example data which can be displayed:

Total number of users logged in this month
Total number/value of purchases this month
How many new users this month
Usage of newly released services – are they actually bringing in revenue?

2. Display data to solve/address particular challenges that the team is facing right now. These will all be related to business goals underneath, but it may be that highlighting these issues specifically can help people to focus on resolving these issues as a priority.

Example issues which can be highlighted by displaying specific data:

If there are too many concurrent releases and the team is struggling to manage them, then display the difference in what version is released to test vs prod and don’t allow that difference to get past a certain number
Too many users who sign up to the service then never return
If there are slow response times which nobody wants to take responsibility for
The current status of builds and if they are broken – to prevent broken deployments
Can be used for identifying progress in resolving a critical issue eg a security patch that needs to be rolled out across all services

3. Display information about what team members are doing. If people are more aware of what is happening then credibility will be built up and this can help to build better relationships across teams. Also this gives people the opportunity to proactively identify changes and improvements they wish to make as they will be aware of what is going on in the wider team.

Example data which can be displayed:

Current status of ongoing projects ad who is working on them
Current status of bug fixes
Any improvement initiatives which are underway

In many ways, the 2nd type of dashboard can be most useful to start with, particularly if you are on a DevOps journey and still in the transition state. It can help galvanise the team and importantly, help to change the culture, or at the very least assist the cultural changes to be embedded.

The post Dashboard Everything appeared first on Sandhata.

How can we measure the success of DevOps?

Bronwyn Davies — Fri, 27 Mar 2015 11:58:04 +0000

A key part of your DevOps programme, and instrumental in its success, is how DevOps and your applications are measured. If this measurement is done well, it will provide accurate ROI, help you to manage progress towards your DevOps goals, and be a great help in evangelising DevOps success.

Metrics supporting the business

Well-defined and relevant metrics also help to focus the organisation on delivering the right business outcomes. They make sure that every change implemented is a step towards achieving a defined business goal. However, metrics used badly can stall or even reverse the cultural changes in progress. This will delay your DevOps ambitions and disrupt your long term goals. Bad metrics can for example be ones that put different teams in direct conflict – which is the very state we are trying to move away from.

For the most accurate information on your progress, start measuring from day 1 of your DevOps journey – or earlier, if possible. This allows you to compare your current state with your starting point throughout the entire process.

Measuring issue resolution

A good metric to start measuring might be MTTR – Mean Time To Recovery. This measures how long it takes for an issue to be resolved in production. High MTTR generally translates to long downtime for the customer or business users, which results in loss of revenue and direct business impact. Low MTTR corresponds with high availability, fast responsiveness and minimal customer impact.

With low automation, high MTTR is generally down to the manual nature of a lot of the work required for releases. When a manual release goes wrong, a manual rollback or hot fix is often rushed in. This change can bring increased risk, as the rollback process is not likely to be thoroughly tested under the added time pressure. If a quick hot fix is needed, the developer will write the code quickly and try to get as much testing as possible done before the hot fix deadline. But without continuous integration and continuous delivery, the full set of tests (including regression tests) will inevitably not get run.

Reducing MTTR directly translates to better reliability and better customer service. It creates cohesion within the entire application team, as there is no conflicting goal between any groups.

Encouraging innovation

Something which goes hand in hand with measuring MTTR is not being afraid to innovate and make mistakes. With a low MTTR we have greater confidence that any problem can be resolved quickly, so the impact of issues in production is not so high. This means that each issue becomes less critical. This attitude relies heavily on underlying cultural change to encourage innovation and not focus the blame on incidents.

When creating goals and metrics for tracking progress, the final key characteristic I want to highlight is the creation of goals that are applicable to each stakeholder. This means that everyone can take ownership for achieving them. Having individual goals for each team member should encourage success, as everyone has a vested interest.

What works for your business?

In this blog, I have only scratched the surface of the vast topic of metrics and measurement in DevOps success, but I will be discussing this more in future blogs. Please let me know if you agree or disagree, and if you have any other useful metrics that you have seen used successfully – or badly, for that matter!

I have touched on one particular metric here, which is useful for some organisations adopting DevOps. Our recent white paper goes into much more detail about KPIs for DevOps success from a broader perspective, including tips and tricks to build a KPI framework suited to your organisation.

The post How can we measure the success of DevOps? appeared first on Sandhata.

Seven Steps to Start Your DevOps Initiative – Part 2

Bronwyn Davies — Thu, 19 Feb 2015 12:24:30 +0000

This blog follows on from last week’s Seven Steps to Start Your DevOps Initiative – part 1. The paper “Seven Steps to Start Your DevOps Initiative” by Ronni Colville (2014) lists 7 key recommendations for successfully implementing DevOps. Below I continue my discussion and share my insights for steps 5 – 7.

5. Change the Metrics

Defining meaningful and actionable KPIs is one of the best ways to focus the organisation on delivering the right business outcomes. Making sure the metrics are based on clear business outcomes means each improvement delivered should have a positive impact on the business. In this way, feedback loops can be used to assess progress against the business goals, and they will provide motivation and drive to spread DevOps throughout the organisation.

For example, instead of aiming for a specific frequency of releases, aim to be able to deliver for the customer, which may involve being able to release a new product on the website within a specified amount of time. Once the metrics have been agreed upon, make sure they are relevant for all teams (dev, ops, test, security etc.). Business objectives which have tangible goals for delivery teams on the ground will create shared targets, a collaborative culture, and remove the conflicts which are usually present e.g. new features vs. stability.

Importantly, KPIs and metrics also need to be consistently implemented across the company. Inconsistent goals mean that tangible business value will be difficult to achieve, and it will be hard to measure the success of your DevOps transformation. In the worst case, having badly defined metrics can guide undesired behaviour and even set back the DevOps progression.

6. Automate as much as possible

Implementing automation in an application team can be the easiest way to get started on the DevOps roadmap. When considering automation, it is always important to think about the business goals (identified in step 1) and align the automation goals to those. This way, the feedback loops can input into the automation strategy and it will help to identify if the automation is providing enough real business value.

Team culture is an important consideration when implementing automation for the first time in a team. Generally, job roles will evolve once the repeatable tasks have been automated. This will have an impact on the staff, who should be able to progress on to more interesting and critical tasks. If operations engineers are not satisfied, it can be stressed that operational knowledge will always be key and operational roles have not been made redundant. This change should be communicated effectively so that all team members understand the future of their roles. Job satisfaction can and should improve as an outcome of the DevOps changes, as roles will evolve to include more creative and important tasks. Change management is a critical part of DevOps, and is often the difference between a successful or failed DevOps programme.

7. Consider a Toolchain

In my experience, creating a shared DevOps toolchain will really benefit the collaborative culture between teams. Once established, the same tools (usually) are used by all team members and this is a key enabler for successful and ongoing collaboration. It can also streamline and consolidate processes as duplicate entry into 2 or more similar systems is no longer required.

When creating a DevOps toolchain, identify the complete chain, and what the end state looks like. Once a complete toolchain has been established and is in active use by all stakeholders, then the biggest benefits will be seen. Traceability is a key benefit of a complete and integrated DevOps toolchain, as requirements can be traced easily through to the work items and release artefacts. As the same tools are used across the team, all team members and stakeholders can access the same data to make informed decisions.

Final thoughts

This concludes my thoughts on the “Seven Steps to Start Your DevOps Initiative” paper. Since this paper was published the DevOps movement has progressed in many areas. Some areas of DevOps which have not been discussed in much depth here are covered in more detail in other Sandhata whitepapers and blogs:

Learn More

To discover the difference DevOps can make for your business, take a look at our Solution Brief: The Sandhata DevOps Approach.

The post Seven Steps to Start Your DevOps Initiative – Part 2 appeared first on Sandhata.