The Importance of Leadership in Moving to a DevOps Culture

Why DevOps?

DevOps is a set of practices that improve the efficiency and effectiveness of IT operations. Utilizing many aspects of agile methodology, DevOps aims to shorten the systems development life cycle and provide continuous improvement. As you consider incorporating DevOps into your operations, understand the effect DevOps has on processes and culture. Successful implementation is about finding the right balance of attention on people, processes, and technology to achieve improvement.

The ultimate goal is continuous improvement through processes and tools. No amount of tooling, automation, or fancy buzz words can cause any greater effect on an organization than transforming their culture, and there’s no other way to do that than to focus on the change.

Understanding What You Are Trying to Accomplish with DevOps

Ask yourself what you are trying to achieve. It may seem obvious, but you may get on the wrong track without thinking about what you want your development and operations teams to achieve.

Often, when clients approach 2nd Watch wanting to incorporate DevOps, they are really asking for automation tools and nothing else. While automation has certain benefits, DevOps goes beyond the benefits of technology to improve processes, help manage change more effectively, and improve organizational culture. Change is difficult. However, implementing a cultural shift is particularly challenging. Often overlooked, cultural change is the greatest pain 2nd Watch consultants encounter when working with companies trying to make substantial organizational changes. Even implementing things as simple as sharing responsibility, configuration management, or version control can cause turmoil!

From IT Management to Leadership

There is a distinction between what it means to be a manager versus being a leader. And, in all industries, being a manager does not necessitate being a good leader.

It’s helpful to consider the progression of those in technical roles to management. Developers and operations personnel are typically promoted to managers because they are competent in their technical position—they excel at their current software development process, configuring a host or operating a Kubernetes cluster. However, as a manager, they’re also tasked with directing staff, which may put them outside of their comfort zone. They are also responsible for pay, time and attendance, morale, and hiring and firing. They likely were not promoted for their people skills but their technical competencies.

Many enterprise organizations make the mistake of believing employees who have outstanding technical skills will naturally excel at people management once they get that promotion. Unfortunately, this mistake breeds many managers who fall short of potential, often negatively affecting corporate culture.

Leading the Change

It’s imperative to understand the critical role leadership plays in navigating the amount of change that will likely occur and in changing the organization’s culture.

Whether you’re a manager or leader matters a lot when you answer the question, “What do I really want out of DevOps?” with, “I want to be able to handle change. Lots and lots of change.”

Better responses would include:

  • “I want our organization to be more agile.”
  • “I want to be able to react faster to the changing market.”
  • “I want to become a learning organization.”
  • “I want to embrace a DevOps culture for continuous improvement.”

The underlying current of these answers is change.

Unfortunately, when bungled management occurs, it’s the people below that pay the price. Those implementing the changes tend to take the brunt of the worst of the change pain. Not only does this cause lower morale, but it can cause a mutiny of sorts. Apathy can affect quality, causing outages. The best employees may jump ship for greener pastures. Managers may give up on culture change entirely and go back to the old ways.

However, there is light at the end of the tunnel. With a bit of effort and determination, you can learn to lead change just as you learned technical skills.

Go to well-known sources on management improvement and change management. Leading Change by John P. Kotter[1]  details the successful implementation of change into an organization. Kotter discusses eight steps necessary to help improve your chances of being successful in changing an organization’s culture:

  1. Establishing a sense of urgency
  2. Creating the guiding coalition
  3. Developing a vision and strategy
  4. Communicating the change vision
  5. Empowering broad-based action
  6. Generating short term wins
  7. Consolidating gains and producing more change
  8. Anchoring new approaches in the culture

It’s all about people. Leaders want to empower their teams to make intelligent, well-informed decisions that align with their organization’s goals. Fear of making mistakes should not impede change.

Mistakes happen. Instead of managers locking their teams down and passing workflows through change boards, leaders can embrace the DevOps movement and foster a culture where their high-performing DevOps team can make mistakes and quickly remedy and learn from them.

Each step codifies what most organizations are missing when they start a transformation: focusing on the change and moving from a manager to a leader.

The 5 Levels of Leadership

Learning the skills necessary to become a great leader is not often discussed when talking about leadership or management positions. We are accustomed to many layers of management and managers sticking to the status quo in the IT industry. But change is necessary, and the best place to start is with ourselves.

The 5 Levels of Leadership by John C. Maxwell[1] is another excellent source of information for self-improvement on your leadership journey:

  • Level 1 – Position: People follow you only because they believe they have to.
  • Level 2 – Permission: People follow you because they want to.
  • Level 3 – Production: People follow you because of what you have done for the organization.
  • Level 4 – People Development: People follow you because of what you have done for them.
  • Level 5 – Pinnacle: People follow because of who you are and what you represent.

Leadership easily fits into these levels, and determining your position on the ladder can help. Not only are these levels applicable to individuals but, since an organization’s culture can revolve around how good or bad their leadership is, this ends up being a mirror into the problems the organization faces altogether.

Conclusion

When transforming to a DevOps culture, it’s essential to understand ways to become a better leader. In turn, making improvements as a leader will help foster a healthy environment in which change can occur. And there’s no better catalyst to becoming a great leader than being able to focus on the change.

2nd Watch collaborates with many different companies just beginning their workflow modernization journey. Contact us to discuss how we can help your organization further adopt a DevOps culture.

-Craig Monson

3 Advantages to Embracing the DevOps Movement (Plus Bonus Pipeline Info!)

What is DevOps?

As a result of the increase in cloud adoption across all industries, understanding practices and tools that help organizations’ software run efficiently is essential to how their cloud environment and organization operate. However, many companies do not have the knowledge or expertise needed for success. In fact, Puppet’s 2021 State of DevOps Report found that while 2 in 3 respondents report using the public cloud, only 1 in 4 use the cloud to its full potential.

Enter the DevOps movement

The concept of DevOps combines development and operations to encourage collaboration, embrace automation, and speed up the deployment process. Historically, development and operations teams worked independently, leading to inefficiencies and inconsistencies in objectives and department leadership. DevOps is the movement to eliminate these roadblocks and bring the two communities together to transform how their software operates.

According to a 2020 Atlassian survey, 99% of developers & IT decision-makers say DevOps has positively impacted their organization. Benefits include helping advance their career, and better and faster deliverables. Given the favorable outcome for these developers and IT decision-makers, adopting DevOps tools and practices is a no-brainer. But here are three more advantages to embracing the DevOps movement:

1. Speed

Practices like microservices and continuous delivery allow your business operations to move faster, as your operations and development teams can innovate for customers more quickly, adapt to changing markets, and efficiently drive business results. Additionally, continuous integration and continuous delivery (CI/CD) automate the software release process for fast and continuous software delivery. A quick release process will allow you to release new features, fix bugs, respond to your customers’ needs, and ultimately, provide your organization with a competitive advantage.

2. Security

While DevOps focuses on speed and agile software development, security is still of high priority in a DevOps environment. Tools such as automated compliance policies, fine-grained controls, and configuration management techniques will help you reap the speed and efficiencies provided by DevOps while maintaining control and compliance of your environment.

3. Improved Collaboration

DevOps is more than just technical practices and tools. A complete DevOps transformation involves adopting cultural values and organizational practices that increase collaboration and improve company culture. The DevOps cultural model emphasizes values like ownership and accountability, which work together to improve company culture. As development and operations teams work closely together, their collaboration reduces inefficiencies in their workflows. Additionally, collaboration entails succinctly communicating roles, plans, and goals. The State of DevOps Report also found that clarity of purpose, mission and operating context seem to be strongly associated with highly evolved organizations.

In short, teams who adopt DevOps practices can improve and streamline their deployment pipeline.

What is a DevOps Pipeline?

The term “DevOps Pipeline” is used to describe the set of automated processes and tools that allow developer and operations teams to implement, test, and deploy code to a production environment in a structured and organized manner.

A DevOps pipeline may look different or vary from company to company, but there are typically eight phases: plan, code, build, test, release, deploy, operate, and monitor. When developing a new application, a DevOps pipeline ensures that the code runs smoothly. Once written, various tests are run on the code to flush out potential bugs, mistakes, or any other possible errors. After building the code and running the tests for proper performance, the code is ready for deployment to external users.

A significant characteristic of a DevOps pipeline is it is continuous, meaning each function occurs on an ongoing basis. The most vital one, which was mentioned earlier, is CI/CD. CI, or continuous integration, is the practice of automatically and continuously building and testing any changes submitted to an application. CD, or continuous delivery, extends CI by using automation to release software frequently and predictably with the click of a button. CD allows developers to perform a more comprehensive assessment of updates to confirm there are no issues.

Other “continuous” DevOps practices include:

  • Continuous deployment: This practice goes beyond continuous delivery (CD). It is an entirely automated process that requires no human intervention, eliminating the need for a “release day.”
  • Continuous feedback: Applying input from customers and stakeholders, and systematic testing and monitoring code in the pipeline, allows developers to implement changes faster, leading to greater customer satisfaction.
  • Continuous testing: A fundamental enabler of continuous feedback. Performing automated tests on the code throughout the pipeline leads to faster releases and a higher quality product.
  • Continuous monitoring: Another component of continuous feedback. Use this practice to continuously assess the health and performance of your applications and identify any issues.
  • Continuous operations: Use this practice to minimize or eliminate downtime for your end users through efficiently managing hardware and software changes.

 Embrace the DevOps Culture

We understand that change is not always easy. However, through our Application Modernization & DevOps Transformation process, 2nd Watch can help you embrace and achieve a DevOps culture.

From a comprehensive assessment that measures your current software development and operational maturity to developing a strategy for where and how to apply different DevOps approaches to ongoing management and support, we will be with you every step of the way. Following is what a typical DevOps transformation engagement with us looks like:

Phase 0: Basic DevOps Review

  • DevOps and assessment overview delivered by our Solutions Architects

Phase 1: Assessment & Strategy

  • Initial 2-4 week engagement to measure your current software development and operational maturity
  • Develop a strategy for where and how to apply DevOps approaches

Phase 2: Implementation

Phase 3: Onboarding to Managed Services

  • 1-2 week onboarding to 2nd Watch Managed DevOps service and integration of your operations team and tools with ours

Phase 4: Managed DevOps

  • Ongoing managed service, including monitoring, security, backups, and patching
  • Ongoing guidance and coaching to help you continuously improve and increase the use of tooling within your DevOps teams

Getting Started with DevOps

While companies may understand the business benefits derived from DevOps, 2nd Watch has the knowledge and expertise to help accelerate their digital transformation journey. 2nd Watch is a Docker Authorized Consulting Partner and has earned the AWS DevOps Competency for technical proficiency, leadership, and proven success in helping customers adopt the latest DevOps principles and technologies. Contact us today to get started.

-Tessa Foley, Marketing

 

Cloud Automation for I.T. Governance, Risk, and Compliance (GRC) in Healthcare

It has been said that the “hero of a successful digital transformation is GRC.” The ISACA website states, “to successfully manage the risk in digital transformation you need a modern approach to governance, risk and regulatory compliance.” For GRC program development, it is important to understand the health information technology resources and tools available to enable long term success.

What is GRC and why it important?

According to the HIPAA Journal, the average cost of a healthcare data breach is now $9.42 million. In the first half of 2021, 351 significant data breaches were reported, affecting nearly 28 million individuals. The needs have never been more acute among healthcare providers, insurers, biotechnology and health research companies for effective information security and controls. Protecting sensitive data and establishing a firm security posture is essential.  Improving health care and reducing cost relies on structured approaches and thoughtful implementation of available technologies to help govern data and mitigate risk across the enterprise.

Effective and efficient management of governance, risk, and compliance, or GRC, is fast becoming a business priority across industries. Leaders at hospitals and health systems of all sizes are looking for ways to build operating strategies that harmonize and enhance efforts for GRC. Essential to that mission are effective data governance, risk management, regulatory compliance, business continuity management, project governance, and security. But rather than stand-alone or siloed security or compliance efforts, a cohesive program coupled with GRC solutions allow for organizational leaders to address the multitude of challenges more effectively and efficiently.

What are the goals for I.T. GRC?

For GRC efforts, leaders are looking to:

  • Safeguard Protected Healthcare Data
  • Meet and Maintain Compliance to Evolving Regulatory Mandates and Standards
  • Identify, Mitigate and Prevent Risk
  • Reduce operational friction
  • Build in and utilize best practices

Managing governance, risk, and compliance in healthcare enterprises is a daunting task. GRC implementation for healthcare risk managers can be difficult, especially during this time of rapid digital and cloud transformation. But relying on internal legacy methods and tools leads to the same issues that have been seen on-premises, stifling innovation and improvement. As organizations adapt to cloud environments as a key element of digital transformation and integrated health care, leaders are realizing that now is the time to leverage the technology to implement GRC frameworks that accelerate their progress toward positive outcomes. What’s needed is expertise and a clear roadmap to success.

Cloud Automation of GRC

The road to success starts with a framework, aligned to business objectives, that provides cloud automation of Governance, Risk, and Compliance. Breaking this into three distinct phases, ideally this would involve:

  1. Building a Solid Foundation – within the cloud environment, ensuring infrastructure and applications are secured before they are deployed.
  • Image/Operation System hardening automation pipelines.
  • Infrastructure Deployment Automation Pipelines including Policy as Code to meet governance requirements.
  • CI/CD Pipelines including Code Quality and Code Security.
  • Disaster Recovery as a Service (DRaaS) meeting the organization’s Business Continuity Planning requirements.
  • Configuration Management to allow automatic remediation of your applications and operating systems.
  • Cost Management strategies with showback and chargeback implementation.
  • Automatic deployment and enforcement of standard security tools including FIM, IDS/IPS, AV and Malware tooling.
  • IAM integration for authorization and authentication with platforms such as Active Directory, Okta, and PingFederate, allowing for more granular control over users and elevated privileges in the clouds.
  • Reference Architectures created for the majority of the organization’s needs that are pre-approved, security baked-in to be used in the infrastructure pipelines.
  • Self-service CMDB integration with tools such ServiceNow, remedy and Jira ServiceDesk allowing business units to provision their own infrastructure while providing the proper governance guardrails.
  • Resilient Architecture designs
  1. Proper Configuration and MaintenanceInfrastructure misconfiguration is the leading cause of data breaches in the cloud, and a big reason misconfiguration happens is infrastructure configuration “drift,” or change that occurs in a cloud environment post-provisioning. Using automation to monitor and self-remediate the environment will ensure the cloud environment stays in the proper configuration eliminating the largest cause of incidents. Since workloads will live most of their life in this phase, it is important to ensure there isn’t any drift from the original secure deployment. An effective program will need:
  • Cloud Integrity Monitoring using cloud native tooling.
  • Log Management and Monitoring with centralized logging, critical in a well-designed environment.
  • Application Monitoring
  • Infrastructure Monitoring
  • Managed Services including patching to resolve issues.
  • SLAs to address incidents and quickly get them resolved.
  • Cost Management to ensure that budgets are met and there are no runaway costs.
  • Perimeter security utilizing cloud native and 3rd party security appliance and services.
  • Data Classification
  1. Use of Industry Leading Tools – for risk assessment, reporting, verification and remediation. Thwart future problems and provide evidence to stakeholders that the cloud environment is rock solid. Tools and verification components would include:
  • Compliance reporting
  • Risk Registry integration into tools
  • Future attestations (BAAs)
  • Audit evidence generation

Where do you go from here?

Your organization needs to innovate faster and drive value with the confidence of remaining in compliance. You need to get to a proactive state instead of being reactive. Consider an assessment to help you evaluate your organization’s place in the cloud journey and how the disparate forms of data in the organization are collected, controlled, processed, stored, and protected.

Start with an assessment that includes:

  • Identification of security gaps
  • Identification of foundational gaps
  • Remediation plans
  • Managed service provider onboarding plan
  • A Phase Two (Foundational/Remediation) proposal and Statement of Work

About 2nd Watch

2nd Watch is a trusted and proven partner, providing deep skills and advisory to leading organizations for over a decade. We earned a client Net Promoter Score of 85, a good way of telling you that our customers nearly always recommend us to others. We can help your organization with cloud native solutions. We offer skills in the following areas:

  • Developing cloud first strategies
  • Migration of workloads to the cloud
  • Implementing automation for governance and security guardrails
  • Implementing compliance controls and processes
  • Pipelines for data, infrastructure and application deployment
  • Subject matter expertise for FHIR implementations
  • Managed cloud services

Schedule time with an expert now, contact us.

-Tom James, Sr. Marketing Manager, Healthcare

An Introduction to AWS Proton

As a business scales, so does its software and infrastructure. As desired outcomes adapt and become more complex that can quickly cause a lot of overhead and difficulty for platform teams to manage over time and these challenges often limit the benefits of embracing containers and serverless. Shared services offer many advantages in these scenarios by providing a consistent developer experience while also increasing productivity and effectivity of governance and cost management.

Introduced in December 2020 Amazon Web Services announced the general availability of Proton: an application targeted at providing tooling to manage complex environments while bridging infrastructure and deployment for developers. In this blog we will take a closer look into the benefits of the AWS Proton service offering.

What is AWS Proton?

AWS Proton is a fully managed delivery service, targeted at container and serverless workloads, that provides engineering teams the tooling to automate provisioning and deploy applications while enabling them to provide observability and enforce compliance and best practices. With AWS Proton, development teams utilize resources for infrastructure and to deploy their code. This in turn increases developer productivity by allowing them to focus on their code, software delivery, reduce management overhead, and increase release frequency. Teams can use AWS Proton through the AWS Console and the AWS CLI, allowing for teams to get started quickly and automate complicated operations over time.

How does it work?

The AWS Proton framework allows administrators to define versioned templates which standardize infrastructure, enforce guard rails, leverage Infrastructure as Code with CloudFormation, and provide CI/CD with Code Pipeline and Code Build to automate provisioning and deployments. Once service templates are defined, developers can choose a template and use it to deploy their software. As new code is released, the CI/CD pipelines automatically deploys the changes. Additionally, as new template versions are defined, AWS Proton provides a “one-click” interface which allows administrators to roll out infrastructure updates across all the outdated template versions.

When is AWS Proton right for you?

AWS Proton is built for teams looking to centrally manage their cloud resources. The service interface is built for teams to provision deploy and monitor applications. AWS Proton is worth considering if you are using cloud native services like Serverless applications or if you utilize containers in AWS. The benefits continually grow when working with a service-oriented architecture, microservices, or distributed software as it eases release management, reduces lead time, and creates an environment for teams to operate within a set of rules with little to no additional overhead. AWS Proton is also a good option if you are looking to introduce Infrastructure as Code or CI/CD pipelines to new or even existing software as AWS Proton supports linking existing resources.

Getting Started is easy!

Platform Administrators

Since AWS Proton itself is free and you only pay for the underlying resources, you are only a few steps away from giving it a try! First a member of the platform infrastructure team creates an environment template. An environment defines infrastructure that is foundational to your applications and services including compute networking (VPCs), Code Pipelines, Security, and Monitoring. Environments are defined via CloudFormation templates and use Jinja for parameters rather than the conventional parameters section in standard CloudFormation templates. You can find template parameter examples in the AWS documentation. You can create, view, update, and manage your environment templates and their versions in the AWS Console.

Once an environment template is created the platform administrator would create a service template which defines all resources that are logically relative to a service. For example, if we had a container which performs some ETL this could contain an ECR Repository, ECS Cluster, ECS Service Definition, ECS Task Definition, IAM roles, and the ETL source and target storage.

In another example, we could have an asynchronous lambda which performs some background tasks and its corresponding execution role. You could also consider using schema files for parameter validation! Like environment templates, you can create, view, update, and manage your service templates and their versions in the AWS Console.

Once the templates have been created the platform administrator can publish the templates and provision the environment. Since services also include CI/CD pipelines platform administrators should also configure repository connections by creating the GitHub app connector. This is done in the AWS Developer Tools service or a link can be found on the AWS Proton page in the Console.

Once authorized, the GitHub app is automatically created and integrated with AWS and CI/CD pipelines will automatically detect available connections during service configuration.

 

At this time platform administrators should see a stack which contains the environment’s resources. They can validate each resource, interconnectivity, security, audits, and operational excellence.

Developers

At this point developers can choose which version they will use to deploy their service. Available services can be found in the AWS Console and developers can review the template and requirements before deployment. Once they have selected the target template they choose the repository that contains their service code, the GitHub app connection created by the platform administrator, and any parameters required by the service and CodePipeline.

After some time, developers should be able to see their application stack in CloudFormation, their application’s CodePipeline resources, and the resources for their application accordingly!

In Closing

AWS Proton is a new and exciting service available for those looking to adopt Infrastructure as Code, enable CI/CD pipelines for their products, and enforce compliance, consistent standards, and best practices across their software and infrastructure. Here we explored a simple use case, but real world scenarios likely require a more thorough examination and implementation.

AWS Proton may require a transition for teams that already utilize IaC, CI/CD, or that have created processes to centrally manage their platform infrastructure. 2nd Watch has over 10 years’ experience in helping companies move to the cloud and implement shared services platforms to simplify modern cloud operations. Start a conversation with a solution expert from 2nd Watch today and together we will assess and create a plan built for your goals and targets!

-Isaiah Grant, Cloud Consultant

7 Trends Influencing DevSecOps & DevOps Adoption

Companies worldwide have been increasing DevOps adoption and DevSecOps adoption into their regular workflows at an exponential rate. Whether following Agile methodologies or creating independent workflows stemming from DevOps, companies have been leveraging the faster manufacturing rate with superior quality that DevSecOps provides.

However, the increasing development in autonomous technologies such as AI or ML is idealizing a work cycle where the system operates independently of humans. It aims to provide faster, reliable, and better products – shifting from DevOps to NoOps.

A set of practices coupling software development (Dev) and information technology operations (Ops), DevOps is the combination of employees, methods, and products to allow for perpetual, seamless delivery of quality and value. Adding security to a set of DevOps practices, a DevSecOps approach provides multiple layers of security and reliability by integrating highly secure, robust, and dependable processes and tools into the work cycle and the final product.

This desirable outcome of integrating DevOps and DevSecOps into corporations has made it a trendy work cycle in the market. However, with a growing focus on automation and development in Artificial Intelligence and Machine Learning, we could be heading into a NoOps scenario, where self-learning and self-healing systems govern the work processes.

NoOps is a work cycle wherein the technologies used by a company are so autonomous and intelligent that DevOps and DevSecOps do not need to be exclusively implemented to maintain a continuous outflow of quality and value.

What are the trends that truly influence DevOps and DevSecOps adoptions in countless tech businesses – small and large – all across the globe? Download our 7 Trends Influencing DevOps/DevSecOps Adoption to find out.

-Mir Ali, Field CTO

You’re on AWS. Now What? 5 Strategies to Increase Your Cloud’s Value

Now that you’ve migrated your applications to AWS, how can you take the value of being on the cloud to the next level? To provide guidance on next steps, here are 5 things you should consider to amplify the value of being on AWS.

Ten Years In: Enterprise DevOps Evolves

DevOps has undergone significant changes since the trend began more than a decade ago. No longer limited to a grassroots movement among ‘cowboy’ developers, DevOps has become synonymous with enterprise software releases. In our Voice of the Enterprise: DevOps, Workloads and Key Projects 2020 survey, we found that 90% of companies that had deployed applications to production in the last year had adopted DevOps across some teams (55%) or entirely across the IT organization (40%). Another 9% were in discovery phases or PoC with their DevOps implementation, leaving only a tiny fraction of respondents reporting no adoption of DevOps.

What is DevOps

DevOps is driven by the need for faster releases, more efficient IT operations and flexibility to respond to changes in the market, whether technical such as the advent of cloud-native technologies, or other, such as the Covid-19 pandemic.

Still, one of the biggest drivers of the trend and a primary reason DevOps has become part and parcel of enterprise software development and deployment is adoption from the top-down. IT management and executive leadership are increasingly interested and involved in DevOps deployments, often because it is a critical part of cloud migration, digital transformation and other key initiatives.

Most organizations also report that their DevOps implementation is managed or sanctioned by the organization, in line with the departure from shadowy IT DevOps deployments of 5 or 10 years ago toward approved deployments that meet policy, security and compliance requirements.

Another significant change in DevOps is the growing role of business objectives and outcomes. Organizations are measuring and proving their DevOps success not only using technical metrics such as quality (47%) and application performance (44%), but also business metrics such as customer satisfaction (also 44%), according to our VotE DevOps study.

We also see line-of-business managers among important stakeholders in DevOps beyond developers and IT operators. The increased focus and priority on business also often translates to a different view on DevOps and IT operations in general. While IT administration has traditionally been a budget spending item with a focus on total cost of ownership (TCO), today’s enterprises are increasingly viewing DevOps and IT ops as a competitive advantage that will bring return on investment (ROI).

DevOps Stakeholder Spread

Another significant aspect of DevOps today is the stakeholder spread. Our surveys have consistently highlighted how security, leadership, traditional IT administrators and business/product managers play an increasingly important role in DevOps, in addition to software developers and IT operations teams. As DevOps spreads to more teams and applications within an organization, it is more likely to pull in these and other key stakeholders, including finance or compliance, among others.

We also see additional people and teams, such as those in sales and marketing or human relations, becoming more integral to enterprise DevOps as the trend continues to evolve.

The prominence of security among primary DevOps stakeholders is indicative of the rapidly evolving DevSecOps trend, whereby security elements are integrated into DevOps workflows.

Our data highlights how a growing number of DevOps releases include security elements, with 64% of companies indicating they do include security elements in 2020, compare to 53% in 2019. DevSecOps is being driven mainly by changing attitudes among software developers, who are increasingly less likely to think the security will slow them down and more likely to tie security to quality, which is something they care about.

DevOps Software Security

Software security vendors have also worked to make security tooling such as API firewalls, vulnerability scanning and software composition analysis (SCA) more integrated and automated so they really don’t slow down developers. Finally, the frequency of high-profile security incidents and breaches remind everyone of the need to reduce risk as much as possible.

Another change in DevOps is an increasing awareness and appreciation of not just technology challenges, but also cultural aspects. Our data indicates top cultural challenges of DevOps include overcoming resistance to change, competing/conflicting priorities and resources, promoting communication and demonstrating equity of benefits/costs.

By aligning objectives, priorities and desired outcomes, teams can better address these cultural challenges to succeed and spread their DevOps implementations. This is also where we’ve seen cross-discipline experience – in development, in IT operations, in security, etc. – can be integral to addressing cultural issues.

If you haven’t yet begun your own DevOps Transformation, 2nd Watch takes an interesting approach you can consider. Their DevOps Transformation process begins with a complete assessment and strategy measuring your current software development and operational maturity, using the CALMS model, and developing a strategy for where and how to apply DevOps approaches

Jay Lyman, Senior Research Analyst, Cloud Native and Applied Infrastructure & DevOps at 451 Research, part of S&P Global Market Intelligence

4 DevOps Myths Debunked

DevOps is a set of cultural values and organizational practices that improve business outcomes by increasing collaboration and feedback between teams. Of course, there are industry best practices, but a DevOps transformation will look different and yield different results for each organization, depending on its business and strategy. With a lot of options and moving parts to a DevOps transformation, don’t let these myths delay beginning your transformation.

Myth #1: Tools will solve your DevOps problems.

Unfortunately, even the best tools are not going to solve all your DevOps issues. Tools are enablers that assist in removing unnecessary toil, but they can’t magically make things perfect. For instance, implementing an automation tool sounds like a great time and resource saver at first glance. However, the tool can only produce those results if the structure around the tool can accommodate the action. If your team isn’t ready for that speed, you’ll likely just speed to failure.

Don’t put the tools before the structure. Instead, think long-term and comprehensively when constructing your DevOps transformation map. Otherwise, roadblocks will slow down your ability to achieve speed.

Myth #2: You should start with CI/CD.

Typically, people begin their DevOps transformation with continuous integration (CI) and continuous delivery (CD). A CI/CD pipeline enables fast code changes through automated deployment steps that create a more consistent and agile environment. While the results of CI/CD are the goal, starting there doesn’t take into account the support necessary for successful implementation.

Today, the DevOps transformation is being refined to include discussions and planning around the evolvement of production support, application monitoring, and automated dashboards. When you start with CI/CD, you’re focused on development speed, but operations might not be ready to accommodate. In true DevOps fashion, you need to bridge the gap between development and operations first to produce a streamlined feedback loop. Operations must have their tools ready to feed into the CI/CD pipeline to break down barriers early on and avoid stopping points in the future.

Myth #3: DevOps transformation and cloud transformation can’t happen at the same time.

Promises of more speed and lower costs motivate businesses to jump into the cloud quickly, with the expectation that those benefits and return on investment (ROI) are delivered immediately. The issue with this way of thinking is not enough forethought prior to action, with a fracture resulting between departments. Teams need to be trained on new cloud procedures, security must be implemented, legal has to update contracts, and company culture, from the top down, needs to be onboard for adoption.

Fortunately, there’s a lot of overlap between a DevOps transformation and a cloud transformation. In fact, DevOps can be the support you need for a successful cloud transformation without any roadblocks. Instead of waiting on DevOps because you’re not agile yet, start with it at the beginning of your cloud transformation. Utilize DevOps best practices as you migrate to the cloud to help transform how your teams work with a well-constructed plan for company-wide implementation.

Myth #4: The role of security is for vulnerability scanning.

Waiting until you’re finished with development to include security is a DevOps anti-pattern. As an essential part of the business, security can contribute more than just vulnerability scanning before you go live. When you only look to security for the last line screening, you’re inviting a significant bottleneck into your process.

Of course, getting security involved and excited about DevOps can be a struggle because they’re inherently at odds. The goal of DevOps is to increase speed with new tools. The goal of security is to decrease risk, which can slow processes and releases. But when you apply speed and change with new implementations, you are increasing risk. Instead of asking, “How do we get security involved before vulnerability scanning?” consider the benefit of getting development to include security as part of the CI/CD pipeline. Automate steps like vulnerability scanning, secrets detection, license checks, SAST & DAST early in the development cycle so that issues are found and addressed early on. This removes the security roadblock to production.

In addition, cross-training between DevOps and security invites both teams to understand their colleagues’ goals, responsibilities, roles, expectations, risks, and challenges. Give each team real life examples of how the gap creates conflict for each side. Once they have a better understanding of the other side, they’re more likely to consider one another during product planning and development.

One well-known and widely accepted truth to a successful DevOps transformation is the benefit of an expert partner in the process. 2nd Watch offers packaged service offerings to help you get the most out of your DevOps transformation with start to finish essentials that deliver the results you expect. Contact Us to see how you can gain more leverage with less risk.

-Stefana Muller, Sr Product Manager, DevOps & Migration

 

A DevOps Transformation Overview: What, How, Who, and Why

When your organization needs to address a specific problem, change the status quo, follow new trends, add a premier service, etc., it requires an approach that leads to success. A DevOps Transformation is the modern IT leader’s choice for achieving the speed and innovation needed to meet today’s market demands.

What is DevOps?

DevOps is a set of practices that combines software development, ‘Dev’, and IT operations, ‘Ops.’ The term was spurred from the initial struggle that existed between these two vital pieces of product creation. However, as our technology has expanded and become more business focused, so has the term.

Initially, businesses were mostly focused on making development and operations work better together by providing appropriate processes and specific automation technology. However, over the nearly 12 years that this term has been in existence, businesses have grown, and we’ve realized that the struggle doesn’t just exist between dev and ops, but rather the entire structure of the business.

How has DevOps evolved?

DevOps grew from the agile transformation effort where companies had to speed up, find new ways to develop software, and go-to-market quicker in order to remain competitive. Although agile was initially a development methodology, it makes sense that we now use it as part of a DevOps Transformation, expanding the use of agile across business areas to help companies quickly deliver the highest value to their customers.

Another big evolution in DevOps is how information should flow. DevOps used to encourage a bi-directional exchange between developers and operations, but now it’s omni-directional throughout the entire organization including departments like security, finance, marketing, product management, and business-line owners. It’s important to expand the feedback loop to and from all the stakeholders in an organization – including your customers – in order to fully deliver high value products or services.

If departments are unable or unwilling to share their wins and losses, communicate candidly, and exchange information, the transformation will hit barrier after barrier. This is especially important for project management, which has to change its processes drastically in a DevOps Transformation in comparison to a department-specific or smaller scale project. With the main objective being speed, planning is critical.

Who is involved in a DevOps Transformation?

The short answer is everyone. When you go through a DevOps Transformation, your company is essentially speeding things up. Typically, the action takes place in the application development and cloud operations space because that’s where you develop and deploy new products or features. But it’s not just the traditional Dev and Ops teams being affected by the transformation. Executives need to be all-in to encourage cooperation throughout the organization. Finance has to transact quicker, sales needs to sell differently, marketing has to understand new features and find the best ways to promote them, and legal has to update contracts with clients and providers to enable the rapid change brought by this model.

Today’s DevOps Transformation affects almost every business area in an organization, including cultural values, organizational practices, and improving business outcomes by increasing collaboration and feedback. This is why we refer to it as a transformation rather than an implementation – it’s really going to change your entire business.

Why are so many companies choosing DevOps?

A DevOps Transformation isn’t the only way to approach change management, but beneficial outcomes are making it a popular one.

  • Streamlined processes: Remember that the foundation of DevOps is built on removing the struggle between departments. Enabling teams to cross-innovate, by eliminating barriers and encouraging a culture of constant innovation, propels your business forward faster.
  • Challenges resolved: When your approach is based on removing issues and facilitating an omni-directional exchange of information, you get an unencumbered view of what those issues are and can then work toward resolution.
  • Specific benefits achieved: DevOps is used to target specific goals, and with the measurement necessary to determine success, IT leaders inherently receive a slew of additional benefits. For example, if you’re using DevOps to address high development costs, you won’t only accomplish cost reduction, but also faster time to market and higher security in your development cycle.
  • Valuable data collected: DevOps requires you to measure, report, and be transparent with everything you do. These insights not only aid the DevOps Transformation currently in focus, but also future initiatives.
  • Elevated customer experience: Delighting your customers with new, stable technology on a frequent basis will contribute to retention and new business growth.

2nd Watch has developed a number of DevOps Transformation services to aid enterprises in their transformations, including assessment and strategy, training and tooling, continuous integration and continuous delivery (CI/CD), cloud native application modernization, and full DevOps management. Get more out of your DevOps Transformation while becoming self-sufficient for the future. Contact Us to discuss how a DevOps Transformation can help you achieve your goals.

-Stefana Muller, Sr Product Manager, DevOps & Migration

Cloud Crunch Podcast: Managed DevOps – An Oxymoron?

Managed DevOps sounds like an oxymoron, so why would someone consider it? Hear from our DevOps pro about the factors that contribute to companies stalling mid-DevOps Transformation and how a Managed DevOps strategy can help overcome that plateau. We’d love to hear from you! Email us at CloudCrunch@2ndwatch.com with comments, questions and ideas. Listen now on Spotify, iTunes, iHeart Radio, Stitcher, or wherever you get your podcasts.