Most discussions on Platform Engineering and Internal Developer Platforms (IDPs) start with a familiar goal, reduce cognitive load for software developers.

That is a valid objective and it is usually where IDP conversations begin. However, when we started working on an enterprise-grade platforms, we saw a different problem surface very quickly.

The biggest friction was not only with application developers, it was also with the teams who were expected to build, maintain and automate the infrastructure and Platforms that everyone else depended on.

Our initial brief was to create a platform engineering solution that includes best practices, customizable and extensible IDP and right skills to manage all this in one place. We successfully created all these with focus major focus around developer productivity. At the same time we went deeper into day-to-day operating challenges, we made a deliberate shift. We started treating automation engineers, SREs and infrastructure operators as first-class users of the platform. That change in perspective helped us design something more useful, not just a catalogue, but a working environment where platform teams could create, test, govern and operate automation more consistently. We actually repurposed the entire platform engineering solution for platform engineers , infra operations engineers, SREs , network reliability engineers etc. Now the same concepts of platform engineering meant for software developers are used for automations and GenAI related developers but specifically for platform and infrastructure provisioning, upgrades and operations related automations. 

The Hidden Bottleneck in Application Operations

In many large environments, application operations slow down because application operations, middleware platforms automation is scattered. We saw scripts sitting in different repositories, infrastructure-as-code being executed from individual machines and application and platform release knowledge living with a few experienced engineers. None of this was due to poor intent. It was simply the result of teams solving urgent problems over time without a common operating model. The impact became visible whenever an application team needed a new environment, a release pipeline update or a configuration change. The request usually turned into a ticket and the waiting began.

What became clear to us was that the delay was rarely about capability. The Applications operations teams knew what they were doing. The real issue was that every change required too much manual effort, too much context switching and too much careful validation. If we wanted to improve application release cycles, we first had to improve the daily workflow of the engineers who built and supported those release pipelines. HCL IDP solution became the place where we brought that workflow together.

The introduction of platform engineering and IDP for platforms proved to be the lifesaver in application operations. Now the Critical application release cycles are managed through one click automations. And all the automation scripts are kept in GitHub with core templets available through IDP, reusability jumped reducing turnaround time significantly.

Customizing Backstage for AppOps and Platform Management

Our IDP solution is based on backstage and backstage is strong at cataloging services and software components, but we needed it to represent the assets our AppOps and platform teams actually used every day.

We extended the catalog to include Terraform modules, CI/CD pipeline templates, operational scripts, Helm charts, configuration patterns and policy-as-code definitions. This gave engineers a single place to find approved automation assets instead of searching through multiple repositories or asking around for the latest version.

This small shift changed the usefulness of the platform. Automation engineers could see what already existed, understand dependencies, review execution history and reuse patterns with more confidence. Over time, this also reduced the number of one-off solutions being created for similar environment and release requirements.

HCL IDP–bundled AI-Driven Code Generation

The HCL IDP solution as part of CARE framework, has been significantly modified and multiple additional features are added in past few years. All these additional features are based on client feedback and based on advanced technical changes taking place.

One of the more practical additions we made was an AI-powered assistant inside the IDP experience. We did not position it as a replacement for engineering judgement. Instead, we used it to remove some of the repetitive effort involved in writing platform automaiton and configuration code. AppOps SREs still reviewed, adjusted and validated the output, but the starting point was much faster.

The assistant was tuned around our internal architecture patterns, security expectations and preferred tooling. For example, when an engineer needed a Kubernetes manifest, an Ansible playbook or a Helm chart for a specific release scenario, the assistant could generate a compliant draft aligned to our standards. The real benefit was not that AI wrote code. The benefit was that engineers spent less time producing boilerplate and more time thinking through risk, dependencies and operational impact.

Blueprints for Rapid Platform Deployment

We also learned that generating automation code is only half the problem. The more important question is where to test it safely. Earlier, engineers often had limited access to realistic test environments and validating an infrastructure change could require coordination across multiple teams. That created hesitation, especially for changes involving networking, database migrations, cluster policies or shared platform services.

To address this, we introduced platform deployment blueprints inside the IDP. These were not generic application templates. They were designed for platform-level validation and our flagship solution ePACE was used as an enabler. An engineer could create an ephemeral Kubernetes environment with the standard platform stack, apply a new script or configuration, observe the behavior and then tear the environment down once testing was complete. All this through ePACE running at the backend of IDP seamlessly.

This gave teams a safer way to experiment. It did not remove the need for proper review or change control, but it reduced the fear of testing infrastructure changes. Engineers could validate behavior in an environment that looked and behaved much closer to production, without putting active workloads at risk. The automatic cleanup also helped avoid the familiar problem of test environments being left running indefinitely.

Real-Time Observability for Operational Clarity

Another issue we wanted to solve was operational visibility. In practice, engineers often had to move between the IDP, log tools, monitoring dashboards and pipeline systems to understand whether a change had behaved as expected. That context switching slowed down troubleshooting and made it harder to connect a deployment action with its operational impact.

We brought key observability views into HCL IDP, so teams could see resource usage, latency, error rates and environment health in the same place where they initiated or reviewed platform changes. This made reviews more practical. If a new automation script increased resource consumption or introduced errors, the team could see the signal quickly and respond with better context.

Driving GreenOps with Sustainability Dashboards

As the platform matured, we also started looking beyond speed and reliability. Cost and sustainability were becoming part of the same conversation. We integrated Kepler, the Kubernetes-based Efficient Power Level Exporter, to give teams visibility into energy consumption patterns at the workload level. This was useful because it connected infrastructure efficiency with application design decisions.

For developers, this made efficiency more visible. Instead of only seeing CPU and memory numbers, they could also understand the energy impact of their services. We found this helpful in shifting the discussion from abstract sustainability goals to specific engineering choices, such as right-sizing workloads, reducing unnecessary background processing and improving inefficient code paths.

Transforming the Application & platform Lifecycle

Looking back, the most important lesson was that an IDP becomes far more valuable when it reflects the real workflow of the teams operating the platform. By focusing on automation engineers and SREs, we improved the foundation on which application teams depend. Scripts could be generated faster, tested more safely, reused more consistently and observed with better context.

The outcome was not a sudden transformation caused by a portal. It was a steady improvement in how environment management, release operations and infrastructure automation were handled. Application teams benefited because platform teams had better tools. Platform teams benefited because their work became more standardized and easier to validate. For us, that was the real value of rethinking the IDP: making it useful for the people who quietly keep the delivery engine running.