Salesforce began as an effort to simplify the enormous complexity of setting up an application such as CRM. One of its overwhelming benefits has been the ease of creating and updating functionality using click-based tools. Even Salesforce’s programming languages provide rich prebuilt frameworks for interacting with data and the user interface.
Through skillful sales and marketing, ambitious product engineering, and the audacious success of building a community of 6 million click-based developers, Salesforce has grown into a vast platform. Over 150,000 businesses have customized the platform to meet their unique needs, in many cases creating tens of thousands of components, both code and config. Salesforce now supports an entire world of technologies and customizations, from blockchain, to AI, to social media, to user communities, and beyond, most of which can be configured by citizen developers.
The growth of these capabilities has outpaced the sophistication of the methods most Salesforce teams use to manage the development lifecycle. But fortunately the challenge of taming the dev lifecycle is not unique to Salesforce, and there has been an explosion of innovation and experience cultivated on this topic within the broader IT world over the last decades. The DevOps movement has become a gathering place for teams across all technologies to exchange ideas and improve tooling in support of those efforts. And so the Salesforce community is increasingly looking to the DevOps community to understand how to effectively manage such complex configuration at scale.
Throughout this book I’ve used the word “should” a lot. It’s natural for most of us, certainly me, to hear the word “should” and feel inadequate, like we’re not doing enough. This book has attempted to introduce opportunities to improve our processes, and I’ve shared encouragement, sometimes strongly, about practices we should adopt or abandon (see, there’s that word again). But fundamentally, what we “should” do is to make life easier and better for ourselves, our coworkers, and the people around us who depend on our work.
We “should” spend more time with our families, and not have to work weekends and evenings doing deployments, or cleaning up in their aftermath. We “should” be able to make small improvements quickly without making other people wait. We “should” be able to exercise our creativity at work instead of being stuck doing monotonous tasks. And we “should” be solving problems once, in an automated way, so that we or our coworkers don’t have to face them again.
My motivation in writing this has been to share what I’ve learned in the process of trying to make work more fun for myself, and more effective for the teams I’ve worked with. Take every suggestion in this book as optional, and as something you can experiment with, or not, depending on the needs of your team.
My other motivation in writing this has been to introduce Salesforce workers to the world of DevOps, which has become an active and brilliant community filled with life wisdom and technical excellence. Just as Salesforce solves many problems that bedevil people who are struggling to set up and manage their own infrastructure, these DevOps processes can solve many of the problems that Salesforce teams have historically struggled with. My hope is that this book contributes to that conversation and helps build another bridge between these communities of practice.
When we’re customizing Salesforce to the needs of our organizations, our goal is to deliver innovation and value. In working together—dev and ops, developer and admin, business and IT, customer and company—we are building trust in each other and increasingly building trusted processes. The goal of innovation is to create value; and the goal of building trust is to reduce risk. Doing these two together, at high velocity and large scale, is the essence of DevOps.
At HP we never set out to do Agile. Our focus was simply on improving productivity. … We set off on a multiyear journey to transform the way we did development with the business objective of freeing up capacity for innovation and ensuring that, after the transformation, firmware would not be the bottleneck for shipping new products. This clear objective really helped guide our journey and prioritize the work along the way. ...
We see many companies that embark on a “do Agile” journey. They plan a big investment. They go to conferences to benchmark how well they are “doing DevOps or Agile.” They see and feel improvements, but the management teams struggle to show bottom-line business results to the CFO. Not having clear business objectives is a key source of the problem. If they started out by focusing on the business and just using DevOps ideas or implementing some Agile methods that would provide the biggest improvements, they would find it much easier to show bottom-line financial results. This worked at HP. When we started, firmware had been the bottleneck in the business for a couple of decades and we had no capacity for innovation. At the end of a three-plus -year journey, … We had dramatically reduced costs from $100M to $55M per year and increased our capacity for innovation by eight times.
To be clear, achieving these results was a huge team effort. … Without the collaboration with our partners throughout the business we could not have achieved these results. Having a set of high-level business objectives that the entire organization is focused on is the only way to get this type of cross-organizational cooperation and partnership. These types of results will not happen when you “do Agile.” It takes a laser-like focus on business objectives, a process for identifying inefficiencies in the current process, and implementing an ongoing, continuous improvement process. 1
This story of the HP LaserJet Firmware division has been celebrated extensively in the DevOps community, in part because it shows how agility and radical transformation is possible even with a decades-old technology that’s rooted in hardware. With a complex topic like DevOps, it’s easy to get entranced with the technological changes involved. It’s equally easy for business people to feel that things like continuous delivery are irrelevant to their mission. But you can and should drive such process improvements to gain business benefit. When the business case for DevOps is clear to everyone involved, there’s never a problem sustaining long-term support for these initiatives.
I hope this book has provided guidance to help you begin or continue your Salesforce DevOps journey. May your process of building trust while delivering innovation become as simple and fun as the act of creating on Salesforce.