DOCSLIB.ORG

Strategy & Technical Considerations for Successful Enterprise Devops

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Strategy & Technical Considerations for Successful Enterprise DevOps Credit: metamorworks By Jon Collins Strategy & Technical Considerations for Successful Enterprise DevOps 09/18/2018 Table of Contents 1. Summary 2. Why Enterprise DevOps and What Makes It So Hard? 3. Shift to Customer-Centricity 4. Deliver Agile Best Practice 5. Connect Data and Services 6. Automate Development and Delivery 7. Orchestrate and Operate Infrastructure 8. Conclusion 9. About Jon Collins 10. About GigaOm 11. Copyright Strategy & Technical Considerations for Successful Enterprise DevOps 2 1 Summary This report covers enterprise drivers, pain points, and contextual factors that make DevOps both essential and difficult to achieve in larger organizations. DevOps brings a number of benefits to enterprises looking to deliver technology-based solutions more quickly. It can increase business value and reduce costs by: enabling new ideas to be tested, adopted or adapted; bringing engineering and business teams together; reducing time to market; shortening development cycles; increasing responsiveness to new requirements, incidents, and threats; and reinforcing a brand’s position as leading-edge and customer-focused. The five fundamental pillars to Enterprise DevOps enable the model to broaden outside of individual initiatives. They include: considering the need to shift to customer-centricity; delivering agile best practice; connecting data and services; automating deployment and delivery; and finally, orchestrating operations infrastructure. In each of these areas, the challenges of enterprise business-as-usual cause what might be termed “DevOps Friction,” that is, overheads that risk slowing down DevOps cycles and therefore undermining the benefits it can bring. A wide range of tools and technology vendors exists to respond to each of these challenges. While many tools exist to support DevOps, the litmus test for their effectiveness is how much friction they remove from the development pipeline, increasing efficiency without undermining governance, for example, through self-service or rules-based decisions. In order to deliver a comprehensive DevOps solution, enterprise decision makers must evaluate their breadth of needs over the next one to three years. Then they must limit their field of vision to the subset of capabilities that will meet the majority of their requirements, which includes setting a target platform strategy, a delivery strategy, and a toolchain strategy in response. The DevOps approach is fundamental to what is currently being called digital transformation. To be clear, a transformation to the digitally-enabled enterprise is also a transformation to using DevOps: either both will succeed, or both will fail. And just as digital transformation requires executive buy-in, so does DevOps. In the future, it is likely that a common set of practices and standards will emerge from DevOps; that the market landscape for tools will consolidate and simplify; and that infrastructure Strategy & Technical Considerations for Successful Enterprise DevOps 3 platforms will become increasingly automated; a symptom of all three will be the increasing use of AI. We would therefore advise any enterprise to embrace the principles of DevOps, which are unlikely to change, whilst seeing any toolchain as an enabler to delivering on DevOps today. Strategy & Technical Considerations for Successful Enterprise DevOps 4 2 Why Enterprise DevOps and What Makes It So Hard? Today’s enterprises are under pressure to deliver a consistent return to investors while satisfying existing customers and maintaining brand awareness and reputation. CMOs and other lines of business are increasingly responsible for large parts of the technology budget. At the same time, boardrooms face an onslaught of digital propaganda—from media, consulting firms and indeed, analysts—who tell them they need to transform if they are to keep up with the competition. Against this background, technology has become its own worst enemy. Repeated deployments of infrastructure and software have created legacy environments that slow rather than enable progress. Cloud-based solutions have the potential to unblock this bottleneck, and many enterprises look enviously at organizations, which are unencumbered by existing infrastructure and processes, that have come from nowhere to become a competitive threat. Enterprises know they have to deliver technology-based solutions more quickly, if they are to stay relevant. In principle, rapid delivery: • enables new ideas to be tested, adopted, or adapted based on evolving customer need • brings engineering and business teams together, enabling more customer-centric outcomes • reduces time to market, delivering a first-mover advantage and increasing revenues • shortens development cycles, increasing productivity and reducing delivery costs • increases responsiveness to new requirements, incidents, and threats • reinforces a brand’s position as leading-edge and customer-focused Software development practices have been evolving for many years to enable these benefits; however, a gulf has remained between enterprise developers and operations teams. The goal of DevOps is to close this gap through the use of automated deployment, shared information, and increased collaboration. This models the way in which newer startups tend to work, unlocking the benefits of rapid delivery. While the reasons to adopt DevOps—deliver faster and with higher quality, increase business value, and reduce cost—are increasingly well-established, larger organizations can struggle to move beyond the application team’s DevOps initiative to a broader, business-wide adoption. Strategy & Technical Considerations for Successful Enterprise DevOps 5 The journey to enterprise DevOps can hit a number of bottlenecks, notably around governance, quality assurance, and communication, each of which creates what we might term “DevOps Friction.” DevOps Friction is not something that can be smoothed away with best practice or automation, as it goes to the heart of what make an enterprise tick. In this report, we distill down the results of multiple conversations and briefings with enterprise organizations, best practice experts and indeed, tools vendors, into five enablers that need to be considered in order to successfully expand the role of DevOps in the enterprise. Their order is deliberate: 1. Shift to customer-centricity.If DevOps is about speeding up delivery, we must start with what is being delivered, and why. Across verticals, today’s business success stories are no longer about brand, product, selection, model, or any other historical factor alone, but in how they enable customers to succeed and achieve their own goals. 2. Deliver best practice.DevOps marks a cultural shift from slower, linear practices, to faster approaches that bring in rapid iteration and parallelism. Its procedures and steps are one part of a greater mindset shift, without which progress will be slowed and organizations risk reverting to old ways of doing things. 3. Connect data and services.In terms of deliverables, DevOps success depends on how well platforms of data and existing/new services can be brought along, not just for the ride but in a way that adapts to changing circumstances. Strategy & Technical Considerations for Successful Enterprise DevOps 6 4. Automate deployment.Automation, the traditional heartland of DevOps tooling, remains important. However, it needs to be considered in the context of the first three enablers, to ensure that any progress made in automation is not undermined by challenges in other areas. 5. Operate and orchestrate resources.Finally, the availability of a commoditized, flexible platform is becoming table stakes for DevOps success. As platform and operational efficiency increases, so does the effectiveness of DevOps overall. Or in layperson’s terms, it’s easier to build more things, more quickly, if your pools of resources are more stable and flexible. We look at each enabler in the sections below. Following a problem statement, we cover some of the challenges causing DevOps Friction, due to the additional effort they cause across the pipeline. We also cover a number of tools available today in response. Given the complexity of the tooling landscape, the report does not present an exhaustive feature comparison for each tool; rather, it focuses on what areas stand out. Strategy & Technical Considerations for Successful Enterprise DevOps 7 3 Shift to Customer-Centricity DevOps best practices serve a singular purpose, namely delivering technology-based applications and services that fit the evolving needs of the customer. Enterprises as a whole will confirm that customers are hugely important; however, DevOps teams and structures may not be organized in such a way that they can respond to rapidly changing customer demand. Enabling a shift to customer centricity requires three areas to be addressed across the DevOps cycle: 1. Optimize customer experience 2. Assure security and privacy 3. Test quality and non-functional criteria We look at each below. Strategy & Technical Considerations for Successful Enterprise DevOps 8 3.1. Optimize Customer Experience Strategy & Business Considerations As customers engage more directly with the enterprise, through online and mobile apps as well as customer service channels, customer experience has moved from being a nice-to-have to an essential need. This is as true in business-to-business (B2B) scenarios as in business-to- consumer; for example, in B2B, partner
Recommended publications
  • A Study of the Effectiveness of Cloud Infrastructure

    A Study of the Effectiveness of Cloud Infrastructure

    A STUDY OF THE EFFECTIVENESS OF CLOUD INFRASTRUCTURE CONFIGURATION A Thesis Presented to the Faculty of California State Polytechnic University, Pomona In Partial Fulfillment Of the Requirements for the Degree Master of Science In Computer Science By Bonnie Ngu 2020 SIGNATURE PAGE THESIS: A STUDY OF THE EFFECTIVENESS OF CLOUD INFRASTRUCTURE CONFIGURATION AUTHOR: Bonnie Ngu DATE SUBMITTED: Spring 2020 Department of Computer Science Dr. Gilbert S. Young _______________________________________ Thesis Committee Chair Computer Science Yu Sun, Ph.D _______________________________________ Computer Science Dominick A. Atanasio _______________________________________ Professor Computer Science ii ACKNOWLEDGEMENTS First and foremost, I would like to thank my parents for blessing me with the opportunity to choose my own path. I would also like to thank Dr. Young for all the encouragement throughout my years at Cal Poly Pomona. It was through his excitement and passion for teaching that I found my passion in computer science. Dr. Sun and Professor Atanasio for taking the time to understand my thesis and providing valuable input. Lastly, I would like to thank my other half for always seeing the positive side of things and finding the silver lining. It has been an incredible chapter in my life, and I could not have done it without all the love and moral support from everyone. iii ABSTRACT As cloud providers continuously strive to strengthen their cloud solutions, companies, big and small, are lured by this appealing prospect. Cloud providers aim to take away the trouble of the brick and mortar of physical equipment. Utilizing the cloud can help companies increase efficiency and improve cash flow.
  • Lessons Learned from a Large-Scale Infrastructure As Code Project

    Lessons Learned from a Large-Scale Infrastructure As Code Project

    PowerShell Conference Europe 2019 Hannover, Germany June 4-7, 2019 Lessons learned from a large-scale infrastructure as code project Platinum Sponsor Mark Warneke After this Session - I am able to develop a mature “Infrastructure As Code” project from scratch using a Test-Driven development approach, avoiding common pitfalls and getting a heads up in necessary considerations, tools and best practices - I can build sophisticated Azure Release Pipelines that leverage advanced testing scenarios using Azure Resource Manager Templates, PowerShell tooling to support an advanced “Infrastructure As Code” project @MarkWarneke Agenda Introduction Architecture Demo @MarkWarneke By viewing cloud computing as a starting point for IT automation, companies may be able to have it all: scalability, agility, flexibility, efficiency, “ and cost savings. But that’s only possible by building up both automation and cloud capabilities. – McKinsey @MarkWarneke“ What is the challange? Speed Control Agility @MarkWarneke Why change? Servers Services @MarkWarneke Paradigm shift Enforce/Control Enable/Support Controlled & central responsibility Freedom & delegated responsibility @MarkWarneke What organization want Secure, predictable, and flexible Control service delivery and operations capability (end to end traceability). Faster business innovation through Innovation adoption of cloud services. Business agility and reduced time-to- Speed/Agility market through efficient DevOps teams. Costs Efficient use of public cloud scale. @MarkWarneke DevOps benefits based on research Source: 2018 State of DevOps Report DORA @MarkWarneke A Cloud Center of Excellence (CCoE) is a cross- functional team of people responsible for developing and managing the cloud strategy, “governance, and best practices that the rest of the organization can leverage to transform the business using the cloud.
  • Adoption, Support, and Challenges of Infrastructure-As-Code: Insights from Industry

    Adoption, Support, and Challenges of Infrastructure-As-Code: Insights from Industry

    Adoption, Support, and Challenges of Infrastructure-as-Code: Insights from Industry Michele Guerriero,1 Martin Garriga,2 Damian A. Tamburri,3 Fabio Palomba4 1Politecnico di Milano, Italy 2Jheronimus Academy of Data Science & Tilburg University, The Netherlands 3Jheronimus Academy of Data Science & Eindhoven University of Technology, The Netherlands 4University of Zurich, Switzerland [email protected], [email protected], [email protected], palomba@ifi.uzh.ch Abstract—Infrastructure-as-code (IaC) is the DevOps tactic semi-structured interviews in as many companies to distill: (1) of managing and provisioning infrastructure through machine- how practitioners currently develop infrastructural code — that readable definition files, rather than physical hardware config- is, the best/bad practices experienced by the practitioners as uration or interactive configuration tools. From a maintenance and evolution perspective, the topic has piqued the interest of IaC blueprints grow in size and maintenance costs [8], (2) practitioners and academics alike, given the relative scarcity of what is the automatic support available — that is, pros and supporting patterns, best practices, tools, and software engineer- cons of using existing tools in practice, and (3) the challenges ing techniques. Using the data coming from 44 semi-structured reported by the practitioners via direct experience — that is, interviews in as many companies, in this paper we shed light the research and industrial avenues that practitioners perceive on the state of the practice in the adoption of IaC and the key software engineering challenges in the field. Particularly, as worthy of investigation in the near future. we investigate (i) how practitioners adopt and develop IaC, (ii) Data on the above points reveals a number of results as well which support is currently available, i.e., the typically used as valuable avenues for further work.
  • INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, Phd and Douglas Reynolds December 2018

    INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, Phd and Douglas Reynolds December 2018

    INFRASTRUCTURE AS CODE–FINAL REPORT John Klein, PhD and Douglas Reynolds December 2018 1 Introduction This report concludes work on Research Project 6-18 518 Feasibility of Infrastructure as Code, summarizing the problem addressed by the research, the research solution approach, and results. 1.1 Background 1.1.1 What Is Infrastructure as Code? Infrastructure as code (IaC) is a set of practices that use “code (rather than manual commands) for setting up (virtual) machines and networks, installing packages, and configuring the environment for the application of interest” [3]. The infrastructure managed by this code includes both physical equipment (“bare metal”) and virtual machines, containers, and software-defined networks. This code should be developed and managed using the same processes as any other software; for example, it should be designed, tested, and stored in a version-controlled repository. Although information technology (IT) system operators have long employed automation through ad hoc scripting of tasks, IaC technology and practices emerged with the introduction of cloud computing, and particularly infrastructure-as-a-service (IaaS) technology. In an IaaS-based envi- ronment, all computation, storage, and network resources are virtualized and must be allocated and configured using application programming interfaces (APIs). While cloud service providers furnish management consoles that layer an interactive application on top of the APIs, it is not practical to use a management console to create a system with more than a couple of nodes. For example, creating a new virtual machine (VM) using the Amazon Web Services management console requires stepping through at least five web forms and filling in 25 or more fields.
  • Adopting 'Infrastructure As Code' Misha Zynovyev (GSI)

    Adopting 'Infrastructure As Code' Misha Zynovyev (GSI)

    Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) adopting 'infrastructure as code' to run HEP applications Misha Zynovyev ([email protected]) Dennis Klein ([email protected]) Victor Penso ([email protected]) HEPiX Spring 2011 GSI, Darmstadt, 5th of May 2011 Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) acknowledgements Dr. Peter Malzacher Bastian Neuburger Christopher Huhn Dr. Stefan Haller Helge Brust Oliver Wirth Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) outline of the talk our mission statement current approaches to infrastructure management our approach to running HEP applications describing infrastructure with code our playgrounds results outlook Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) clarification target audience: developers, system administrators and infrastructure providers you accept the benefits of virtualization presented concepts are transparent to users1 this is not about how to build the Infrastructure-as-a-Service (IaaS) clouds, but about efficient ways to use them 1nevertheless users can have as much control of details as they can cope with Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) our mission statement we want to simplify deployment and operation of scientific computing applications and their infrastructure by describing everything in code furthermore, we need a mechanism which will allow us to use external resources provided by IaaS clouds in a transparent way Adopting 'Infrastructure as Code' Misha Zynovyev (GSI) deploying infrastructure manual (with OS tools, text-editor):
  • Magic Quadrant for Application Release Automation

    Magic Quadrant for Application Release Automation

    Magic Quadrant for Application Release Automation Published: 27 September 2017 ID: G00315074 Analyst(s): Colin Fletcher, Laurie F. Wurster The ARA market is rapidly evolving in response to growing enterprise requirements to both scale DevOps initiatives and improve release management agility across multiple cultures, processes and generations of technology. This research helps I&O leaders make better-informed decisions. Strategic Planning Assumption By 2020, 50% of global enterprises will have implemented at least one application release automation solution, up from less than 15% today. Market Definition/Description Application release automation (ARA) tools provide a combination of automation, environment modeling and release coordination capabilities to simultaneously improve the quality and the velocity of application releases. ARA tools enable best practices in moving application-related artifacts, applications, configurations and even data together across the application life cycle process. These tools are a key part of enabling the DevOps goal of achieving continuous delivery with large numbers of rapid, small releases. Approximately seven years old, the ARA solution market reached an estimated $228.2 million in 2016, up 31.4% from $173.6 million in 2015. The market is continues to be expected to grow at an estimated 20% compound annual growth rate (CAGR) through 2020. Magic Quadrant Figure 1. Magic Quadrant for Application Release Automation Source: Gartner (September 2017) Vendor Strengths and Cautions Arcad Software Founded in 1992, Arcad Software is a privately held company headquartered in Chavanod, France. The company was started by its founder to deliver automation-oriented solutions supporting the Page 2 of 28 Gartner, Inc. | G00315074 IBM i (introduced as AS/400, then later renamed eServer iSeries) platform.
  • Ebook Devops Toolchain.Pdf

    Ebook Devops Toolchain.Pdf

    DevOps Toolchain 1 Introduction accordingly based on the problem at hand. DevOps may need little introduction these days, Similarly, most systems administrators possess but many are still at a loss to explain precisely competent programming abilities for traversing what the movement entails. Some emphasize the the stack—on top of the requisite skills for portmanteau of the two terms, stating that the managing IT operations. The industry has heart of DevOps is the collaboration between been quick in attaching new labels to these developers and operations staff. Others choose emerging hybrid roles: DevOps Engineer and to focus on the tools and the problems they solve, DevOps Specialist being the most common. singing the praises of DevOps for fixing their Notwithstanding, the key takeaway is that no respective infrastructure woes. Tools—though single IT skill is more important or valuable than crucial enablers of the movement—only form part another; subsequently, many different tools are of the equation. DevOps encompasses cultural required to do the job effectively. So as DevOps innovation, a breaking down of walls and silos is comprised of a group of concepts clustered between software development, operations, around the premise of continuous software and QA/ testing—in addition to the tools and delivery, these concepts in turn encompass a methodologies enabling this transformation. range of associated tools for fulfilling particular Ultimately, the definition of DevOps varies per functions. organization. Since its meaning depends heavily on the audience and context in question, general All in all, these complementary tools fill out the discussions around the true definition of DevOps DevOps toolchain, unifying the best elements are for the most part inconsequential.
  • CV - Russell Dunphy Russell@Russelldunphy.Com | 07849465404 |

    CV - Russell Dunphy [email protected] | 07849465404 |

    CV - Russell Dunphy [email protected] | 07849465404 | https://www.linkedin.com/in/rsslldnphy/ An experienced software developer, technical leader, and manager, with a love of functional ​ ​ ​ ​ ​ ​ ​ programming and coding as language. Came to programming by a somewhat unusual route: ​ ​ ​ a first class degree in Creative Writing. I see people, teams, code, and infrastructure as an interconnected ecosystem, and enjoy ​ ​ tending that ecosystem by sitting at the intersection of them all: doing people management, process optimisation, architecture, and coding as and when needed. I also enjoy developing long-term technical strategy, taking into account how this ecosystem fits into the wider business ​ ​ context, and finding sustainable, iterative ways to implement it. I’ve managed teams ranging in size from two to twelve, including developers, data scientists, scrum masters and testers. I’ve worked with a number of languages, most recently Clojure, ​ ​ Clojurescript, and Javascript/Typescript, and love learning more. I’m happy wrangling ​ ​ ​ ​ ​ infrastructure, doing backend work, or building frontend features. Most of all I like finding ways to make these different levels of the stack, and the people who work on them, form a cohesive whole. Employment Head of Engineering - HealthUnlocked Jun 2016 - Present ​ HealthUnlocked is social network for health, with around 3-4 million unique sessions per month. As Head of Engineering I am responsible for managing the tech team; for recruitment; for setting technical strategy for the organisation;
  • Continuous Delivery for Every Team

    Continuous Delivery for Every Team

    Continuous Delivery for Every Team Six ways CA Continuous Delivery Director can help you become a modern software factory Keeping up with customer demand—and getting ahead of the competition—means you must continuously deliver high-quality apps and experiences. In the modern software factory, you’ll find: Application releases are occurring at increased volumes, with greater frequency and speed.1 33% Release daily or “Cloud First” is Microservice more frequently 66% becoming a global architectures and 33% priority. container-based apps In 15 months, 80 percent are the new norm. Release weekly of all IT budgets will be 83 percent of organizations committed to cloud apps are actively using containers 2 and solutions. today.3 1 CA Technologies DevOps Research, prepared by Spiceworks, February 2017 2 Forbes, “2017 State of Cloud Adoption and Security,” April 2017 3 Ibid 02 But how do you become a modern software factory when you’re still facing challenges like: • Manual Processes: Manual, ad hoc release and testing processes do not scale in a multi-app, multi-release pipeline. And increased deployment frequency and speed through automation exacerbate the issue. • Testing Bottlenecks: Testing is critical, but a siloed, time- consuming and manual part of the release cycle. In fact, 66 percent still use Microsoft Excel®, Microsoft Word® and email to track testing.4 • Evolving Tech: DevOps toolchains and technologies are constantly evolving, putting pressure on teams to balance new capabilities with existing investments. • Limited Visibility: The proliferation of moving parts requires that you establish a big picture view of the pipeline to continuously improve the speed and quality of releases.
  • Software Engineering Using Devops - a Silver Bullet?

    Software Engineering Using Devops - a Silver Bullet?

    UPTEC IT 19 002 Examensarbete 30 hp Januari 2019 Software Engineering using DevOps - a Silver Bullet? Mikaela Eriksson Institutionen för informationsteknologi Department of Information Technology Abstract Software Engineering using DevOps - a Silver Bullet? Mikaela Eriksson Teknisk- naturvetenskaplig fakultet UTH-enheten Today we have technology that help us scan millions of medical databases in a glimpse of an eye and self-driving cars that are outperforming humans at driving. Besöksadress: Technology is developing so fast that new updates in the technology world are Ångströmlaboratoriet Lägerhyddsvägen 1 commonplace to us and we are more often frustrated in case something is not up Hus 4, Plan 0 to speed. Technology is moving so quickly and in order for humans to keep up with the development needed in the tech business, different methodologies for how to Postadress: optimise the development process have been applied, some that work better than Box 536 751 21 Uppsala others. But just as fast as the technology changes, the methodologies used change with them. Recently a new term has entered the methodologies field. This Telefon: term is said to bring faster deployment, decreased failures and improved the 018 – 471 30 03 loyalties within the teams. The term in question, is called DevOps. Telefax: 018 – 471 30 00 This study is about uncovering the world of DevOps. This thesis is exploring the term in real teams in order to find out whether or not DevOps is the silver bullet it Hemsida: makes out to be. The study is based on ten interviews with people at different http://www.teknat.uu.se/student organisations, using DevOps, and will find out how these interviewees use and feel about DevOps.
  • Gartner Magic Quadrant for Enterprise Agile Planning Tools, April 2019

    Gartner Magic Quadrant for Enterprise Agile Planning Tools, April 2019

    13/09/2019 Gartner Reprint Licensed for Distribution Magic Quadrant for Enterprise Agile Planning Tools Published 18 April 2019 - ID G00361074 - 40 min read By Analysts Keith Mann, Mike West, Thomas Murphy, Nathan Wilson As organizations mature their enterprise-scale agile capabilities, established vendors refine their offerings and new providers emerge. This Magic Quadrant evaluates 17 vendors of enterprise agile planning tools to help you make the right choice for your organization. Market Definition/Description This document was revised on 26 April 2019. The document you are viewing is the corrected version. For more information, see the Corrections (http://www.gartner.com/technology/about/policies/current_corrections.jsp) page on gartner.com. Enterprise agile planning (EAP) tools help organizations make use of agile practices at scale to achieve enterprise-class agile development. This is achieved by supporting practices that are business-outcome-driven, customer-centric, collaborative and cooperative, in conjunction with continual stakeholder feedback. These tools represent an evolution from project-centric agile tools and traditional application development life cycle management (ADLM) tools. The majority of products in the EAP tool market play into the overall ADLM product set, acting as hubs for the definition and management of work item tracking. There is a relationship between EAP tools, project portfolio management (PPM) tools and product roadmapping tools. Traditional PPM tools provide the high-level planning and resource management enterprises demand, but may lack enterprise-class agile development support. EAP tools, for their part, may not support project management outside agile frameworks. (Gartner has a separate Magic Quadrant for PPM, the latest being “Magic Quadrant for Project Portfolio Management, Worldwide”).
  • The Practical Blueprint to Continuous Delivery Executive Summary

    The Practical Blueprint to Continuous Delivery Executive Summary

    The Practical Blueprint to Continuous Delivery Executive Summary CA Technologies, A Broadcom Company, proposes a four-stage blueprint to continuous delivery to assist enterprises at any stage of their DevOps journey. This plan can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic® Continuous Delivery Automation, 40-plus years of business automation experience, and the proven tools and practices the company is already leveraging. As the only vendor that automates within the toolchain (steps one and two) and across the toolchain (steps three and four), CA Technologies is in a unique position to help enterprises at every stage of their progression. Our tool-agnostic, cross-platform and multi- stack technology means developers can continue using the tools they are most comfortable with, while DevOps teams can collaboratively build automated, production-ready deployment processes that make operations comfortable. CA Technologies offers a DevOps Maturity Assessment that shows on which of the four steps an organization sits, and compares its current state with that of its competitors, its industry and its competition globally. Using the assessment findings will give companies a blueprint to guide them up to the next level on the road to enterprise agility as quickly and safely as possible. 2 Step 1: Manual and Scripting Participation in our DevOps Maturity Assessment will deliver a continuous delivery roadmap that contains a blueprint for DevOps throughout the enterprise. Customers will be able to compare their current state with their competitors, their industry and globally. Manual steps will be identified and documented, then replaced with automated tasks and workflows.