Accelerate release lifecycle with pathway to deploy: Part 1

For many enterprises, the journey to cloud reduces technical debt costs and meets CapEx-to-OpEx objectives. This includes rearchitecting to microservices, lift-and-shift, replatforming, refactoring, replacing and more. As practices like DevOps, cloud native, serverless and site reliability engineering (SRE) mature, the focus is shifting toward significant levels of automation, speed, agility and business alignment with IT (which helps enterprise IT transform into engineering organizations).

Many enterprises struggle to derive real value from their cloud journeys and may continue to overspend. Multiple analysts have reported that over 90% of enterprises continue to overspend in cloud, often without realising substantial returns.

The true essence of value emerges when business and IT can collaborate to create new capabilities at a high speed, resulting in greater developer productivity and speed to market. Those objectives require a target operating model. Rapidly deploying applications to cloud requires not just development acceleration with continuous integration, deployment and testing (CI/CD/CT), It also requires supply chain lifecycle acceleration, which involves multiple other groups such as governance risk and compliance (GRC), change management, operations, resiliency and reliability. Enterprises are continuously looking for ways that empower product teams to move from concept to deploy faster than ever.

Automation-first and DevSecOps-led approach

Enterprises often retrofit cloud transformation elements within existing application supply chain processes rather than considering new lifecycle and delivery models that are suited for speed and scale. The enterprises that reimagine the application lifecycle through an automation-first approach encourage an engineering-driven product lifecycle acceleration that realizes the potential of cloud transformation. Examples include:

• Pattern-based architecture that standardizes the architecture and design process (while teams have the autonomy to choose patterns and technology or co-create new patterns).
• Patterns that address security and compliance dimensions, ensuring traceability to these requirements.
• Patterns-as-code that help codify multiple cross-cutting concerns (this also promotes the inner source model of patterns maturity and drive reusability).
• DevOps pipeline-driven activities that can be utilized across the lifecycle.
• Automatic generation of specific data needed for security and compliance reviews.
• Operational-readiness reviews with limited or no manual intervention.

As enterprises embrace cloud native and everything as code, the journey from code to production has become a critical aspect of delivering value to customers. This intricate process, often referred to as the “pathway to deploy,” encompasses a series of intricate steps and decisions that can significantly impact an organization’s ability to deliver software efficiently, reliably and at scale. From architecture, design, code development, testing to deployment and monitoring, each stage in the pathway to deploy presents unique challenges and opportunities. As you navigate the complexities that exists today, IBM® aims to help you uncover the strategies and target state mode for achieving a seamless and effective pathway to deploy.

The best practices, tools, and methodologies that empower organizations to streamline their software delivery pipelines, reduce time-to-market, enhance software quality, and ensure robust operations in production environments will all be explored.

Pathway to deploy: Current view and challenges

The diagram below summarizes a view of enterprise software development life cycle (SDLC) with typical gates. While the flow is self-explanatory, the key is to understand that there are several aspects of the software supply chain process that make this a combination of waterfall and intermittent agile models. The challenge is that the timeline for build-deploy of an application (or an iteration of that) is impacted by several first- and last -mile activities that typically remain manual.

The key challenges with the traditional nature of SDLC are:

1. Pre-development wait time of 4-8 weeks within architecture and design phase to get to development. This is caused by:

• Multiple first-mile reviews to ensure no adverse business impacts, including privacy concerns, data classification, business continuity and regulatory compliance (and most of these are manual).
• Enterprise-wide SDLC processes that remain waterfall or semi-agile, requiring sequential execution, despite agile principles in development cycles (for example, environment provisioning only after full design approval).
• Applications that are perceived as “unique” are subject to deep scrutiny and interventions with limited opportunities for acceleration.
• Challenges in institutionalizing patterns-based architecture and development due to lack of cohesive effort and change agent driving, such standardization.
• A security culture that affects the speed of development, with adherence to security controls and guidelines often involving manual or semi-manual processes.

2. Development wait time to provision environment and CI/CD/CT tooling integration due to:

• Manual or semi-automated environment provisioning.
• Patterns (on paper) only as prescriptive guidance.
• Fragmented DevOps tooling that requires effort to stitch together.

3. Post-development (last-mile) wait time before go-live is easily 6–8 weeks or more due to:

• Manual evidence collection to get through security and compliance reviews beyond standard SAST/SCA/DAST (such as security configuration, day 2 controls, tagging and more).
• Manual evidence collection for operation and resiliency reviews (such as supporting cloud operations and business continuity).
• Service transition reviews to support IT service and incident management and resolution.

Pathway to deploy: Target state

The pathway to deploy target state requires a streamlined and efficient process that minimizes bottlenecks and accelerates software supply chain transformation. In this ideal state, the pathway to deploy is characterized by a seamless integration of design (first mile), as well as development, testing, platform engineering and deployment stages (last mile), following agile and DevOps principles. This helps accelerate deployment of code changes swiftly and automatically with necessary (automation-driven) validations to production environments.

IBM’s vision of target state prioritizes security and compliance by integrating security checks and compliance validation into the CI/CD/CT pipeline, allowing for early detection and resolution of vulnerabilities. This vision emphasizes collaboration between development, operations, reliability and security teams through a shared responsibility model. It also establishes continuous monitoring and feedback loops to gather insights for further improvement. Ultimately, the target state aims to deliver software updates and new features to end users rapidly, with minimal manual intervention and with a high degree of confidence for all enterprise stakeholders.

The diagram below depicts a potential target view of pathway to deploy that helps embrace the cloud-native SDLC model.

Key elements of the cloud-native SDLC model include:

• Pattern-driven architecture and design institutionalized across the enterprise.
• Patterns that incorporate key requirements of security, compliance, resiliency and other enterprise policies (as code).
• Security and compliance reviews that are accelerated as patterns and used to describe the solution.
• Core development, including the creation of environments, pipelines and services configuration (which is driven through platform engineering enterprise catalog).
• CI/CD/CT pipeline that builds linkages to all activities across pathway to deploy lifecycle.
• Platform engineering builds-configures-manages platforms and services with all enterprise policies (such as encryption) embedded as platform policies.
• Security and compliance tooling (for example, vulnerability scans or policy checks) and automation that is integrated to the pipelines or available as self-service.
• Generation of a high degree of data (from logs, tool outputs and code scan insights) for several reviews without manual intervention.
• Traceability from backlog to deployment release notes and change impact.
• Interventions only by exceptions.

Pathway to deploy drives acceleration through clarity, accountability and traceability

By defining a structured pathway to deploy, organizations can standardize the steps involved in supply chain lifecycle, ensuring each phase is traceable and auditable. This allows stakeholders to monitor progress through distinct stages, from initial design to deployment, providing real-time visibility into the program’s status. Assigning ownership at each stage of the pathway to deploy ensures that team members are accountable for their deliverables, making it easier to track contributions and changes, as well as accelerating issue resolution with the right level of intervention. Traceability through the pathway to deploy provides data-driven insights, helping to refine processes and enhance efficiency in future programs. A well-documented pathway to deploy supports compliance with industry regulations and simplifies reporting, as each part of the process is clearly recorded and retrievable.

Source: ibm.com

Continue reading

DevOps or DevSecOps?

Currently, security attacks are getting more sophisticated and targeting a wider array of system components. This makes preventing and recovering from them more difficult especially when security knowledge and responsibilities are siloed within an organization. It is increasingly more important to ensure that everyone in an organization has a stake in security and that the company’s experts integrate more deeply with other teams. Many companies claim to make security a pillar of culture, but rarely do they invest in more than the occasional training. To truly make security a fundamental pillar, it must be embedded deeper within the organization’s engineering teams and software development life cycles (SDLCs). The latest trend in operationalizing security within tech organizations is the melding of DevOps and security professionals into a joint DevSecOps team and bringing automation, along the domain of quality assurance, into the security toolset to further reduce risk.

Experienced DevOps professionals have long understood their responsibility for keeping tabs on the security risks in their purview, but in many organizations they don’t necessarily have the tools or backing to delve more broadly into security. Often team members have I-shaped skillsets and responsibility areas and their window of involvement in security are kept very narrow and strictly within the operational activities of their team. This makes operationalizing security across the organization much more difficult. This is especially true in larger organizations where the collaboration barriers between teams and departments are more rigid and having security personnel siloed is itself a vulnerability. When security is only a small sliver of individual or team responsibilities, issues are found much later in the process and the risk level and cost of remediation rises.

This is mitigated by embedding security within other teams in the organization. Lately, the trend towards blended DevSecOps teams with broader security oversight helps address the challenges organizations face by removing the silos and barriers of collaboration within this area of the organization. This allows security to be shifted within company workflows facilitating discovery and mitigation of risks and vulnerabilities. It acknowledges the scenario that the later a vulnerability is discovered, timely remediation, spent effort and risk exposure are more costly. Ensuring security guardrails are in place earlier in the development cycle reduces the cost of security and compliance programs and reduces the likelihood of high risk issues making it to production without  a mitigation strategy.

A lot of companies claim security is everyone’s job. But often the culture of security ends at annual anti-phishing trainings and/or the occasional confidentiality discussion. Embedding security experts into teams like DevOps and ensuring experts are hired with enough security knowledge in their toolbox brings it deeper into the company’s culture. Once planted, those roots will grow. In many cases converting to the DevSecOps model will be mostly painless. The actual team process will largely stay the same regardless of the development model the team is using although this shift is especially effective in agile organizations. Workloads should also remain stable—if not decrease—as the time is no longer spent on fixing vulnerabilities in production.

While putting security experts in roles on a DevOps team is a start, it is ever more important to hire DevOps engineers with T-shaped skillsets. While they may not be deep experts, the critical part is that they have security and compliance skills in their repertoires. Their primary duties day-to-day may not be security focused, however in their work with other teams, their security consciousness and conscientiousness will rub off. and spread. They will find issues earlier in the pipeline and the teams they work with will will learn from them and gain the knowledge to spot and even prevent issues. They bring a concern for security standards into their interactions with other engineering teams and over time they help transform the overall culture of engineering into one that is more security conscious.

Automation also plays a key role in risk reduction. Much like automating tests to find bugs earlier, shifting security monitoring left and automating vulnerability-checks and adherence to security policies will save additional effort and money later down the line. While shifting to this DevSecOps model reduces risk, relying on manual processes only goes so far. Automation reduces the human element and the chance something will be overlooked. Properly designed automation tools shift the possibility of human error even further to where it is very easy to remediate. Having skilled DevOps engineers with security experience who can automate these activities pays off.

In addition, team empowerment is incredibly important. By shifting activities left and automating, risk can be reduced incredibly. However, it’s impossible to completely negate it. It’s critical for teams to be empowered to speak up and have proper ways to report any issues found. Making the changes to bring security into DevOps and automate the process mentioned will go a long way towards building the culture of security consciousness that is needed for this. Embedding security deeper in teams and making it part of their daily workflows and conversations shows employees that the company prioritizes security in their operations and cares about vigilance and conscientious reporting.

Adding security consciousness to the DevOps services available to the rest of the company will ensure that risks are considered earlier in the pipeline. This saves companies time and money in remediating those risks and will come at little to no cost to team workflows and velocities. Automation further reduces risk by shifting security even farther in the process and it reduces the risk of human error. These changes also make security a deeper part of company culture. Disseminating knowledge—and attention to the details related to security to the teams and employees with whom DevOps works closely—empowers the entire organization to make security a priority. Vulnerabilities and compliance issues will be found much earlier in the process reducing the cost of fixing them and the risk of production incidents.

Source: ibm.com

Continue reading