Home Cloud & Networking Salesforce DevOps for Architects

Salesforce DevOps for Architects

By Rob Cowell , Lars Malmqvist
books-svg-icon Book
eBook $35.99 $24.99
Print $44.99
Subscription $15.99 $10 p/m for three months
$10 p/m for first 3 months. $15.99 p/m after that. Cancel Anytime!
What do you get with a Packt Subscription?
This book & 7000+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook + Subscription?
Download this book in EPUB and PDF formats, plus a monthly download credit
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook?
Download this book in EPUB and PDF formats
Access this title in our online reader
DRM FREE - Read whenever, wherever and however you want
Online reader with customised display settings for better reading experience
What do you get with video?
Download this video in MP4 format
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with video?
Stream this video
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with Audiobook?
Download a zip folder consisting of audio files (in MP3 Format) along with supplementary PDF
What do you get with Exam Trainer?
Flashcards, Mock exams, Exam Tips, Practice Questions
Access these resources with our interactive certification platform
Mobile compatible-Practice whenever, wherever, however you want
BUY NOW $10 p/m for first 3 months. $15.99 p/m after that. Cancel Anytime!
eBook $35.99 $24.99
Print $44.99
Subscription $15.99 $10 p/m for three months
What do you get with a Packt Subscription?
This book & 7000+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook + Subscription?
Download this book in EPUB and PDF formats, plus a monthly download credit
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook?
Download this book in EPUB and PDF formats
Access this title in our online reader
DRM FREE - Read whenever, wherever and however you want
Online reader with customised display settings for better reading experience
What do you get with video?
Download this video in MP4 format
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with video?
Stream this video
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with Audiobook?
Download a zip folder consisting of audio files (in MP3 Format) along with supplementary PDF
What do you get with Exam Trainer?
Flashcards, Mock exams, Exam Tips, Practice Questions
Access these resources with our interactive certification platform
Mobile compatible-Practice whenever, wherever, however you want
  1. Free Chapter
    Chapter 2: Developing a DevOps Culture
About this book
As the Salesforce Platform evolves into an increasingly complex landscape, architects face a growing demand for advanced solutions. The key to successful Salesforce projects lies in effective DevOps practice, and this book helps you achieve just that by offering strategic and practical insights into Salesforce components. The book starts by cultivating a DevOps mindset, focusing on collaboration, coordination, and communication, and learning how to efficiently demonstrate governance, visibility, and accountability. Building upon this architectural foundation, you’ll delve into tools and techniques to plan your strategy using the capabilities of SFDX. Once you’ve gotten to grips with Salesforce packaging, you'll learn how to build a CI/CD stack with freely available software and configure it for automated change delivery. You’ll then address the operational concerns of a mature DevOps process as you explore topics such as ticket management, backups, change monitoring, and data seeding—essential for maintaining a clean and healthy Salesforce org. Finally, you’ll learn about the ecosystem of third-party solutions, which provide out-of-the-box capabilities to accelerate your Salesforce DevOps journey. By the end of this book, you'll have demystified Salesforce DevOps, empowering you to deliver Salesforce projects with the expertise of a DevOps professional.
Publication date:
January 2024
Publisher
Packt
Pages
260
ISBN
9781837636051

 

Developing a DevOps Culture

The core of a successful DevOps implementation does not lie with the technology and tooling used. Instead, getting the surrounding team culture in place and aligned with a new way of working is the most essential element that underpins DevOps.

In this chapter, we will cover the importance of the offline aspects of DevOps, and how a culture of collaboration and communication is fundamental to DevOps success. We’ll see ways in which to drive adoption and alignment with best practices in your organization. Along the way, we’ll explore the following:

  • Why culture is key to a DevOps transformation and how we can start building it
  • The need to strive for strong communication that drives collaboration
  • Ways to drive adoption of and alignment to a DevOps approach
 

The need for a DevOps culture

The history of software development and its delivery has been long and ever-changing. As the landscape of technology has changed, so has the need for businesses to get that technology into the hands of customers. DevOps represents a drive to deliver according to that need, replacing monolithic software releases, lengthy project cycles, and opaque waterfall methodologies.

When we look at DevOps as a way of delivering change, it’s very easy to get pulled into looking at the software tools first, but this should not be where your DevOps journey begins. It’s equally important to keep in mind that any DevOps transformation should not be prescriptive; instead, it should align with you and your organization’s way of working. This approach is equally important for those that have had prior DevOps experience with other teams or systems – there is no “one size fits all” approach to DevOps, and while experience can be brought to bear on building a DevOps culture with a new team, you should be mindful of tailoring it to fit the team.

However, there are some common elements that work consistently for high-performing DevOps teams, so you should contemplate making these a part of your plan to bring DevOps culture to life. Let’s begin by looking at some of the characteristics of successful DevOps teams and the elements of DevOps culture they have adopted, before diving deeper into how to deliver them.

Strongly defined teams

As the name suggests, DevOps teams are a hybrid of IT Development and IT Operations teams, but the reality is not as straightforward. Successful DevOps teams comprise teams from the full end-to-end spectrum of software delivery, from business analysts gathering the requirements and architects designing solutions to those requirements through to developers implementing those solutions and operations delivering those requirements in your Salesforce environments.

It is within this cross-functional team structure that you need to establish strong buy-in for DevOps. A team that does not understand or appreciate the value of a process is unlikely to adopt DevOps – and it only takes a few shortcuts or out-of-process releases to damage the good work the rest of your DevOps team has done. It is vital that the entire team aligns and engages with DevOps as a way of working, to make the initiative successful.

A team that aligns with DevOps practices has shared responsibility for the entire application life cycle, from planning to deployment and maintenance, thus reducing standoffs and finger-pointing over who is responsible for fixing bugs or test failures. Additionally, DevOps encourages product teams to be more involved in the development process, ensuring that their input and expertise are considered throughout the application life cycle.

As architects, we need to convey the value that DevOps brings since for most teams – whether technical or on the business side – this tends to be the key factor that gets people on board. By showing how DevOps benefits everyone along the development journey we have outlined, we stand a better chance of getting teams on board with DevOps, compared to a hard enforcement of processes.

Companies that have yet to adopt a DevOps culture for software delivery may have lost trust in their delivery teams, bringing in heavyweight processes in an attempt to prevent the risk of future failures. Part of adopting a DevOps culture is restoring that trust by providing tools and processes that empower teams to succeed and allow any failures to be small, rather than bogging everything down by trying to avoid failure entirely.

In general, one of the benefits of DevOps and Agile is to be able to take small steps safely. DevOps and Agile methodologies advocate for small, incremental releases rather than large, monolithic deployments. This approach allows teams to identify and fix issues more quickly, reducing the risk of catastrophic failures. It also enables them to respond to changing requirements or market conditions more effectively. As a result, trust in the team’s ability to deliver accurate results and adapt to change grows.

Closely working together

Hand in hand with strong teams is the need to collaborate and communicate with each other. This may seem an obvious need in all working teams, not just DevOps, but the principles of clarity, visibility, and cooperation really come to the fore with DevOps and are essential for its smooth running.

To break down the siloed approach to software delivery and work toward a common goal, the entire team needs to be aware of how projects are being delivered. Techniques such as Agile and tools such as Jira or Asana will certainly help with this, but that’s only part of the picture of collaboration, as we’ll explore shortly.

Constant evolution

No matter how mature a DevOps team may be, the highest-performing teams are always open to change and improvement. Through a continuous cycle of measurement, enhancement, and re-measuring, these teams are able to pinpoint areas where performance and accuracy gains can be made and then address them. The most common metrics they tend to focus on are based on the DORA metrics, as follows:

  • Deployment frequency: How often a team releases to production
  • Change lead time: How long it takes for a specific feature to reach production
  • Change failure rate: The proportion of deployments that either fail to deploy or cause errors in production
  • Mean time to recovery: How long it takes to recover from a production error or another issue

In the context of Salesforce, measuring against these metrics can be a bit different since it’s a cloud-based platform with specific features and limitations. Metrics such as deployment frequency, change lead time, and mean time to recovery can be determined easily enough, especially if you have a ticketing system such as Jira or Asana for managing new work.

The change failure rate can be a little trickier, though, since it involves tracking unsuccessful deployments and the number of incidents or defects related to those deployments. There are a few ways you could approach this – we’ll cover Salesforce-specific DevOps solutions and platforms in later chapters, but as an example using on-platform features, you could try the following:

  • Use Salesforce’s deployment history, available on the Deployment Status page, to track the success and failure rates of deployments. Identify failed deployments and the specific components that caused the failure.
  • Keep a record of all production incidents, including those caused by recent deployments. You can use the Salesforce Case object to log and track incidents.
  • For each failed deployment or production incident, analyze the root cause and determine whether it was due to a recent change. You can use the Salesforce Developer Console, debug logs, and test results to pinpoint the root cause of the issues.
  • Divide the number of failed changes (deployments causing incidents or defects) by the total number of changes made during a specific period. Multiply the result by 100 to get the change failure rate as a percentage.

The origin of the DORA metrics

The DORA metrics came from a group called DevOps Research and Assessment, which was founded in 2015 by Nicole Forsgren, Gene Kim, and Jez Humble (and later acquired by Google in 2018), to better understand what factors led to high-performing DevOps teams. Since that initial research, these four metrics have become an industry-standard set of measurements of DevOps success.

Now that we’ve determined the need for, and elements of, a strong DevOps culture, let us look in more detail at some techniques for creating this culture.

 

Collaboration and communication

In an ideal DevOps team, the whole team works in the same way and toward the same goal – there should be a shared responsibility for the successful delivery of changes. Fundamental to this collaborative approach is strong communication, and this can take many forms, from the more formal approach needed for governance of the overall change management process down to the daily interactions that form part of your usual workflow.

Communication should be clear, informative, and present at every step of the delivery life cycle. For example, when using version control, teams should endeavor to always provide meaningful commit messages and comments on peer reviews. These aid teams to carry out the next steps of any change delivery process with context, not just the specifics of the change itself. There is often a balance needed between providing sufficiently detailed information and relevant information, and you should iterate on this level of detail to find the sweet spot that works for you and your team.

While this book is not an exploration of Agile principles, there does seem to be a strong correlation between successful DevOps teams and Agile practitioners since both disciplines foster these same principles of regular, clear, and concise communication to drive projects forward. Such techniques encompass all team members involved in delivering change so that everyone is informed and aware of the process and progress of work.

Equally, tools will help bring visibility and clarity to daily work. Software for managing features as they go through your DevOps process, such as Jira, Asana, Azure DevOps, and so on, can bring this overview to your processes when used properly and they integrate in some way into most DevOps tools to complete the picture. Many teams have started to eschew email as an internal communication medium, instead favoring the immediacy of messaging platforms such as Slack or Teams as a further means of breaking down siloes and removing barriers between cross-functional teams.

The necessity of adapting to remote work has led to an increased reliance on digital communication tools and has changed the dynamics of team interaction in a number of ways. With teams distributed across various locations and time zones, it is essential to have tools that enable real-time collaboration and offer instant communication, file-sharing, and integration with other tools. In remote work, it is not always possible to gather everyone at the same time for discussions. Asynchronous communication tools, such as project management platforms, shared documents, and threaded discussions on messaging apps, allow team members to contribute at their convenience and keep everyone informed of progress.

With every adaptation that needs to be made with the shift to remote working, balance is key. With the shift to digital communication, remote workers may face an influx of messages and notifications. Messaging platforms have adapted by offering features such as channels, threads, and snooze options, allowing team members to prioritize and manage their communications effectively. However, it is equally important to maintain a sense of connection and engagement between team members. Messaging platforms facilitate informal interactions, such as virtual water-cooler conversations, quick check-ins, and social activities, helping teams stay connected and fostering a positive team culture.

Remote work has made it necessary for teams to communicate effectively without the context provided by face-to-face interactions. Modern methods of communication for distributed teams encourage team members to be more concise and clear in their communications, as well as more intentional with their responses.

Finally, as remote work relies on digital communication tools, ensuring data security and compliance with industry regulations becomes critical. Technological solutions have responded by offering end-to-end encryption, data storage options, and compliance features tailored to different industries.

 

Adoption and alignment

As we’ve seen, the adoption of a DevOps culture should come before the adoption of DevOps technology. Within each, however, the optimal approach is always to start slowly – it’s often said that DevOps is a journey, not a destination, and to that end, we should begin with some planning.

Questions to start with

The best place to start any kind of journey is to look at where we would like to go, with a few questions:

  • What does the intended process look like?

Knowing your target scenario helps focus your efforts and prevents unnecessary disruption to your business. For example, is the ultimate goal to be able to deliver business requirements faster and incrementally, or do you want to work to a more scheduled, sprint-based approach, but have better visibility and control over the elements contained within that sprint? Having the aims well defined up front helps focus teams on delivering them.

  • What is the intended audience for the new process?

A new DevOps process will impact more than just development and operations teams. If you truly want to adopt an end-to-end Salesforce DevOps approach, you will need to align not just the technical teams but also those involved in the gathering and assigning of work tasks, those responsible for project management, release management, overall architecture, business approval, and more. We’ll look at some of these governance aspects shortly.

  • What do we need to change in our current approach?

While it’s not unheard of, it’s rare that an existing process needs to be completely replaced. Take stock of your current delivery model and make note of what works and what doesn’t work. Where are the bottlenecks that are slowing you down? How many attempts does it take to get something delivered to production? If we look again at the DORA metrics discussed earlier, where are we starting from? Getting a baseline set of metrics before you start a DevOps transformation is a solid way of measuring progress and improvement – and ultimately, your return on investment – as you begin to adopt Salesforce DevOps. Furthermore, having the ability to demonstrate the problem (and later, the improvements made) to executive stakeholders is invaluable in getting their buy-in for a DevOps transformation project.

With these questions front of mind, it becomes easier to start identifying the potential gains from adopting Salesforce DevOps, which, in turn, can help drive team alignment with the change. This step is essential – everybody involved needs to become a stakeholder in the move to DevOps and the best way to achieve this is to look at things from two viewpoints:

  • What are the benefits that DevOps will bring?

After identifying the teams that will be directly impacted by the adoption of DevOps as a means of delivery, work on conveying the benefits to them. Visibility of changes, more manageable and smaller units of work, faster delivery, robust testing, reasonably predictable release cycles – all of these things matter to Salesforce teams and the overriding principle of making their life easier is a strong driver for getting people on board with the change.

  • What are the risks of not adopting DevOps?

Equally, it’s valuable to assess the risks of standing still and changing nothing. If you don’t adopt a faster and more flexible delivery model, you risk being outmaneuvered by more agile competitors. If you don’t implement a robust backup and recovery strategy, you risk losing your valuable business data or that of your customers. If you stick to more traditional delivery models, which can be lengthy and arduous, you risk dissatisfaction and burnout in your teams, which can lead to them moving elsewhere.

Making life easy for your teams

If your Salesforce team is new to DevOps concepts, techniques, or even terminology, then it can seem a daunting prospect for them to move to a new delivery model. However, like all large projects, the optimum approach is often to start slowly with small aspects of the process, then expand and iterate upon it.

For example, because the concept of source control has historically been a code-based domain for developers, many Salesforce Admins will be unfamiliar with this approach. This area alone is a good place to start – even if you don’t necessarily dive straight into applying source control, the mere act of aligning Admins and Developers with a common way of working contributes to the communication and collaboration components of building a DevOps culture.

Having Admins and Developers work more closely together in this way also lends itself to another great set of techniques for fostering your DevOps culture. High-performing Salesforce DevOps teams make frequent use of mentoring and coaching to not only improve the overall skill set and confidence of the team but also as an aid to collaborative working and breaking down siloes to form a multi-discipline DevOps team.

Of course, it’s not all about the process, and you should also ensure that your teams have the necessary tools to aid a smoother DevOps journey. As an architect, you should be ever-mindful of the Salesforce DevOps landscape and assess the components, such as version control providers, new tools or updates to existing ones, or even complete Salesforce DevOps platforms – some of which we’ll look at in later chapters.

Governance and risk management

A DevOps culture should be ever-mindful of the need to manage and mitigate business risks, and a strong governance framework should be in place to provide this. It’s important to appreciate that while DevOps unlocks the potential for rapid delivery of change, it is not a free-for-all without controls.

The governance of our DevOps process should be aligned with the governance in which your business, or that of your customers, operates. Without the correct processes in place, you risk losing the value of the alignment and adoption you fostered in starting your DevOps journey. You risk falling back to the use of lengthy, monolithic releases with dissatisfied customers waiting on changes that are buried deep in the backlog. You also potentially risk low-quality changes being delivered, which, in a worst-case scenario, can damage your systems, your data, and your reputation.

Regulated industries such as financial services and healthcare face unique challenges when it comes to software development and deployment. These industries are subject to a wide range of regulations, standards, and compliance requirements that govern how software must be developed, tested, and deployed. These regulations are in place to protect sensitive data, ensure data privacy, and prevent fraud and other criminal activities.

In financial services, regulations such as the Sarbanes-Oxley Act, Payment Card Industry Data Security Standards (PCI DSS), and Anti-Money Laundering (AML) regulations require financial institutions to implement strong controls around software development, testing, and deployment. Similarly, in healthcare, regulations such as the Health Insurance Portability and Accountability Act (HIPAA) and the General Data Protection Regulation (GDPR) require healthcare organizations to protect patient data and ensure data privacy. DevOps can help organizations in these types of industries comply with these regulations by providing a structured process for software development, which includes automated testing, security scanning, and continuous monitoring. This can help ensure that software is developed with security and privacy in mind and that any potential security vulnerabilities are identified and addressed before the software is deployed.

A good governance framework addresses these issues by implementing the necessary checks and balances throughout the entire life cycle. From prioritizing work and deciding which initiatives are driven forward through to the technical design and implantation considerations, governance allows stakeholders on all sides to input into success.

At the heart of this approach lies the Center of Excellence, which oversees this journey. It informs and guides the business goals as they apply to Salesforce, the approach used for delivery, and the technologies used. It is also responsible for communication with both stakeholders and end users across the organization, for identifying and managing business risk of projects, and for ensuring initiatives deliver value.

As such, a CoE often contains, or works alongside, distinct groups with specific responsibilities. A Change Management group, for example, will be the approving body for changes going into Salesforce and will make sure that the change is of suitable quality and has been thoroughly tested before it is allowed to be released to production. This would typically be through the definition of the required processes and behaviors it expects to see carried out to ensure quality deliverables, rather than it carrying out the testing itself, which would continue to be the responsibility of the technical teams.

A note of caution should be taken with Change Management groups, however. In the book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, and Gene Kim, the authors emphasize the importance of fast feedback loops, continuous experimentation, and a culture of learning and improvement – factors that may suggest that traditional change management practices may not always align with the needs of high-performing DevOps teams.

A Steering Committee, on the other hand, is a business-led group that ensures that changes continue to align with business strategy, vision, and values. Across all these areas, there should be an executive sponsor that is empowered and available to make decisions and unlock business bottlenecks.

Making a case for a CoE to leadership

Architects looking to present a case for establishing a CoE to the leadership of their organization or customers should largely draw upon the same techniques for presenting any proposal to stakeholders. However, some specific elements should be considered a fundamental part of that proposal. Here are some typical areas to focus on:

Topic

Detail

Define purpose and goals

Articulate the objectives of the CoE, such as driving continuous improvement, sharing best practices, fostering collaboration, and accelerating DevOps adoption across the organization.

Build a business case

Create a compelling business case that demonstrates the benefits of a CoE, including potential cost savings, improved operational efficiency, faster time to market, and enhanced customer satisfaction. Showcase industry examples and relevant success stories.

Identify key stakeholders

Identify and engage key stakeholders, such as senior management, development, and operations teams. Involve them in the decision-making process and the subsequent establishment of the CoE.

Propose the CoE structure

Propose a structure for the CoE, including roles, responsibilities, and reporting lines. Estimate the budget and resources required to set up and maintain the CoE. Positions may include DevOps coaches, product owners, and continuous improvement specialists.

Develop a roadmap

Outline a roadmap for implementing the CoE, including milestones, timelines, and key performance indicators (KPIs). Provide a clear plan for leadership to follow and monitor progress.

Plan for change management

Recognize that implementing a CoE may involve significant cultural and organizational changes. Present a change management strategy that addresses potential resistance, communication, and training needs.

Foster collaboration

Emphasize the importance of cross-functional collaboration and knowledge sharing between teams. Propose tools and platforms that facilitate communication and collaboration, such as chat platforms, wikis, or video conferencing systems.

Pilot and iterate

Propose starting with a pilot program involving one or more teams to test and refine the CoE approach. Enable the organization to learn from the pilot, adjust, and gradually scale up the CoE as part of the wider DevOps adoption.

Regularly report progress

Ensure that the progress of the CoE is regularly reported to leadership, including successes, challenges, and learnings. Maintain support and commitment from senior management through transparency.

Demonstrate ongoing value

Continually highlight the positive impact of the CoE on the organization, including quantifiable improvements in efficiency, quality, and innovation. Maintain and grow support for the CoE and its role in the broader DevOps adoption.

Table 2.1 – Elements to consider in a proposal

Overcoming resistance and hesitation

There are several common reasons why people might initially resist the idea of implementing DevOps in their organization, believing that “it’s nice, but it can’t be done here.” Let’s address some of these reasons and provide counterarguments to help dispel these concerns:

Area

Resistance

Counterargument

Organizational structure and culture

The existing organizational structure and culture promote siloed teams and discourage collaboration

DevOps is an opportunity to break down silos and foster collaboration. Start with small changes, such as creating cross-functional teams, and gradually scale up DevOps initiatives as the organization adapts to the new approach.

Lack of skills and expertise

Team members lack the skills and knowledge to implement DevOps practices and tools

Invest in training and upskilling team members and consider hiring or partnering with experts to help guide your DevOps transformation. Continuous learning is a core principle of DevOps, so developing these skills should be viewed as an ongoing process.

Limited resources and budget

There is no budget or resources to invest in new tools, technologies, and training for a DevOps transformation

DevOps can help increase efficiency and reduce costs in the long run. Start small by leveraging existing tools and resources, and gradually expand your DevOps capabilities as you demonstrate ROI and gain organizational buy-in.

Fear of failure and disruption

Changing existing processes could lead to disruptions and negatively impact current projects

DevOps is about continuous improvement and learning from failure. Begin with small, low-risk projects to minimize potential disruptions and use the lessons learned to refine your approach before tackling larger initiatives.

Legacy systems and technical debt

Existing infrastructure and legacy systems make it difficult to adopt modern DevOps practices and tools

DevOps can help address technical debt and modernize legacy systems by promoting incremental improvements and fostering a culture of innovation. Prioritize the most critical aspects of your infrastructure and develop a roadmap for introducing DevOps practices.

Lack of management support

Management does not see the value in DevOps or is unwilling to invest in the necessary changes

Build a strong business case for DevOps by highlighting its potential benefits. Share success stories and best practices from other organizations and consider running a pilot project to demonstrate the value of DevOps firsthand.

Regulatory and compliance concerns

Adopting DevOps practices may conflict with compliance requirements in heavily regulated industries

DevOps can improve compliance by automating processes, ensuring consistency, and providing better visibility. Collaborate with your compliance and security teams to ensure that your DevOps practices align with industry regulations and organizational policies.

Table 2.2 – Reasons and counterarguments to dispel concerns

By addressing these common concerns and demonstrating the potential benefits of adopting DevOps, you can help overcome resistance and encourage stakeholders to embrace this transformative approach.

 

Summary

There is an often (mis)quoted saying, “Culture eats strategy for breakfast,” and seldom has this been more pertinent than in the world of DevOps. No matter how well crafted your strategy for adopting DevOps may be, it will not succeed if your team is not on board with the culture and mindset required. By promoting the advantages of a DevOps process and ensuring that the entire team works together to this model, with strong communication along the way, you have laid the foundation for a successful Salesforce DevOps transformation and can now build upon it with the tools and techniques we’ll explore in the next part of this book. In the next two chapters, we’ll first look at the essential role that testing plays across your DevOps life cycle, before looking at an example workflow that takes these elements into account with a typical SFDX and Git workflow.

Culture eats strategy for breakfast – or does it?

The quote is attributed to renowned management expert, Peter Drucker. While this version remains in popular use and demonstrates our point here, Drucker’s original quote was “Culture – no matter how defined – is singularly persistent.”

About the Authors
  • Rob Cowell

    Rob Cowell is a Salesforce DevOps Advocate at a leading platform provider in this space. He uses his wealth of experience as a Salesforce Dev and Architect to guide and advise on best practice for Salesforce DevOps. He has gained a unique insight into Salesforce trends and challenges over the years, and uses this to help organizations of all shapes and sizes to optimize their Salesforce processes. Alongside his day job, he is an active participant of the Salesforce community, providing support and sharing experiences to help others thrive.

    Browse publications by this author
  • Lars Malmqvist

    Lars Malmqvist is a 32x certified Salesforce CTA and has spent the past 15 years in the Salesforce ecosystem building advanced solutions on the platform. Currently, he works as a partner in the management consultancy, Implement Consulting Group, focusing on supporting large Nordic Salesforce clients in their transformation journeys. He has published two books, Architecting AI Solutions on Salesforce and Salesforce Anti-Patterns, both with Packt publishing.

    Browse publications by this author
Salesforce DevOps for Architects
Unlock this book and the full library FREE for 7 days
Start now