Platforms like ServiceNow and Salesforce (to name a few) were introduced to address and solve the many overwhelmingly burdensome tasks associated with building enterprise-specific applications and keeping companies agile, automated, and scalable. However, to adopt these platforms in the organization and maximize their value, they require development practices, principles, and discipline similar to classic software development.

Platform engineering, and Instance Management Platforms, emerged as a way to codify and standardize the management of the platform including its CI/CD production pipelines. However, in the age of low-code/no-code (LCNC) platforms like the ones named above, applying platform engineering principles to these platforms is beneficial for non-developers and classic developers alike. LCNC platforms allow developers to immediately focus directly on developing sound business logic without coding the requisite application logic. Theoretically, this should shorten the time to market and lower maintenance costs since the platform handles all the application infrastructure (memory, storage, network, etc.). However, it’s critical not to overlook that organizations onboarding citizen developers will face the same challenges pro-coders see in enterprise development. 

Addressing the Root Causes of Chronic Delays

Most prominent players are still experiencing chronic delays in their operations, so they have turned to platforms. However, they often quickly find that even with these platforms, they are still experiencing chronic delays at pivotal times in the development lifecycle, which can be due to several factors. 

Inefficient deployment practices, slow approval processes, and lengthy manual testing all contribute to delays. Fixed release schedules are another big contributor. When companies can’t release on demand, they have to wait for the next change window, which limits how often they can release to production.

Beyond this, for companies using platforms like ServiceNow or Salesforce, processes like cloning databases or instances to serve as production environments can also be time-consuming. Cloning is typically used to copy production data/information to pre-production environments to test developed changes. 

While cloning is necessary to align production updates across all non-prod environments, this process (typically being database-heavy) can take up to 10, 20, or even 30 hours. That’s a lot of time for developers to sit idle; lost time is only the tip of the iceberg. 

These are just a few of the hurdles platform engineering teams are helping companies overcome, and they are doing it in a variety of ways. 

First, platform engineering teams and technology are helping to navigate the transition from fixed release schedules to on-demand releases by introducing better infrastructure, tools and processes that enable continuous integration and continuous delivery (CI/CD) pipelines. Beyond that, with automated deployment processes, companies can push changes to production without manual intervention, allowing for frequent and smaller releases.

Second, when it comes to processes like cloning, automation and accuracy are everything. If platform engineering teams can automate and accelerate their cloning process, they can minimize the discrepancies between source and target. The key is to establish and standardize better ways to minimize downtime and errors so that the platforms themselves can support a better service delivery standard. 

Who Owns that Delivery Pipeline?

Governance and standardization are crucial elements in the context of platform engineering. The platform engineering movement began when software engineers realized that building a CI/CD delivery pipeline involved significant coding. They recognized that the pipeline itself should be treated as an application platform, requiring a dedicated team of engineers. 

Many enterprises don’t anticipate hiring people specifically to maintain and build delivery pipelines. They might assume that using cloud services means everything is automatically taken care of. Consequently, part of the development team’s time is often allocated to managing the delivery pipeline as an application, which can be feasible since they are already responsible for app maintenance. This hidden burden is typically integrated into the overall maintenance costs of all the applications the development team is working on.

However, issues can arise in delivery pipeline governance when admin privileges become too widespread, and deployment practices too inconsistent. Beyond this, platform environments can spiral out of governance when there are too many changes in non-production environments. 

This is where we are seeing platform engineering teams begin to own the delivery pipeline, and introduce more automation surrounding governance and deployment flows and around the software development lifecycle in general. The reality is that platform teams should be looking to operationalize governance in the same way they standardize how code is developed, built, and deployed. The tools are out there to mindfully and intentionally embed governance in processes, and the results are helping teams to become better aligned. 

Keeping Environments as Production-Like as Possible

Often, when companies think about platform engineering, they think about the pipeline, not what environment the pipeline is passing through, or how to keep non-prod environments as production-like as possible. Without this alignment, the classic ‘works in development, not in production’ conundrum may be inevitable. 

Successful platform engineering teams keep environments as production-like as possible because they understand the value of testing and pushing tiny snippets of code to reduce the risk of something going wrong. When new functionality is tested in production-like environments all the way through, companies can demonstrably reduce the risk by size and volume, and improve quality. This is all part of the practice of scaling and building sustainable large enterprise systems

Ultimately, platform engineering has been tasked with solving the enterprise development problems encroaching on developer’s lives, and there is still a lot of work to be done. Without a strategic approach to managing platform engineering within modern LCNC platforms themselves, the enterprise development community won’t be anywhere near close to delivering at the speed today’s business demands without compromising quality or compliance.

You may also like…

Platform Engineering is not (just) about infrastructure!

Analyst View: What’s new, what’s now, and what’s next in platform engineering