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.