devopsy.kinsta.cloud

Tag: agile

  • Gene Kim, DOES17 Speakers Discuss the Deployment Age

    Gene Kim, DOES17 Speakers Discuss the Deployment Age

    In a special episode of Electric Cloud’s Continuous Discussions (#c9d9), Gene Kim and speakers from the upcoming DevOps Enterprise Summit San Francisco (DOES17) discussed the deployment age, and how DevOps practices and automation can unburden teams and boost productivity.

    The panel included: Mik Kersten, CEO of Tasktop; Robin Yeman, fellow at Lockheed Martin; Courtney Kissler, VP of digital platform engineering at Nike; and, our very own Sam Fell and Anders Wallgren.
    Continue reading for some of their top takeaways:

    Kersten discusses the importance of spreading the word about DevOps tooling: “I think the best thing we can do is accelerate this turning point by giving the rest of those 15 million developers working in all of those other companies the tools that they need to apply these technical practice and to reorient their organizations to actually leverage them.”

    Yeman on the multiplier effect of automation: “DevOps is definitely all about the people, but the automation enables people to have such a higher outcome and better business results. It’s almost like a force multiplier for companies.”

    It’s crucial to look at the bigger picture of software delivery, advises Wallgren: “If you don’t have a big picture of what your value stream is from one end to the other, it’s hard to convince people that the problem they’re looking at is in fact not the right problem to be focusing on, or whether that is the right or wrong problem.”

    Organizations that employ transformational leaders succeed, claims Kim: “We see people driving DevOps transformations in large complex organizations, specifically the DevOps enterprise community, and my claim would be that these people are being promoted at a rate far higher than the population at large. My interpretation of this is that the value that’s being created by these leaders is appreciated and they’re being put into roles where they’re being asked to make an even greater contribution across even a broader portion of the organization.”

    You can’t just optimize for cost and efficiency anymore, explains Kissler: “There’s this realization that we’re all shipping software and really embracing that and understanding that organizations that have typically optimized for cost and efficiency are not going to win. And so, optimizing for speed to value, the value stream is a huge shift as well.”

    Yeman explains the awesome leadership structure at Lockheed Martin: “At Lockheed, most business leaders were engineers at one point in time. So, if you’re looking at the President or the Vice President, they started out in software, or systems, or as a tester. They have to have depth in their area because then they can really empathize with what we’re building and with, you know, the people that are building it.”

    More on the wonders of automation, per Kersten: “Agile has scaled up, but it kind of hit a brick wall until automation came into play and organizations realized that they needed reliable, predictable, and safe ways to deploy. I think one of the most interesting things that happened when the technical practice matured around that automation layer is all of the other gaps it uncovered.”

    Wallgren on the ironic manual nature of the software delivery industry: “I think that one of the paradoxes of what we do in software teams is we don’t use software at all, most of the time, to help us produce our own software. We use people.”

    Kim reflects on revelations after reading “Disrupt or Die” by Jedediah Yueh: “The real value that DevOps will create is not going to be in the FAANGs, the Facebook’s, Amazon’s, Apple’s, Netflix’s, and Google’s of the world, but it really is in the large brands in every industry vertical as they either disrupt, get digitally disrupted, or digitally disrupt themselves.”

    Kissler on how to respond to the exponential growth of digital disruption: “I think the acknowledgement of where we’re at and where we need to go and how fast we can get there is a huge component of responding to the digital disruption.”

    Watch the full episode:

    Want more Continuous Discussions (#c9d9)? We hold our #c9d9 podcast every other Tuesday at 10 a.m. Pacific. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.

    Check out all past episodes and panelists here.

    About the Author / Anders Wallgren

    Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.

  • How to Succeed with DevOps by Outsourcing Software Development

    How to Succeed with DevOps by Outsourcing Software Development

    The DevOps journey can be successful when you use offshore outsourcing software partners, but it requires careful attention from your IT leaders.

    The old saying, “The only constant is change,” has never been more true for software development, whether your company is a SaaS provider or a manufacturer of discrete products that rely heavily on software delivered by your IT department. For the past several years we have seen four key movements:

    1. The continued adoption of outsourced software development. As far back as 2013, it was reported that 2 out of 5 CIOs surveyed planned some sort of outsourced software development for the coming year.
    2. Increased outsourcing options. While outsourcing to India is still a legitimate option today, it’s certainly not the only viable option available. Companies are now able to answer the question: “What country will provide my outsourced programming team?” in multiple ways.
    3. Agile as a mainstream methodology. Software development teams continue to embrace Agile as the preferred methodology for software development projects.   
    4. Interest in—or adoption of—DevOps. Since the term “DevOps” was introduced by Andrew Shafer and Patrick Debois at the 2008 Agile conference in Toronto, large and small companies alike have shown increased interest in embracing DevOps and the promise it holds for rapid software deployment.

    The current state of tools and service provider capabilities should entice IT leaders to adopt (or continue to adopt) DevOps methods for software development. More than ever before, there are capable teams of programmers across the globe that you can tap into for a successful software.

    There is No Substitute for Good Process

    The goals of higher output and greater efficiencies and even “continuous deployment” through DevOps have their roots in elite manufacturing methods such as kanban and lean manufacturing. Like its manufacturing method cousins, DevOps success hinges on good process. To see improvements through the use of DevOps, you must have clear understanding (and description of) your current software development process. You need to communicate your processes clearly in words and pictures with your outsourcing partner. Issues that are birthed out of shortcomings in your DevOps process will be exponential when you add the variable of outsourced development into your work steps.

    Key Takeaway: DevOps is only possible through good process. If you’re not committed to good analysis and continual improvement of your processes, then the use of an outsourced software developer will only allow you to create flawed software and generate chaos more rapidly.

    Tools Create Speed

    If good process is the engine of DevOps, then automation tools are the gasoline that makes the well-designed process run with speed. Automation of good process makes it possible to eliminate bottlenecks in the software development cycle—you can truly “sprint through your sprints.” Perform an inventory of your tools:

    • Are you able to seamlessly (and automatically) promote code?
    • Can you perform test-driven design?
    • Can you perform test-driven development?
    • Can you easily associate features and fixes with promoted code?
    • How do you perform regression testing?

    Key Takeaway: Automation tools must be used with consistency by you and your outsourcing partner. These tools will enable the process that you all follow daily in the development activities of your project.

    Choose Wisely

    Having the right outsourcing partner for software development is important. To outsource successfully in a DevOps approach, you must be very selective in your choice of an outsourced software development team.

    • The best partners employ a programming staff that have achieved the major certifications that are important for your DevOps project needs. Moreover, a good partner invests in its programming staff’s training on a continual basis. We like to see evidence that its programming staff regularly renews their certifications.
    • Experience. Equally important is having a software outsourcing team with demonstrated experience in your business vertical (example: discrete manufacturing, banking, etc.) and expertise in the system functional area (e.g. finance, e-business order processing, warehouse management, etc.). Of course, the software development team also should be versant and have demonstrable experience in the use of Agile and DevOps techniques.
    • The right partner should be neither too large nor too small. The outsourcing company needs a pool of programmers large enough to keep with the intended work pace of your project. Conversely, we caution IT managers to be wary of extremely large outsourcing companies. Your project and company must be “big enough to matter” to the partner you select. If you are seen as too small in terms of the revenue opportunity, the outsourcing company will defer attention and its top talent to larger customers, who are more able to influence decision-making.

    Key Takeaway: To succeed with DevOps outsourcing, you need the right partner, based on attributes of skills, demonstrable experience, and a size that’s proper for your company.

    Metrics Matter

    John Adams, the second U.S. president, once famously said, “Facts are stubborn things.” DevOps presumes a culture of continuous improvement—and our metrics help demonstrate that improvement. We collect metrics so we can accurately measure pace of work, quality of software produced, level of effort and so on. We measure events over time to see if we are improving, worsening or stagnant. Metrics are a critical means of communication and mutual accountability between your company staff (IT and business) and the outsourcing partner who is writing your software. In a DevOps-driven outsourcing relationship, you’ll regularly capture and report on metrics (estimated and actual) such as:

    • Lead Time: In software development, you need to measure the time elapsed from concept to the point delivery of the completed software. From project to project or even epic to epic, you want to see an increase in speed to deliver software.
    • Sprint Time: Teams using Agile will have sprints measured in a few days, instead of months, for the typical time for work grouped in “phases” or “activities,” using traditional development methods. Be sure to track metrics for your sprints.
    • Sprint Volume: How many sprints are needed to complete a story? How many sprints are needed for a version? For each of these metrics, look for consistent volume (i.e. number of sprints produced) over time.
    • Issues and Open/Close Rates: Measure how many production issues are reported AND closed within a specific time frame. Observe and take action on trends rather than establishing a hard and fast number; there’s no “right answer.”

    Key Takeaway: Metrics allow you and your outsourcing partner to objectively assess the pace and quality of rapid work being performed in a DevOps/Agile-driven development project.

    Collaboration is Key

    It almost goes without saying that you and your outsourcing partner will need to have good, regular rhythms of communication. This continuous collaboration is essential because you and your vendor-partner team are:

    • Operating in a common disciplined way using DevOps methods.
    • Performing work through a common set of tools.
    • Progressing through the project goals in a series of rapid sprints.
    • Capturing and analyzing team metrics to ensure project health.

    Honestly assess what barriers might exist to good collaboration. Do you need to ramp up your real-time collaboration tools? Do you have a master calendar of formal meetings where the agenda will drive good information-sharing, decision-making and issue resolution?

    Are time zone differences an issue? This may affect the geographic location from which you will select your outsourced development team. In a recent survey, one-third of U.S. companies that outsourced to India considered the 10-hour (or more) time difference to be a big challenge. Very often the “core team” in an outsourcing software provider will be working hours that are completely opposite of normal U.S. business hours. Some companies find that a “nearshore” outsourcing partner helps optimize collaboration. Because the outsourcing partner is in the same time zone as your IT leadership team, it’s easier to schedule meetings or even have impromptu discussions, which are so important in software-development methodologies such as Agile.

    Key Takeaway: DevOps and Agile require high collaboration. Set yourself up for success by ensuring there will be no reasonable impediments to good collaboration.

    A Perfect Storm – and Opportunity

    The recent evolution in best thinking and adoption of DevOps, and the parallel growth in options for software development outsourcing together create a kind of perfect storm in software development. The potential of DevOps is augmented by the inherent continuous-change nature of Agile. We see the ability to transfer work across the “virtual shop floor” of development without geographic constraints. This new programming paradigm of DevOps, partnered with Agile, is now matched by equally exciting (and relevant) growth in the options for delivering high-quality code from anywhere across the globe.

    About the Author / Steve Mezak

    Steve Mezak is founder and CEO of Accelerance, a leader in global software development outsourcing, as well as the author of “Software Without Borders,” co-author of, “Outsource or Else: How a VP of Software Saved His Company,” and a CIO columnist.

     

  • DevOps in the Age of Digital Transformation

    DevOps in the Age of Digital Transformation

    Digital transformation is one of the hottest buzzwords in the technology industry today. While it tends to be overused, the term does represent a widespread, ongoing movement that will set a standard for the next generation of enterprises.

    Digital transformation is all about keeping up with the pace of innovation and using technology to achieve business goals. A key differentiator in the age of digital transformation is customer experience. Consumers are increasingly engaging with brands on digital platforms, whether it be a website, social media profile or mobile app. The foundation of all these platforms is, of course, software.

    Agile software delivery is key because it helps organizations innovate faster and gets new software in the hands of consumers sooner. This requires new, more productive ways of working for enterprise IT teams. Development teams have already undergone several “transformations” in recent years, from the siloed waterfall approach to agile methodology and now DevOps. Software is the true differentiator in the age of digital transformation, and many companies are using DevOps to ensure their software meets the standard.

    Here are a few best practices for using DevOps to keep up with the pace of digital transformation:

    • Automate wherever possible. We no longer collect the work of multiple engineers over multiple sprints into a release. To out-innovate the competition in the digital transformation era, a team must release the work of a single engineer as soon as it is ready. This is usually accomplished through a CI/CD pipeline directly from the source repository through automated testing and then deployment into production, preferably without any human intervention. Choosing the right tools for your IT environment will cut costs, time and room for error.
    • Align the goals of development and security. DevOps isn’t limited to just the development and operations teams. Without security, all progress made in the digital transformation era is at risk to cybercriminals. The accelerating software development life cycle means little time for security analysis or penetration testing when the release candidate is ready to deploy. To ensure a piece of software is secure before pushing it to market, security standards must be included in the definition of “done.” Preventative scanning will not only train developers to write secure code, but will allow the software to pass the assurance tests included in any good CI/CD pipeline.
    • Measure ROI. Measuring the impact of DevOps can be extremely difficult and up to interpretation because of the focus on culture and processes. However, it’s important for DevOps teams to gain continued executive buy-in and dedicated resources by proving their value. The value of DevOps is determined in terms of achieving improved business outcomes. There are specific questions to ask to help determine ROI: How long does it take to release a code change? How long does it take for a product to reach a customer’s hands? The ability to continually deliver quality software faster results in a positive customer experience, ultimately improving brand reputation and revenue.

    While keeping up with the competition is necessary in the digital transformation era, putting customer experience first is how the true leaders succeed. By shortening the software development cycle, DevOps speeds the pace of innovation for an organization and helps earn customer trust and retention. Implementing these best practices can help a business use DevOps to place software and customer engagement at the heart of its digital transformation.

    — Pete Chestna

  • The 7C Holistic Approach to DevOps

    The 7C Holistic Approach to DevOps

    The DevOps methodology was first adopted in 2007 with a bigger purpose of improving organizational efficiency by bridging the gap between software release and IT operations teams. This started as the core practice of continuous integration (CI) and continuous delivery (CD) with a prime focus on better quality of releases and more frequent releases. Now, DevOps is becoming the norm of the industry and is being embraced by multiple organizations as a digital transformation with a shared goal, involving all stakeholders, to serve the customers better with higher quality product release and more frequent releases.

    DevOps has evolved beyond release and deploy and now involves product owners, project managers and all aspects of software development life cycle. This is the key reason it has evolved as a holistic approach starting from the service team interacting with the customers to product release and production monitoring. In this blog, we will explain how the 7C approach of DevOps is a natural evolution of DevOps and how it helps different organizations to perform better.

    DevOps now spans across the entire organization involving customer service, marketing, product owners, project managers, program managers, and different levels of developers, QA, release or build teams and infrastructure team. As the main focus of DevOps is to serve the customer better and faster, it is important that all the stakeholders have better end-to-end visibility of operations, planning, integration, testing, monitoring, delivery and feedback. This is the 7C approach of DevOps, as illustrated in Fig 1. This requires an efficient integration of processes and tools to automate the seamless information exchange and execution. This approach also empowers all the stakeholders to better contribute in product’s success and efficient execution.

    Fig. 1: 7Cs of DevOps

    The 7C holistic approach to DevOps also requires efficient collaboration between all stakeholders, empowering them to contribute more. The 7C approach removes all silos of information and execution.

    Startups were fast to adopt DevOps as many of them were setting up things from scratch. But the latest industry trends show large enterprises embracing DevOps primarily with the focus on efficiency and better, more frequent releases.

    The DevOps domain includes lots of tools and many of them are open source. This has provided a toolset for engineers to tinker with or experiment. This tends to have problem of its own, as too many toolsets in the flow create silos of information and execution, which creates confusion and inefficiency. This is becoming a problem and that’s why solutions are required which provide better integration and execution across multiple tools. The right solution for this will be a platform with deep integration capabilities.

    A deep integration platform for DevOps will enable seamless integration and execution across different tools, even home-grown proprietary tools, to provide a holistic solution starting from customer initiation to production deployment and feedback. This approach is significantly important for large enterprises, as this enables them to have the flexibility of preserving their existing investments on tools and processes while also allowing them to selectively introduce new tools. Rather than trying everything new, large enterprises can manage changes while primarily focusing on efficiency, automation, collaboration, better quality of releases and more frequent releases.

    This 7C approach gives same visibility to all stakeholders and everyone knows what feature is being released when. This approach also helps to move information/execution in both left and right direction with powerful traceability features, analytics and dashboards. Deep integration of information and execution also reduces dependency on other teams and promotes self-service.

    Fig. 2 illustrates a sample DevOps flow where service team uses ServiceNow; software, product and project managers are using Jira for Agile management, developers are using Eclipse as their integrated development environment, GitHub is used for source code repository, QA team uses a test management tool for test and defect management, and finally the release team uses Chef and Jenkins to orchestrate build, release and deployment. In real-world examples, teams add more tools for code analysis, security and production monitoring. All such complex flows are supported within DevOps 7C holistic approach by utilizing the deep integration platform. The 7C approach is more productive as it allows faster detection, analysis and resolution of problems.

    Fig 2. Sample DevOps Flow with Deep Integration

    The 7C approach works well with both traditional waterfall software management as well as Agile software management—mainly because of better end-to-end visibility, efficiency and collaboration.

    To conclude, 7C approach of DevOps is the natural evolution of DevOps, empowering the team to achieve better efficiency and execute better. This empowers all the stakeholders in the organization by providing better end-to-end visibility and powerful means of collaboration. Involving all stakeholders also creates a better environment of trust and collaboration. With this 7C approach, DevOps is not limited to build and release but it has spanned across the entire spectrum of software development lifecycle. This is especially highly beneficial for large enterprises as it enables them to preserve their prior investments and enhance their existing flows. This gives them leverage to selectively try new tools and technology while preserving what is working well. This is a great approach to expedite the enterprise level digital transformation.

    About the Author / Devendra Joshi

    Devendra Joshi is Sr. Director, Customer Solutions and Products at Kovair. He is a software professional with over 20 years of experience in enterprise software, social media, healthcare, SaaS companies, and EDA. He has worked with startups and large enterprises in engineering management, and product and solutions management roles.

  • Break the Rules and Win at Digital Transformation

    Break the Rules and Win at Digital Transformation

    The rules of the game have changed.

    In today’s digital world, it’s not about the big eating the small. It’s the fast that beat the slow and the nimble that outmaneuver companies constrained by old systems and business models.

    What’s more, the finish line is always moving. The rapid pace of innovation and disruption means businesses must continuously transform themselves to stay ahead of competitors.

    The takeaway for CIOs: Speed and agility are the name of the game.

    IT must respond faster than ever to shifting business needs. To succeed at digital transformation, companies must rethink how they design, build, deploy and source enterprise applications. They must adopt new approaches that accelerate delivery and anticipate, even bake in, ongoing changes.

    It’s time to update the IT playbook. Here are five best practices from digital leaders that are breaking with the past to deliver a successful future.

    Accelerate and Iterate Software Delivery

    Digital leaders outpace their rivals by adopting methodologies and mindsets that shorten software delivery cycles. They’re also really, really good at rapid, iterative change.

    Shift to Speedier Methodologies

    Digital leaders rely on Agile development methods—short sprints, scrum teams and user feedback loops—to accelerate the design and development of new applications. With its emphasis on rapid iteration and continuous improvement, Agile methodologies are a proven way for companies to churn out new innovations quickly. Studies show Agile approaches average 50 percent faster time-to-market than waterfall ones.

    DevOps is also a catalyst for speed. Automation and tighter collaboration between development and operations make it easier to put new code into production. Led by such companies as Facebook, Google and Amazon, the world is moving away from “that 10-year-old solution everyone’s afraid to touch” to flexible platforms that are updated multiple times a day.

    Adopt an Agile Mindset

    Of course, being agile requires more than just new methodologies. It also demands a willingness to take risks, learn on the fly and adjust continuously. Digital leaders don’t just respond to change; they embrace and design for change.

    Digital leaders test and then invest. They fail fast and then swiftly course-correct. The most successful experiment rapidly and incrementally so if they do stumble, they fall from the first floor, not the 10th. Digital leaders also think big. They don’t just digitize current processes. They completely re-imagine business models and technology systems—as Pitney Bowes did with its transformation into a digital commerce powerhouse or as GE did with its launch of the Predix industrial IoT platform.

    Adopt New Application Architectures and Infrastructure

    Digital leaders are building in flexibility with new application architectures and deployment models. They’re leaving legacy systems behind as they take to the cloud with microservices-based solutions.

    Move to Microservices

    Monolithic applications are hard to change, costly to maintain and ill-suited to today’s dynamic business environment. That’s why digital leaders are moving to an agile, microservices-driven architecture. Converts include Netflix, eBay, Amazon, Twitter, Gilt, Liberty Mutual and the UK Government Digital Service, to name just a few.

    Assembling applications from small modular services—each a self-contained building block—allows digital leaders to transform quickly and at scale. They can mix and match services to fast-track new digital offerings and processes. They can tweak and scale services to adapt to changing business models and customer expectations. And they can push innovation across the enterprise by reusing services—all without adding armies of developers or getting locked into any one technology.

    Step Up Cloud Migration

    The cloud is increasingly the preferred foundation for digital transformation. Digital leaders gain speed and agility by plugging into on-demand services and computing resources. They short-circuit long design and procurement cycles; focus on innovation, not infrastructure; and deliver differentiated capabilities and customer experiences at a fraction of the time and cost.

    Digital leaders are betting big on the cloud. According to IDC, at least half of IT spending will be cloud-based by 2018, reaching 60 percent of IT infrastructure spending and 60 percent to 70 percent of software, services and technology spending by 2020. Organizations across industries—such as Nike, Xerox, General Mills, Liberty Mutual, and the U.S. federal government—have migrated mission-critical workloads to the cloud to support new, more digital ways of doing business.

    Use Novel, Unexpected Sources of Innovation

    Digital leaders rely on open-source innovators and third-party collaborators to shorten development cycles. They’ve also abandoned long RFPs in favor of shorter, more effective proofs of concept (POCs).

    Embrace Open Tech with Open Arms

    Open technologies—including open source, open standards and open APIs—dominate the digital landscape. According to a study by North Bridge and Black Duck, open source software makes up more than 50 percent of the typical enterprise and application stack. Digital leaders including Ticketmaster, Box, eBay and Goldman Sachs rely on open-source software to speed solution delivery and draft off the innovations of millions of developers worldwide.

    Digital leaders also innovate openly with others. They hold hackathons. They crowdsource. They co-create with customers and partners. They also contribute back to the community with projects such as Walmart Labs, Ericsson’s open-source hub and GE’s Industrial Dojo for the Cloud Foundry ecosystem.

    Say RIP to RFPs

    Digital leaders have pulled the plug on massive RFPs for complex, multiyear development projects. Instead, they favor faster, more flexible procurement processes that reward innovation and accelerate vendor selection. They conduct POC tests to evaluate alternative technologies. They use iterative prototyping to refine requirements and determine the best solution for the job. They keep their options open with shorter timelines and smaller deliverables.

    Digital success calls for a more collaborative relationship with technology providers. It’s the whiteboard sessions, technical conversations and joint problem-solving that yield breakthrough results. That’s why progressive companies now approach the RFP like a “request for partnership.”

    Integrate Data and Systems in Transformative Ways

    Digital leaders use open platforms and APIs to integrate information, people and processes across their extended value chain. These connections lay the foundation for faster business flows and new digital products and services.

    Connect Quickly with APIs

    APIs (application programming interfaces) enable diverse applications to connect and share data. Digital leaders use API-led integration to combine services and expose information in ways that deliver unprecedented customer and business value. Within days and without lots of coding, they can roll out service innovations, revamp internal processes, enliven customer interactions, extend their digital reach and enable entirely new business models.

    This year, 2017, has been dubbed the year of the API economy. ProgrammableWeb lists more than 17,700 APIs and hundreds of digital leaders are opening up their APIs so others can easily integrate and innovate with their technologies. API marketplaces from Mastercard, ADP, Ford and FedEx are just a few examples.

    Achieve Digital Flow

    Silos slow the flow of business. Disconnected processes, departmental barriers and gaps in information all impede speed and agility.

    Digital leaders excel at silo-busting. They integrate disparate systems. They connect processes from end to end, across all customer touchpoints and organizational boundaries. They use open platforms to ensure that information—structured data and unstructured content—flows to the right person, at the right time, in the right context.

    The seamless integration of information, people and processes allows digital leaders to be much more nimble and responsive. They can also leverage these connections to make huge improvements in customer experience—such as the bank that slashed loan origination steps by 70 percent or the insurer that processes claims 25 percent faster.

    Bring Business and IT Closer Together

    Digital leaders treat digital transformation as a partnership between business and IT, with a shared focus on meaningful outcomes and better experiences for customers and employees.

    Engage and Empower Users

    Digital leaders put people—customers, citizens, employees and partners—at center of their transformation efforts. They prioritize design thinking, a user-centric approach that shifts the focus from adding features to adding value. They take advantage of platform tooling to involve users in solution design and invest in dedicated UX teams to deliver better experiences faster. Capital One, for instance, regularly solicits customer input at its three innovation labs. Other proponents of design thinking include Citrix, Airbnb, BMW, DHL and Procter & Gamble.

    Another winning strategy is to empower users with self-service tools that add business agility. Examples include self-service analytics for rapid decision-making and process services that make it easy for users to modify workflows as business needs change.

    Take a More Strategic Role

    Now that every company is a software company, IT is increasingly strategic to the enterprise. Successful CIOs have seized this opportunity and are making the most of it.

    Forward-thinking IT leaders have recast IT in the role of business partner and change agent for digital transformation. They look for ways to drive growth, deepen customer engagement and shorten time to market. They help colleagues understand and realize the value of digital initiatives. They build bridges and buy-in by adopting a service mindset—what one CIO calls “ego-free IT.” The new measures of success aren’t IT-specific metrics; they’re meaningful business outcomes such as dollars saved, customers added and market share gained.

    Conclusion

    Every digital transformation is different. But the underlying challenge is the same. How can IT accelerate the pace of delivery and change simultaneously? By following the lead of digital trailblazers, any organization can gain the speed and agility needed to compete in a digital-first world—and win.

    About the Author / Chris Wiborg

    Chris Wiborg is Vice President of Product Marketing at Alfresco Software. In his role, Chris is responsible for setting and executing the go-to-market strategy for Alfresco’s Digital Business Platform. Connect with him on Twitter and Linkedin.

  • Speaking for the Dead: Are ‘Agile’ and ‘Monolithic’ Actually Good?

    Speaking for the Dead: Are ‘Agile’ and ‘Monolithic’ Actually Good?

    What if Agile is the product of getting bored at work, microservices are the result of us needing a challenge and scrums are the result of an obsessive project manager? Do we all think waterfall development is a dinosaur whose extinction is deserved because of what we have been told and not because of reality? Do we think Agile is better because it simply sounds desirable?

    Michael DeHann (@laserllama), creator of Ansible, spoke at the 2016 All Day DevOps conference, which espouses the benefits of DevOps, and, by association, Agile and microservices. It essentially says, “Let’s step back and evaluate the past. Maybe waterfall development and monolithic architectures are actually a good thing?”

    Michael has been a software engineer and created a key tool in the IT automation toolbox: Ansible. His arguments deserve a look, because re-evaluation can keep you from making mistakes and improve processes going forward.

    Michael started his talk by making the point that in this day and age, it is waterfall versus Agile and monolithic architecture versus microservices. The assumption is that if you are still developing software with the waterfall method and/or developing monolithic applications, you might as well be riding a horse and buggy to work and dialing up coworkers on your rotary phone.

    Throughout his talk, he asked questions to make his points, beginning with, “Is big design up front bad?” with the conclusion, “I don’t think so.” His argument is that design and requirements at the beginning of the process enable a better production. Marketing and engineers hammered out requirements based on needs, abilities and budgets. There was plenty of time to research and design solutions. Both sides worked together, raising questions and comments and documenting mutual agreement. This presented an accurate view of the strengths of various team members and dependencies between tasks and task orders. And, perhaps most important, engineering was engineering—the engineers had greater responsibility and less hand-holding.

    Contrasting that with his view of Agile, big design up front is labeled as bad or counterproductive, engineers are viewed as interchangeable and scope is more unpredictable. Estimates are encouraged to not be time-based, which often results in a constant crunch time. Finally, meetings can consume a significant portion of team members’ time and often include “games reminiscent of Kindergarten, such as Fist of Five or Planning Poker.” Even in lightweight Agile systems, testing can suffer, requirements are more vague and there is no mutual sign-off.

    Michael argues that there can, in fact, be a middle ground where teams:

    • Do share design
    • Have an accessible, effective product owner
    • Know hard requirements versus soft requirements
    • See test-driven development and test automation as super important
    • Understand that Agile and iterative development can be closer than we think

    Agile and DevOps are also often associated with microservices versus monolithic applications, but according to Michael, “What’s so bad about a monolith?”

    Sample Monolithic Diagram

    dehann1.png

    Sample Microservices Diagram

    dehann2.png

    An example microservices shop has 150 services, many thousands of Jenkins builds per day, eight Amazon regions including dev, staging and production and thousands of EC2 instances. This can result in Jenkins configuration and security enforcement drifts, suboptimal code sharing and DevOps writing lots of custom code to manage it.

    Michael contrasts that with monoliths, which have:

    • Increased ability to develop on one laptop
    • Interfaces that benefit from static typing versus design-by-contract
    • Very small numbers of different server/image types in production
    • Local function calls that are much faster than RPC
    • Few instances sitting around with 5 percent utilization
    • No need for “containers” to get around above utilization problem
    • Greatly simplified debugging
    • Easy code-sharing
    • Very simple version upgrades

    Rather than argue that all applications should be monolithic, he makes the point that many of the concerns that resulted in microservices could be solved with improved communications. He contends that microservices are a tech solution to a people problem.

    Michael concludes that:

    • Labels cloud true meanings,
    • Monolithic architectures are more efficient,
    • Agile can be less efficient,
    • Microservices attempt to solve people problems but introduce new technical and people problems, and
    • We should try and separate the labels from the true meaning of things.

    Most importantly, though, is the fact that there is something to learn from everything. So, even if you don’t agree with Michael’s conclusion, you should listen to his talk online here. You might learn an unexpected lesson.

    If you missed any of the other 30-minute long presentations from 2016 All Day DevOps, they are easy to find and available free of charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online Oct. 24.

    — Derek E. Weeks

  • Don’t Let Cultural Debt Bring Down Your Business

    Don’t Let Cultural Debt Bring Down Your Business

    Businesses today are faced with myriad challenges to innovate and optimize. In doing so, we often need to make decisions that borrow against the future. This can come in a tangible form, such as taking money from investors to fund growth, or in more inconspicuous forms, such as making tradeoffs in technical decisions. When we make such tradeoffs, we expect them to come at the cost of additional technical work in the future; however, these decisions can also borrow against an externality that is often overlooked: culture.

    Technical Debt

    Technical debt occurs in the development of software when the “easy path” is taken to solve a problem rather than using the best overall solution. The concept implies that the time saved now will need to be paid back later (with interest!) in the form of rework.

    Ideally, technical debt is incurred knowingly, i.e. a decision to take a shortcut is made deliberately to increase velocity, and it is flagged to be fixed before becoming a compound problem. In calling out technical debt as such, we can better analyze our decisions, considering their net present value and future opportunity costs. By documenting it, we gain better insight into the responsiveness and flexibility of the code base. Having a strategy around managing technical debt has therefore become an essential discipline in the management of software products.

    Technical decisions also have an impact on the culture of a company, though, and this facet of technical management is often overlooked. “Cultural debt” can be taken on unknowingly, and the unmanageability that flows from it can be difficult to ascertain.

    Cultural Debt

    Cultural debt is when we make a technical decision that borrows against the culture of the organization. Such decisions can introduce divisions between teams, deteriorate communication or even weaken the effectiveness of leadership. These types of decisions need to be made regularly throughout the software development life cycle, and it is therefore critical that we begin to identify them, call them out and manage them accordingly. If the interest goes unpaid we can end up with a toxic environment that is difficult and onerous to manage—we risk a paradox wherein attempts to innovate can stifle progress.

    A Closer Look

    Just as with technical debt, a business ideally will have a strategy for managing cultural debt rather than allowing it to accumulate and bog down the business. Typically, decisions that involve cultural debt will impact on areas such as:

    1. Mission: Ensuring connection to the company mission and that there is minimal variance in how the mission is understood by different teams and departments.
    2. Values: Effective and reliable transmission of company values, the ability to apply them consistently and ensure that they are clear and tangible.
    3. Communication: Fostering openness and the ability to discuss, providing channels for communication and using channels effectively with clarity of purpose and minimal “noise.”
    4. Visibility: Providing the ability for everyone to see up, down and across their organization.
    5. Attitude: Happiness of employees, their effectiveness and retention.
    6. Leadership: Ability for leaders to govern effectively, and influence across departments

    When making technical decisions, we need to think outside the box and consider how our decisions will affect these cultural dimensions of the business.

    To reinforce the concept, let’s look at some current issues that the modern enterprise is being confronted with:

    1. Domain-Specific Tooling – As roles become increasingly specialized, a best-of-breed approach provides the tools needed to perform complex tasks. Unfortunately, tools create silos, and more tools means more fragmentation. Furthermore, in a world where tools are proxies for business processes, domain-specific tooling can cut off teams from processes, reducing visibility and impeding communication. This mean the business will need to devote cycles to meetings, emails and other noisy distractions just to pay down the interest and get the visibility and coordination needed for cross-functional effective leadership. Paying down the debt requires tool integration, and without an infrastructure to reduce the cost of integrating, domain specific tools can be a heavy debt to carry.
    2. Customization – Often we see the introduction of new tooling without the requisite investment to customize them to the business. Tools such as ServiceNow or Salesforce are highly valuable for being specialized to their use cases, but they still require customization to be effective. For example, when customer data is stored in notes fields rather than using structures data captured in the tool, visibility and reporting is gradually reduced and employee frustration abounds. The decision to introduce tooling should be made with the understanding that customization will be required and must be maintained over time to keep pace with the organization’s culture as it changes.
    3. Bimodal IT – One strategy for enabling cutting edge technologies is the use of a “bimodal” structure with essentially two IT organizations that operate under different constraints. While bimodal IT may be valuable for encouraging adoption of new technologies, it also encourages confusion of responsibilities, cross-team rivalry, knowledge silos and double work. The longer the structure remains, the deeper cultural divide and the more difficult an eventual transformation will be. The decision to introduce new technologies or practices using a bimodal structure should be done deliberately, cautiously and with clear goals in mind.
    4. Technology Selection – Often we are presented with new technologies that promise to deliver great benefits. Let’s assume that the new technology passes a technical assessment and is found to deliver on the promises: e.g. a language such as Clojure or Kotlin really will simplify development and increase velocity, or a new delivery tool does indeed remove a key bottleneck. Adopting such a technology invariably creates some cultural debt—developers unfamiliar with the new language may feel alienated, new silos will form around knowledge and expertise and tribes could be forcibly broken apart. Technology decisions that ignore cultural debt will involve more cycles and greater risk, while those that recognize it will implement new technologies with those issues in mind, providing the cross-training and collaboration needed to ensure success.
    5. DevOps – The dirty secret about DevOps is that it involves the introduction of a number of technologies and technical practices that carry a large amount of cultural debt. This can actually tear an organization apart if that debt is not managed closely, and it is therefore why DevOps—despite being closely associated with technical practices such as automation, infrastructure-as-code and CI/CD—is regarded as primarily a cultural movement. In the enterprise, DevOps technologies threaten roles, responsibilities and livelihoods. The cultural debt actually does outweigh the benefits, and DevOps transformations need to focus on cultural issues first before attempting to implement the associated technologies. This is common sense that we learned from observing lean manufacturing transformations in the nineties, which involved a similar change situation where technical practices became a function of culture.

    Cultural debt, like technical debt, can be hard to detect. If your business does not have a strategy for paying off the debt, or at least one for paying down the interest, the result will be a heavy load of cultural issues weighing down decisions and processes.

    Key Measures for Managing Cultural Debt

    • Understand your stakeholders: In an agile world it is easy to overlook stakeholders. We can learn from the disciplines of business analysis and project management, though, where stakeholder analysis is a core componency and key practice in work management. It is not possible to do a thorough breakdown of stakeholders for every technical decision, but an actively maintained stakeholder matrix will increase your mindfulness and can be referred to for a free sanity check when needed.
    • Understand your culture: Your organization is filled with cultural artifacts—if you are not aware of them and taking the time to manage them, you will not be able to assess cultural impacts. These artifacts can include mission and value statements, organizational and tribal structures, meeting cadences and compositions, control systems, routines, rituals, symbols and even legends. Think through your cultural artifacts and ensure that they match intention and are understood by leadership.
    • Obtain buy-in: Getting buy-in means giving people a stake in the game. Imposing technology decisions on people will not only result in a requirements mismatch, but it fosters discontent and mistrust. You can make a large downpayment on your cultural debt by bringing affected parties into the decision-making processes early. This has been shown to be very effective in helping pass decisions even when they have negative consequences.
    • Embrace the ‘Three Ways’: We can borrow from the DevOps movement the Three Ways, which provide a solid foundation for undertaking any technical work: Systems thinking encourages considering how decisions impact the whole system, not just the local area; feedback loops allow continuous feedback and communication about impacts; and continual experimentation and learning ensures that the organization is adaptive and resilient. Leadership that embodies the Three Ways is issued debt on very good terms.

    Conclusion

    Peter Drucker is quoted as saying that “Culture eats strategy for breakfast,” and the examples we’ve seen here highlight this. The best technology in the world cannot compensate for a broken culture, and a broken culture can be the result of a succession of ill-considered technology decisions. Understanding cultural debt is a key differentiator in being able to leverage Conway’s Law rather than be trapped by it. A key aspect of managing technology going forward will therefore be to identify and control this cultural debt as it is being created, and ensure that the organization is able to function with full-capacity engagement.

    About the Author / John Rauser

    John Rauser is the IT Manager of Tasktop Technologies, a global enterprise software company. As part of his role, he is responsible for specifying, managing and administrating software lifecycle tools, witnessing first-hand the impact they have on users and the business on a broader scale. He also serves as VP Operations at the board of the Project Management Institute – Canadian West Coast Chapter, providing leadership and expertise on technology issues. He has deep passion for discussing the business impacts of technology and analyzing strategies for IT management.

  • Incorporating Performance Engineering into DevOps

    Incorporating Performance Engineering into DevOps

    Performance testing historically has been a challenge for most IT organizations. It is highly misunderstood, from executives down to the few resources allocated to perform an extremely difficult task. Most companies consider performance testing expensive and unnecessary and simply refuse to acknowledge it is a critical component of the software development life cycle.  Have we forgotten about major performance failures such as Healthcare.gov? It is time companies start to take performance engineering seriously.

    IT organizations using the Waterfall methodology relied on a few performance testers to develop performance scripts and run them after most of the testing had been completed and the application was a few weeks from a production deadline. If the performance team was lucky, they would get in one or two successful tests, typically working off-hours and executing performance tests on small, patched-together ancient hardware. The problem with this approach is when issues are found, there is not enough time to fix them adequately and performance degrades over time.

    Developing a Performance Engineering Strategy

    Here are some items to consider when incorporating performance engineering into DevOps:

    • Learn—It is important to learn what performance engineering is and how it can be incorporated into your organization. If you don’t have the right skills within your organization, go find someone who can help. There are many organizations that can help with an initial assessment of where things stand.
    • Develop Your Strategy—This is perhaps were most teams fail. Upfront planning is critical and it will save you in the end. It is important to develop a performance engineering road map. This is not something that will be built in a few weeks; a solid performance road map could take 18-24 months, so be patient and build it right.
    • Build Your Baseline—It is important that you build a baseline of your performance tests so that you can determine if you have successful results. Performance testing is different from functional or automation because you have to consider the performance run as a whole. A few high transactions usually are acceptable. It is a good idea to build a history of runs to see how the application performance is trending.
    • Identify Key Business Workflows—It is too time-consuming to build hundreds of performance tests, so focus on those that are the most critical to your business. Typically those workflows will account for the majority of your performance load.
    • Test Upfront—With DevOps you need to start early and you will need to run performance tests frequently. The more you can run upfront, the more performance issues will be avoided in production.
    • Tools and Hardware—Performance engineering requires tools and hardware. It is important that your assessment evaluates what you currently have and what you will need to do it properly. There are many open-source tools on the market today that can help and other tools that are making a big difference in the performance space.
    • Budget—Developing a world-class performance engineering practice is going to take money. When you develop your performance road map, you might need two to three budget cycles to get the tools and infrastructure you need.
    • Load Performance Environment—Yes, you will need to have a performance environment that is scaled to match your production environment. If there isn’t enough budget, then you will have to know how much smaller the environment is so that you can be confident in your performance results.
    • Data—It is important to have data that is similar size to your production environment. This will help you understand how your system will handle performance within the production environment.

    Incorporating performance engineering within DevOps will require work, but the rewards will certainly put the organizations that embrace it at the top of the list. DevOps enables teams between Dev and Ops to produce a stable application that performs exceptionally well under load. Here are some benefits of DevOps performance engineering:

    • Predictable production performance results
    • Production deployment confidence
    • Eliminate catastrophic performance failures
    • Increased performance efficiency

    DevOps gives organizations a real opportunity to get performance engineering right; unfortunately, most organizations will carry over the same mistakes into DevOps. I hope you will take the opportunity to embrace the performance engineering challenge!

    About the Author / Ron Wilson

    Ron Wilson is a passionate champion of Agile, DevOps and Quality Engineering. He has managed large global Quality Engineering teams across multiple industries. He is currently the director of Quality Engineering at Arch MI. He regularly shares insights through social media where you can find him at www.qarevolution.com and on LinkedIn.

  • Yahoo7 Uses DevOps to Speed Website Redevelopment

    Yahoo7 Uses DevOps to Speed Website Redevelopment

    Yahoo7 is a joint venture between Yahoo and Australian entertainment and TV company Seven West Media. Seven is one of Australia’s three major TV networks.

    The company has completely replaced its technology stack and is in the process of revamping its seven consumer sites to take advantage of the new platform. The first cab off the rank is the Be entertainment and lifestyle site, but “the rest will come pretty quickly,” according to CTO Paul Russell.

    “We had an aging website based on a proprietary framework,” he said, which has been replaced with a platform based on node.js and other open-source frameworks, including the Yahoo-backed Screwdriver continuous delivery platform.

    There is also a focus on adopting reusable components across all the sites. It is more efficient to select, for example, an image gallery that gives the best user experience and deploy it across all the sites. That doesn’t mean all the new sites will have the same look; it is still possible to have distinctive layouts for each of them, Russell said.

    A move to cross-functional teams and Scrum “was a pretty big change for us” that took approximately two years, he said. There are three teams, each with four or five developers, a product owner, a tech lead, a Scrum master and a tester. A user experience specialist is added when required.

    The reorganization required “a mindset change,” but having people doing different types of work side by side did help. But the adoption of common KPIs “really has made a big difference,” as it keeps people focused on the things that really matter.

    “We’ve got a fairly mature DevOps model” and the current project is the company’s latest step, said Russell.

    Augmenting Screwdriver with automated performance testing on a range of metrics including latency and the number of requests per second that can be handled captures any problems at the early stages. This was “a really big step for us,” he said, especially as Yahoo7’s news content leads to significant spikes in demand, and also because the entire stack was being replaced.

    The scope of the project meant it was important to have experienced staff (top engineers were needed to pull everything together under Screwdriver, he noted), although some PHP developers were cross-trained for the technical skills required for the new platform. Russell said he is prepared to train people who come with the right attitude, but even though Yahoo7 is regarded as an attractive employer, “it’s definitely a challenge” to get the right people.

    Functional testing is being automated for some of the more complicated parts of the site, such as the video player, to improve confidence in each release.

    Russell believes organizations need to be clear about what they expect to accomplish by adopting DevOps practices, and warns that it requires a change of mindset which is unlikely to be achieved unless the people involved buy into the concept and are all on the same page.

    In particular, the idea of allowing the development team to run releases can be challenging to those used to traditional operations practices, but “it’s absolutely worth it,” he said. For example, the increased release pace means the company can respond more quickly when opportunities arise; Yahoo7 now can deploy two releases per day when necessary.

    There are also benefits from the way the teams take greater day-to-day ownership of the systems they build and run. This—combined, we suspect, with the shared KPIs—brings about a situation where rules imposed from above are largely replaced by good working practices created within the teams.

    A final tip from Russell to anyone considering the adoption of DevOps: You need the right tools and practices in place if it is to be successful.

    — Stephen Withers

  • Continuous Delivery vs. Continuous Deployment

    Continuous Delivery vs. Continuous Deployment

    I am often asked, “if we are using a continuous integration (CI) server and adopting a continuous delivery pipeline, where does continuous deployment fit in?” Good question. In a nutshell, continuous delivery engines such as CloudBees or Blue Ocean are designed to trigger the execution of CI workflows across the dev, test and prod environments. Continuous deployment is called as part of the CI workflow to do the actual release of code out to endpoints. Continuous deployment can be managed by application release automation tools or supported by one-off scripts. Regardless of how sophisticated the deployment step of your CI workflow is, it is still continuous deployment.

    To understand both continuous delivery and continuous deployment, one must go back to their roots, continuous integration. CI is a key component of Agile practice.  Agile developers understand the importance of adopting a methodology that can manage smaller incremental software changes to release software, and therefore business value, to end users quicker and cheaper.  The activities of deploying to testing and production historically have been in the hands of testing and data center teams, separate from Development. But in the Agile practice, these activities cannot be separated from development. The concept of separate development, testing and production teams is a waterfall concept, not an Agile concept. In Agile, everyone is on the same team. This means that testing and production teams must become part of the Agile process.

    Mastering Agile’s last Mile

    Ultimately, the goal of continuous delivery is to accelerate release cycles and get new code out to production fast. However, for most companies this is not happening. Developers and testers may have embraced continuous delivery, but when it comes to production, the code is moved to a staging area where it languishes until production is ready to perform the update. The last mile of Agile is not achieved. And we are back to where we started: waterfall.

    There are many reasons for the production roadblock. Lets’ review the top four.

    • Agents: Both open-source and commercial CI servers are agent-based. An agent based system works fine for developers and can be tolerated by testing. However, production teams are not that excited about installing yet another agent on to the production end points. For this reason, production team use their own method of deploying code. Therefore, the deployment scripts used for releasing code to dev and test are not used by production. The way they see it: Production does not want a deployment process that requires them to re-configure their data center environments with agent from a development tool.
    • Scripts: Production teams want input and visibility. One-off scripts obfuscate the deployment process. For this reason, production teams will write their own scripts. Scripts simply do not have the intelligence needed to meet the audit, rollback and transparency requirements needed by production teams. Production teams perform many steps manually. This takes time and cannot be done in an agile cadence. The result: Great code languishes in staging areas. Production stays several releases behind what continuous test has approved.
    • Cost, cost, cost: Most of what developers create in a continuous delivery workflow comes from open-source or consumption-based licensing models (think Jenkins and Jira). Tools that can achieve continuous deployment such as application release automation solutions are far to expensive for one development team to acquire and incorporate into the CI workflow. These types of tools are sold at the CIO level and cost upwards of $250,000. Production teams are often hesitant to purchases these tools, as the high cost equals high risk. And ‘one ring to rule them all’ does not work. This type of operational tool acquisition is waterfall-based and does not fit into the leaner Agile DevOps tooling. The result: One-off scripts continue to be used and dev and test. Production does not adopt agile.
    • Sustainability: During waterfall, a production release was performed as infrequent as two times per year, or at most once per quarter (considered aggressive). In other words, production is staffed to support a production release on an infrequent basis. With agile, the demand for production releases increases 10-fold. Instead of doing at most four releases a year, they may be required to do four releases a month. Production cannot keep up the agile pace. They are staffed for waterfall.

    Automating Continuous Deployment: Key to Maturing Continuous Delivery

    Continuous delivery cannot be successful without continuous deployment. If you want to roll code out to end users faster, the deployment process itself must be modernized. Using the same one-off scripts that were used in the waterfall approach will not achieve your CD goals.

    Continuous deployment automation is performed by a new set of agile DevOps tools called application release automation, or ARA. ARA solutions are designed to support a model-driven software deployment that allows development, test and production teams to use the same process without the need for one-off deploy scripts. ARA adds all of the features and functions needed to support continuous delivery and data center deployment requirements. ARA is designed to fully perform the heavy lifting of software releases including application packaging, release versioning, database updates, server configuration management, calendaring, roll-forward, rollback, security access and auditing.

    ARA solutions are called by a templated CI workflow that is defined by the development team. The workflow is moved up the pipeline and adapts to the changes at the various pipeline stages (System Test, Integration Test, Pre-Production, Production, etc.)  Because the process is driven by the ARA tool and not a script, the changes are automatically addressed across the pipeline reducing the workload for all teams and supporting frequent changes that can be easily traced and audited down to the server inventory level, including the production environment.

    Developers, Get Your Hands on Deployment Automation Tool       

    To achieve a repeatable CD pipeline that supports production, developers must embrace the automation of continuous deployment at development. The dysfunction however is the outrageously high cost of ARA tools. Developers don’t buy expensive operational solutions. More ARA solutions must be offered on a consumption-based model or offered as open source with the ‘out of the box’ integrations into CI/CD. When considering the purchase of an ARA solution, look for agentless models that can be implemented one project team at a time. Embracing this level of corporate process change must be done project by project. The operational big bang approach does not work well in an agile practice. Not everyone can use the same solution. However,  if done correctly, there are big benefits.

    ARA is a process that strengthens the foundation of the continuous delivery pipeline and is core to the agile DevOps initiative.   It facilitates agile practices by allowing the testing teams and data center teams the tools needed to become more agile and accept the frequency of changes being pushed across the pipeline by Development. Ultimately, the goal is repeatability across the pipeline, pulling together Dev and Ops.

    About the Author / Tracy Ragan

    Tracy Ragan is CEO and Co-Founder of DeployHub. Tracy has extensive experience in the development and implementation of business applications. It was during her consulting experiences that she recognized the lack of build and release management procedures for the distributed platform that had long been considered standard on the mainframe and UNIX.  Tracy has worked with hundreds of development teams in implementing a team-centric standardized build to release process. Connect with her on LinkedIn.