Is Platform Engineering the New Salesforce Devops?

We are all familiar with information technology (IT) hype cycles. A new one starts when a new technology or concept is first unleashed on the public. This phase is when early adopters start singing the praises of the new technology. Then there is an inevitable series of highs and lows that take place until the new technology becomes mainstream. In the world of building enterprise applications, the latest hype cycle is on Platform Engineering. Some have cried “devops is dead!” in the face of Platform Engineering. So, does Platform Engineering threaten our old friend, Salesforce Devops?

In this article, I will initially explain Platform Engineering and then Salesforce Devops. I will then posit that Salesforce devops companies have been pioneers in platform engineering, but now need to step up their offerings to remain relevant. I hope to show you that devops is still key to your Salesforce platform success. I’ll take you through the history of enterprise apps so you can paint the picture of how platform engineering has arrived. And I’ll give some advice on how Platform Engineering hype can get senior execs on board to help bigger companies produce better applications faster.

Platform Engineering Explained

Devops and other newer practices like system reliability engineering (SRE) are not being replaced by platform engineering. It is a natural evolution of devops, SRE, observability, and value stream management. Platform engineers are responsible for building and maintaining the underlying infrastructure that supports product teams. This includes orchestrating complicated systems like cloud computing platforms, container orchestration systems, continuous integration/continuous delivery (CI/CD) pipelines, and Salesforce release management activities. In many ways, platform engineering represents a new pinnacle of operational IT knowledge.

Another core philosophy of the platform engineering movement is to offer a complete stack of purposely designed app development tools. By design, enterprise platform solutions must include observability and value stream management. Used in combination, these tools produce a complete digital product with IT alignment built in.

Like a Center of Excellence

Platform engineering is an enterprise-wide service function much like a Center of Excellence. If you have been investing in Centers of Excellence, then a platform engineering team might be right for you. The platform engineering group should be conceived as a team of product-oriented software engineers. Their job is to deliver SaaS products that help teams write the best software. And platform engineering is also responsible to assure that solutions that comply with corporate standards.

Let’s dig deeper into the platform engineer’s toolbox by examining the Golden Path, Internal Developer Platforms, and a commitment to delivering a complete solution.

Understanding The Golden Path

A basic problem in IT management is getting everybody on the same page. This is especially true in cloud native devops where there are about 1,000 CI/CD building blocks described on the CNCF.io website. To address tool proliferation, The Golden Path refers to a well-defined, supported path for building and deploying software. It is a set of best practices, tools, and technologies that have been proven to work well together.

The Golden Path is not a one-size-fits-all solution. It needs to be customized to the specific needs of each organization. By following the Golden Path, organizations can improve the efficiency and effectiveness of their software development processes.

Understanding Internal Development Platform

The platform engineering team manages an Internal Developer Platform (IDP) that helps multiple teams build cloud native applications from scratch. An IDP is a collection of tools and technologies that enable developers to self-service their infrastructure needs. This is how platform engineering builds the underlying infrastructure that supports software development. The leading cloud native IDP is Backstage. It was spun out of Spotify as an infrastructure service that supports the management of hundreds of microservices.

The IDP has a key architecture characteristic that fascinates me in my studies of how enterprises build digital products. IDPs like Backstage are SaaS systems that help organizations make portals that create and deploy Kubernetes-based applications. In other words, IDPs are SaaS systems that manage cloud native deployments. The very nature of a SaaS system used as a development platform can help to unify efforts in large enterprises. This is because with an IDP, developers now have a place to go where they can share their efforts.

The Entire Solution

Platform engineering was conceived realizing that IT projects frequently lack alignment with enterprise goals. This problem runs deep, where application deployment specialists often have no idea (or don’t care) how their work relates to enterprise goals and value.

That is why observability and value stream management solutions are built into the platform engineer’s toolkit. With platform engineering, the aim is to create measurable devops processes which can be aligned to enterprise values. By prescribing solutions for value streams and observability, platform engineering can help to establish better management practices.

Understanding Salesforce Devops

Salesforce devops is more than just release management. One way to define Salesforce Devops is to refer to the 11 separate product categories I’ve identified for a complete Salesforce release management and enterprise digital product program. In short, my SalesforceDevops.net Industry Map defines devops beyond release management and highlights important topics like application lifecycle management (ALM) and VSM. I believe a well-managed Salesforce devops program that embraces every category of devops excellence has a better chance of producing digital products aligned with enterprise goals.

The Salesforce Metadata Digital Twin

But there is a problem with Salesforce where deploying new applications can be extremely problematic. Even when using a Golden Path in products like Salesforce DevOps Center, installing a change artifact in a Salesforce org doesn’t always work. This is especially true when you have larger teams working at the same time on the same codebase. These deployment errors occur because of the extraordinarily complex interactions that happen in a Salesforce org when making change requests.

Fortunately, most of the Salesforce devops platform vendors, plus some others like Elements.cloud, have learned how to ingest Salesforce metadata and create a digital twin of your Salesforce org. By managing an org’s metadata in an external SaaS system, these vendors gain important capabilities.

The main use for a Salesforce digital twin is to simulate making updates and changes to the org. The digital twin also predicts errors and suggests corrections to change artifacts. This digital twin capability can speed up deployments. Another key digital twin capability developed by Elements.cloud is to use change intelligence to detect the blast radius of proposed org changes.

Are Salesforce Devops Platforms Baby IDPs?

In platform engineering, deploying an IDP is partly designed to get your cloud native teams on the same page. Like the SaaS platforms deployed in platform engineering, Salesforce devops platforms are also designed to get your Salesforce teams on the same page.

If you have a well-implemented Salesforce devops platform, you are already performing platform engineering with a nascent IDP.

Consider for a minute about how platforms like AutoRABIT, Copado, Gearset, Opsera, Prodly, and Salto work. To varying degrees, each of these vendors manage workflow around Salesforce digital twins on SaaS systems that manage other SaaS systems. In fact, a few of them can manage other SaaS systems besides Salesforce, such as NetSuite, Workday, ServiceNow, and Zendesk.

Salesforce Digital Twin Drives Innovation

It turns out that complexity of Salesforce drove vendors to innovate with the Salesforce digital twin. Each Salesforce devops platform vendor innovated to find different solutions. And most Salesforce devops vendors have experienced success in meeting the demand for devops in critical applications. Industry success has popularized the idea of a separate SaaS system to manage your SaaS deployments.

Due to the innovation which puts Salesforce teams on the same page, Salesforce devops platform makers get credit for being part of the platform engineering movement. And the most innovative Salesforce devops vendors are now taking their expertise and extending it to manage other SaaS platforms.

The Necessity of Industry Marketing for IT Leaders

I know what some of you are thinking: “So, you’re telling me there is no big difference between platform engineering and Salesforce devops? What is all the fuss about? These hype cycles are stupid and distracting!” Well, I think the IT industry still has a long way to go digitizing business activities, be they large or small. And who doesn’t feel stuck in the mud most of the time when dealing with Salesforce? We need new products and service providers, like the Salesforce devops vendors, to adopt platform engineering ideals to help move Salesforce users forward.

Most enterprises should invest more in tools, technologies, and people that manage enterprise app production. The problem is that in a $4.4 trillion global IT industry big organizations are locked into buying patterns are hard to break. This means that organizations stagnate and do not innovate operations with new IT products.

Technology hype cycles help to break through the hum of everyday business activities and get the attention of senior buyers in big companies. You can use these moments of hype attention to get senior executives to consider modernization efforts. Let’s look at two industry marketing theories used to describe the hype cycles so you can navigate them like an industry veteran.

How Hype Cycles Influence Technology Buying

Technology hype cycles control the buying and utilization of new IT products and services. The book Crossing the Chasm by Geoffrey Moore in 1991 and the Gartner Hype Cycle market theory, which debuted in 1995, have originated most of the terms we use today to describe technology cycles. Let’s go over these theories.

Both models depict how new technologies are introduced to the public. Moore mainly talks about the succession of user cohorts who adopt new tech. The cohorts are innovators, early adopters, early majority, late majority, and laggards. “Crossing the chasm” refers to the risky efforts software vendors must do to transition their users from early adopters to the early majority. Not every new technology or company crosses the chasm. Cryptocurrency seem to be the latest victim.

Many of you are also familiar with the Gartner Hype Cycle theory, which has five key phases:

1. Technology Trigger: A new technology is introduced, creating initial interest.
2. Peak of Inflated Expectations: Early publicity generates over-enthusiasm and unrealistic expectations.
3. Trough of Disillusionment: Technologies fail to meet expectations and quickly become unfashionable.
4. Slope of Enlightenment: More instances of how technology can benefit the enterprise start to crystallize and become more widely understood.
5. Plateau of Productivity: Technology becomes increasingly stable and evolves into the final phase of its life cycle, where the benefits are widely demonstrated and accepted.

Both theories are useful for technology buyers. Moore’s “chasm” allows you to compare the current state of a technology with your own persona. If a technology is in the “laggard” stage of adoption, and you haven’t adopted that technology, then Moore’s theory makes you wonder if you want to be a laggard. For some industries, like nuclear energy, maybe being a laggard is desirable. For others, being a laggard calls attention to a deficiency in technology utilization.

The Gartner Hype Cycle is especially useful at evaluating the risks of both adopting and ignoring technologies. Do you have enough faith in a new technology to join others in the “trough of disillusionment,” or should you wait for the “slope of enlightenment?”

Enterprise Application Development Hype Cycles

Let’s look at the history of how technology hype cycles impact the way enterprise applications are developed and operated. By understanding these events you can paint a layered picture of industry developments. This timeline helps to portray platform engineering and Salesforce devops as the natural next investment your company’s application development program. And it explains how platform engineering and Salesforce devops don’t replace but build upon the older ideas.

1990s: Lean and Agile Emergence

• Early 1990s: The term “Lean” is coined by James P. Womack and Daniel T. Jones to describe the efficient manufacturing practices used by Toyota. Lean project management techniques are still popular today, like the Kanban Board and Value Stream Management.
• 1995: Scrum, an iterative and incremental Agile software development framework, is defined by Ken Schwaber and Jeff Sutherland.
• Late 1990s: Extreme Programming (XP), another Agile software development framework, is developed by Kent Beck.

2000s: Formalization of Agile and Emergence of DevOps

• 2001: The Agile Manifesto is published by a group of software developers, formalizing Agile principles.
• 2003: Mary and Tom Poppendieck publish Lean Software Development: An Agile Toolkit, applying Lean principles to the field of software development.
• 2009: The term “DevOps” is coined by Patrick Debois and Andrew Shafer, highlighting the need for greater collaboration between development (Dev) and operations (Ops) teams.

2010s: Expansion of DevOps

• 2010: The first “State of DevOps” report is published, providing a comprehensive overview of devops practices and their benefits.
• 2011: Cloud computing begins widespread adoption, driving the need for devops specialists
• 2015: Kubernetes, a container orchestration platform, is released, becoming a key technology in platform engineering for managing and automating containerized applications.
• 2015: Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal is published. The management techniques used by American special forces in the Iraq War have become a beacon of enlightenment for modern corporate management.
• 2016: The DevOps Handbook, by Gene Kim, Patrick Debois, et al, is published. This book and the authors’ consulting company, IT Revolution, further promote and formalize devops practices.
• 2017: Salesforce introduces its DX program, which includes a metadata CLI. This allows Salesforce developers to effectively use devops techniques in Salesforce release management.
• 2018: This year’s State of Devops Report confirms linkages between devops performance and using scientific methods to track performance measurements known as DORA metrics.
• 2019: Team Topologies by Matthew Skelton and Manuel Pais is published by IT Revolution. It promotes the Teams of Teams concept in product-lead organizations. The topic of platform teams as a company-wide service function is first mentioned.

2020s: Platform Engineering Emerges as Devops Mainstreams

• 2020: Salesforce Devops vendors emerge with prototypes of platform engineering that implement Salesforce digital twin and release management technology.
• 2021: Devops companies Datadog, HashiCorp and GitLab go public with multi-billion-dollar valuations.
• 2023: The first State of Platform Engineering report is published by Puppet, focusing specifically on the practices of platform teams.

Comparing Hype Cycles

Now, let’s reframe some of these major innovations in terms of where they fit on the Gartner Hype Cycle and Moore’s Technology Adoption Lifecycle cohorts in 2023. I made these estimates based on the age of the technology, how much the technology has advanced in recent years, and the adoption rate.

IT Technology	Gartner Hype Cycle	Moore’s Lifecycle Cohort
Lean Software Management	Plateau of Productivity	Late Majority/ Laggards
Agile Product Management	Plateau of Productivity	Late Majority
Cloud Native Devops	Slope of Enlightenment	Early Majority
Salesforce Devops	Trough of Disillusionment/ Slope of Enlightenment	Early Adopters/ Early Majority
Platform Engineering	Peak of Inflated Expectations/ Trough of Disillusionment	Early Adopters

Salesforce Devops in Transition

Let’s examine why Salesforce devops is in a transition from the Trough of Disillusionment to the Slope of Enlightenment.

Salesforce devops is still a relatively new product category, but most products in the market are stable. Also, Salesforce devops platforms have a clear value proposition for companies who are spending $1 million per year or more on their Salesforce licenses. These users get value because their release management process needs a digital twin due to org complexity and the size of the developer teams. Another key reason to buy Salesforce devops is when you are running critical applications in regulated industries.

However, for companies that spend less than $100,000 a year on their Salesforce licenses, there is little to no ability to use devops without additional skills. And users who have tried Salesforce DevOps Center may now be disillusioned because the product falls short of expectations for larger teams. Moreover, other teams are disillusioned because Salesforce devops can be complex to implement.

But I do believe there will be transition to widespread acceptance of Salesforce devops. You don’t have to be an early adopter to find value in many parts of the Salesforce devops stack. But we still have a way to go before everyone who spends from $100,000 to $1 million per year on their Salesforce license finds affordable and usable full stack devops solutions.

Platform Engineering Ideals Needed in Salesforce Devops

I believe that the next step for Salesforce devops platforms is to adopt the ideals of platform engineering. Salesforce devops initially became popular because the services they provided gave Salesforce release managers a better way of doing their job. Devops platforms achieved this by running a digital twin running on another SaaS system, but Salesforce devops involves much more than just release management.

The Salesforce ecosystem should use the platform engineering movement to upgrade our expectations for devops platforms. Here is a bit of a manifesto for the industry where I go through some platform engineering ideals worth emulating. While platform engineering services are usually only affordable for very large enterprises, I hope this guidance works for organizations of any size.

• Platform engineering teams should create prescribed solutions for IT projects. Solutions should measure enterprise value streams linked to the IT projects. Complete solutions include prescriptions for CI/CD pipelines, DORA metrics, observability, application lifecycle management, and value stream management.
• The platform engineering teams must use product management skills to pick and manage organization wide IDPs, including Salesforce devops solutions. This covers project outreach and fostering a user community.
• Platform engineering teams should be adjacent to executive functions in IT and corporate management. The team should bear the weight of compliance and other regulatory responsibilities.
• The best platform engineering teams are made up of experienced software engineers and product managers. They are experts at creating developer experiences (DX) and delivering custom SaaS solutions.

Using Platform Engineering in Salesforce Devops

Platform engineering creates a mandate for how enterprise architects can bring Salesforce under a unified umbrella. Company leaders should treat systems like Gearset, Copado, and Opsera as companywide IDPs that need to service multiple constituencies. IT executives should bring Salesforce alongside Kubernetes, cloud native, and other SaaS platform IDP efforts. Start to integrate company-wide efforts in observability, value stream management, and applications for developers into a rich set of services offered by the platform engineering team. And, with the advent of generative AI, company-wide platform teams are neede more than ever to create gateways and other utilities for deploying AI applications.

Let’s keep expanding Salesforce application development beyond mere release management. If you want to fight for IT alignment and user satisfaction, then you need the advanced monitoring and management techniques embraced by platform engineering.

Also, respect the 11 categories found in the SalesforceDevops.net industry map as a guide to find the vendors you need to fill the gaps. Find a Salesforce devops platform vendor` to be your Salesforce IDP. Or have your platform engineering team makes a new IDP just for your company. A custom platform might be needed to integrate metrics and KPIs across silos. The investment pays off in terms of knowing that you are building the things your enterprise needs.

Salesforce Needs Platform Engineering

The long-term health of the Salesforce ecosystem requires innovation in technical debt and IT alignment. Technical managers worry that their orgs will collapse under the weight of technical debt. They also worry about the efficiency of teams delivering solutions. And CEOs of Salesforce customer companies can’t understand if their Salesforce investment is worth it. Creating solutions to both these problems is essential to ensuring the long-term health of the Salesforce ecosystem.

Salesforce devops has helped manage some Salesforce implementations better. This is especially true with a well-implemented application lifecycle management system. The combination helps to move work along in a faster and better managed manner. And digital twin technology improves technical debt by repairing a previously unmanageable Salesforce org with change intelligence.

However, we need to do more to attain the worthy goal of IT alignment. And a platform engineering initiative could be just what the doctor ordered for some organizations. Use the platform engineering hype cycle to introduce value stream management into your organization. And consider using the platform engineering hype to reframe your goals for servicing your user community.

Certainly, it is the time to use one of those annoying hype cycles for good for once!