Tag: automation

  • How to Apply Agile and DevOps Principles to Accelerate Customer Experience Innovation

    How to Apply Agile and DevOps Principles to Accelerate Customer Experience Innovation

    These days, it’s not enough for companies to offer quality products or services; they must deliver an exceptional customer experience. In fast-changing environments, continual innovation on the front lines of customer service requires an agile and nimble approach.

    How important is the automation of development and monitoring for accelerating customer experience (CX) innovation? I recently posed this question to Dr. Nicole Forsgren, research and strategy expert at Google and former chief scientist at DevOps Research and Assessment (DORA). Her response:

    “I would say that, today, this is almost just a given to operate effectively. DevOps is definitely more than tooling, but you can’t do it without strong technology solutions that provide automation, monitoring and visualization to people throughout the value chain. This gives visibility to key stakeholders, so you can ensure you are delivering value and your feedback loops are happening.”

    This is not a simple concept to execute well. The diverse array of applications and systems that organizations deploy to engage their customers is complex and spans many different technologies, platforms and channels. Ensuring all those applications and systems work together seamlessly to enable customers to consistently accomplish their goals is a daunting challenge. What’s clear today is that how customers perceive their interactions with businesses, shapes brand loyalty.

    It’s interesting then, that while most companies recognize the importance of providing an outstanding experience, many have yet to embrace an automated approach for the development of their CX applications. Those enterprises that have successfully accelerated their CX innovation share a common attribute: They have automated both the testing and monitoring of their CX development projects.

    DevOps + CX = Faster Speed, Higher Quality, Fewer Failures

    Customer-facing applications, such as call center technology, websites, SMS and even chatbots, are the central artery of customer experience. If these applications are not designed, built and deployed properly, it will be costly. To ensure success of CX innovation projects and reduce the risk associated with development/deployment, we must build solutions with testing and monitoring in mind, automate deployment and configuration, and use test data in production to accurately monitor variance from the design.

    What’s holding your organization back? There are four important steps organizations can take to boost the speed and quality of CX software development, while reducing their failures.

    1. Strive for automation, anywhere you can find it

    Aim high—strive for 100 percent automation and take a creative approach to integrating different phases of development. Whether it’s JIRA, Bamboo, Udeploy, Cyara or any other technology that helps automate different parts of your software delivery life cycle (SDLC), have a vision that automates and integrates wherever possible. Success here will deliver smooth and seamless movement of work and deployments into various environments.

    2. Don’t underestimate the importance of the feedback loop

    In order to improve our CX, we must first understand what challenges customers are encountering right now. This requires real-time monitoring of the actual customer experience—but from the customer’s perspective, not from a hardware perspective, as is traditionally done. If you can monitor and measure customer interactions in the moment and capture them concisely, then you can channel this critical information back to business decision-makers, so changes can be implemented quickly. It’s one example of a feedback loop, and if you can repeat it over and over, you can significantly improve and refine your CX.

    3. Take the time to reflect, align and improve

    Instill a culture of learning and humility—not finger-pointing and blame. For example, I recommend teams adhere to well-defined Agile Retrospectives, a ritual that enables teams to create a continuous improvement culture in which they reflect on past experiences and define future actions. Retrospectives are only one of the many ways to instill an open-minded culture, constantly focused on improving collective capabilities.

    4. Integrate business objectives and measurements with the technology side of the house

    I see this as a two-way street. First, help ensure the technology teams understand the impact of their work and give them access to the metrics that are important to the business team, through regular progress reporting. Second, make sure the business team shares their goals and key objectives with the technology teams, rather than simply specifying a requirement. I think it’s important that developers and operations teams understand the business impact of success and failure—and, therefore, the importance of their work. This is a great motivator. Plus, more visibility and tighter integration with business objectives can also result in more creative problem-solving from the innovative thinkers on the IT side.

    A Parting Thought: Find Your Anchors

    The right decision or strategy is not always clear, but finding two or three pillars as your anchors can be clarifying during decision time. In the CX innovation space, I find two anchors are particularly helpful:

    • The customers are the reason why we are in business. Are you prioritizing the end-customer experience in this decision? Are you improving it, understanding it better or measuring it more effectively?
    • What is the business goal you’re aiming to attain? No matter how granular the technical change you’re making, there is almost always a business reason driving it from the top down. Do you know what that driver is? How, exactly, will your change move you closer to that business goal?

    — Amy Hudson

  • Report Identifies DevOps Skills in Highest Demand

    Report Identifies DevOps Skills in Highest Demand

    When it comes to DevOps there’s general agreement that a skills shortage is holding back broader adoption. The real issue, of course, is identifying what specific DevOps skills are required most.

    With that goal in mind, the DevOps Institute this week published a report that finds the DevOps skills most in demand fall into three broad categories: automation skills (57 percent), process skills (55 percent) and soft skills (53 percent).

    DevOps Institute CEO Jayne Groll said that, given the fact that DevOps is all about automating repeatable processes, the fact that automation skills are the most sought-after is not all that surprising. But when it comes to process skills, the top five areas where organizations need the most help are software development life cycle (47 percent), understanding of process flow and analysis (46 percent), agile development expertise (42 percent), experience with test-driven deployment concepts and methods (40 percent) and system thinking (39 percent).

    The survey also identifies areas where survey respondents need additional functional skills; most notably, IT operations knowledge (52 percent), security (47 percent), IT infrastructure (44 percent), application design and development (42 percent), quality assurance (34 percent) and testing (31 percent).

    While the survey makes it clear what skills are needed most, it’s less clear whether organizations want to train people with the right attitude toward DevOps skills or find individuals with proven skills. About 30 percent of the survey respondents said they look for soft skills first, with an eye toward training or educating new hires on the process and technical skills later. But 32 percent of respondents said they first look for technical skills.

    In that context, however, it’s also worth noting that 43 percent of the C-level executives and IT management executives that participated in the survey identified business skills—defined as communication, influencing, negotiation, strategic thinking and leadership skills—as being the most important attribute of a new hire.

    Other noteworthy attributes of the organizations participating in the DevOps Institute include:

    • Two-thirds (66 percent) have already adopted DevOps to some degree.
    • More than three-quarters (76 percent) employ agile development processes.
    • Nearly half (47 percent) have adopted the ITIL framework as a best practice for IT service management.
    • Only 10 percent rely on site reliability engineering (SRE) practices defined by Google.

    Groll said the survey makes it clear there is still much work to be done in terms of advancing best DevOps practices. One the biggest challenges are all the silos within IT organizations that have their own nomenclature and culture. Each of those silos creates technical and cultural inertia that must be overcome to integrate processes end to end, she said.

    On the plus side, Groll noted the next-generation of IT professionals are being taught best DevOps practices in academic settings, which means the pool of job candidates with familiarity with DevOps practices should increase steadily. The downside is that it might take a while before those individuals learn enough about the business of the company that hires them to effectively employ those DevOps practices.

    — Mike Vizard

  • Digital Transformation Technology and Process: More Similar Than You Think

    Digital Transformation Technology and Process: More Similar Than You Think

    Right around this time of the year, the gym starts to get a little less crowded. Throughout January, it’s packed to the gills with folks freshly motivated by their New Year’s resolutions to get in shape. But by mid-February, the commitment seems to have all but dissipated.

    Why is it so hard to just commit?

    During my last workout, it occurred to me that the set of vacant treadmills next to mine was eerily reminiscent of the state of enterprise DevOps. According to Forrester, 50 percent of digital transformation efforts stalled in 2018. It seems commitment and follow-through are difficult in both personal and professional arenas. Admittedly, adopting and scaling DevOps is no easy feat. While reflecting on what does work, I found some parallels between the transformation process and DevOps itself.

    What Success Looks Like

    According to DORA’s “2018 State of DevOps report,” organizations with the highest level of DevOps execution, as measured by throughput and stability, also achieved the highest level of business performance in terms of profitability, market share and customer satisfaction. In a true case of going fast without breaking things, elite performers realized impressive performance gains:

    • 46 times more frequent deployments (throughput)
    • 2,555 times shorter lead times (throughput)
    • 7 times lower change failure rate (stability)
    • 2,604 times shorter time to recovery (stability)

    These metrics underlie a key tenet of DevOps transformation, which is breaking up large chunks of work into many small pieces.

    Shrinking the Change

    Smaller changes mean getting work out faster, with less risk. They take less time to plan, less effort to execute and are easier to troubleshoot. But, smaller code changes alone aren’t meaningful unless they are coupled with shorter release cycles. In essence, agile without CD doesn’t work.

    Stockpiling a few months worth of agile code iterations into a single monolithic release reintroduces an enormous amount of risk and negates much of the work done to adopt agile software development in the first place. Big queued-up releases often mean someone is stuck working the weekend to iron out all of the things that inevitably go wrong and no one should be stuck with weekend release duty. As Jez Humble put it, “The most important metric for continuous delivery is the number of person hours spent outside of business hours doing releases… and the goal for that is zero.”

    In practice, CD is what brings agile development to fruition; it’s why Gartner finds that 40 percent of IT departments have already invested in CI/CD with a full third planning to invest in 2019. CD is all about small pieces. In the same way agile enables smaller code changes, CD enables smaller releases.

    Not Just Smaller, but Iterative

    At GitLab we use the phrase, “just commit” as a shorthand for continuous delivery and deployment. The idea is that when you have a completely automated CI/CD pipeline, all a developer needs to do is commit code to their branch, and everything else needed to get that code running live in a production-like environment—from containerization to security testing—is automated. Similarly, getting code to production is as easy as merging the feature branch back into trunk with the entire production deployment automated. The message to the developer is, “Just commit your code and let your DevOps tooling do the rest.” This is CD in a nutshell.

    With this type of automation in place, the cost of making a change significantly decreases. This means the cost of getting started is very low, but so is the cost to keep going. Instead of spending a massive effort to map an entire path to your solution, you simply need to figure out your next step and keep iterating. According to GitLab’s “2018 Global Developer Report,” 67 percent of developers report the top challenge to getting work done is unclear direction. By shrinking the change, business leaders will find it easier to set direction for the next step without having to map the entire path. This brings us back to digital transformation.

    Commit to Digital Transformation

    Just like a monolith being decomposed into microservices, the practice of breaking large chunks into small pieces applies to driving digital transformation as well. Like Creighton Abrams said, “When eating an elephant, take one bite at a time.”

    How can enterprises shrink the change?

    For most organizations that achieve successful digital transformation, the initiative usually starts with a single team or innovation unit. This group proves the success for the rest of the organization. It develops that culture, tools and processes that other parts of the organization can then adopt. One example of this principle in practice is the transformation that Chris Hill, Head of Systems Engineering, Infotainment, led at Jaguar Land Rover. When Chris came on board, only three build engineers had the ability to release to production and it took four to six weeks to complete each release. Chris gradually scaled a CI/CD platform, step-by-step over two years, until every team across the organization was able to complete a release in less than 30 minutes. Today, the Jaguar Land Rover completes 50 to 70 deployments per day. This iterative pattern is seen over and over again with enterprise digital transformation. It’s encouraging because it means successful digital transformation can be driven by either executives top-down or engineers bottom-up.

    Keep the Fuel Burning

    According to Argyle, “91 percent of companies have at least started on digital transformation, but only half have created an organization-wide strategy.” This seems to align with Forrester’s metrics on half of the organizations that stall.

    So, how can organizations keep going and avoid the stall out?

    If I can make a confession, I am also one of those New Year’s resolution makers who just started working out in January. How it is that I’m still hitting the gym while others have dropped off? I have found that taking a “DevOps” approach is a key to my success. Instead of broad sweeping changes, I make small incremental improvements one day at a time.

    It turns out the strategy for getting started—“just commit”—is the same strategy to keep going.

    By starting small with a single project and gradually expanding scope in iterative steps, an organization can continue to improve over time at a rapid pace. Small, single-commit code changes coupled with CD increase throughput and stability. In the same way, small, incremental process improvements bring about the greatest success with digital transformation.

    — William Chia

  • Full-Time Employment in the Age of Automation

    Full-Time Employment in the Age of Automation

    Back in 1930, the economist John Maynard Keynes wrote a short essay, “Economic Possibilities for our Grandchildren,” in which he predicted that in a hundred years the 15-hour work week will be commonplace. Keynes made this assertion based on two factors: first, the increase in capital due to extraordinary yields from the compound interest that was made possible by increased foreign (global) investment; second, the growth of technological achievement made necessary by the competitive forces of capitalism and made possible by the availability of excess capital.

    Keynes pointed out that these events are recent in terms of the entirety of human history, taking place over the last 500 years. Before that time, things were stagnant. Gold reserves remained static until the opening of the New World and technology, save for a few episodic breakthroughs, was pretty much unchanged. For example, the way cloth was made during the time of Joan of Arc, around 1400 AD, was not that different than the way it was made when the Roman emperor Hadrian had a wall built across northern England in 100 AD.

    But, the growing availability of money and technology changed everything. By 1920, the more affluent in the population wore factory-manufactured clothing bought in a store. Those of lesser means might still be making clothes at home, but the cloth from which the garment was made came from a factory.

    Mass-market capitalism powered by technological innovation increased human productivity on a scale unique in the human experience. Abundance on a global scale seemed a real possibility within a few generations. According to Keynes,

    “If capital increases, say, 2 percent per annum, the capital equipment of the world will have increased by a half in 20 years, and seven and a half times in a hundred years. Think of this in terms of material things—houses, transport, and the like.”

    Yet, today most people work 40 hours a week, if not more. Considering that Keynes was essentially a quant who lived and breathed data, how could he get it so wrong?

    My thinking is not so much that Keynes got it wrong, but that we’re having a hard time accepting that he might have gotten it right.

    Allow me to elaborate.

    The Facade of Productivity

    I have a theory: For the average contributor-employee in a medium- to large-size corporation (with 500 employees and more), of all the tasks he or she performs during a 40-hour week, only about half—20 hours’ worth—actually add value to the enterprise. The rest is organizational overhead. Thus, there is a good argument to be made that when you do the math, what we can call real full-time employment is closer to Keynes’s prediction of the 15-hour work week than not. The remaining time, which I call “organizational overhead,” is really just a facade of productivity.

    This theory occurred to me a while back, when I was sitting in a sprint planning meeting observing a project manager and tech-leads do task assignments. The first thing the project manager did was to determine how much time each member of the project team had available to work on the project’s tasks. The agreed-upon number was 20 hours a week.

    The 20-hours a week number struck me as strange. All members of the project team were completely dedicated to the project. They had no side work. The project was their one and only focus. What were they doing with the other 20 hours?

    I asked the project manager and he answered, “Well, they have to do things like answer emails, go to meetings and sometimes there’s some firefighting to be done.”

    Oh.

    The Amazing Ability to Absorb the Cost of Organizational Overhead

    I wish I could say that the project manager’s response was unique. But, in my experience, it’s not. I’ve been in more than one company in which meetings, email and firefighting occupy at least half of a full-time employee’s work week. And, I’ve got to tell you that, except in the rarest instance of mission-critical firefighting, most of these situations have marginal productive value.

    Granted, my theory is based on experiences that are anecdotal. The actual numbers might prove me wrong. Obviously, a thorough, quantitative study is needed. Still, whether it’s five, 10, 20 or even 35 hours a week, what’s amazing is not that employees spend a lot of time in activities that have questionable productive value, but rather, that businesses can actually operate profitably despite these ongoing time-sinks. Why? Because of automation. Machines and software are allowing people to do more work in less time—and it’s not only confined to IT.

    The Dirty Little Secret of Working on an Assembly Line

    Doubling up has always been the dirty little secret of automotive factory work. Ben Hamper revealed the details of technique in his 1986 book, “Rivethead: Tales from the Assembly Line.” Here’s how it works: Imagine that you and I work in a GM plant and do jobs at the same location on an assembly line—say, putting headlights and taillights in a car. Your job is to put in the headlights; my job is to put in the taillights. One day I notice that I can probably put the headlights and taillights in a car in the same amount of time it takes two of us to do the tasks separately. So, I propose a deal to you: I’ll do your job and my job for four hours a day in exchange for you doing the same for me. This way we can both work half time for full-time pay. We might have to pay the line foreman a small bribe to look the other way, but what the heck? The benefits are obvious, so we do it. Win-win, as the saying goes.

    How can we pull this off? Simple: as stated earlier, automation.

    Without the technology of the assembly line, we just couldn’t double up. The car needs to be brought to us for us to increase productivity to the point where one person can do the work of two. The automation of the assembly line effectively reduced our work week while maintaining our productivity, just as Keynes predicted.

    As you can see, the 15-hour work week is quite possible—and, in many cases, quite real. It’s just that the facade of productivity, which exists in larger companies, hides its existence. But, what about the smaller companies such as construction companies, law firms, small manufacturers, dental offices and software startups that employ fewer than 100 people? These types of companies cannot afford a lot of non-productive activity. How do these companies get to the 15-hour work week? Is it possible?

    My answer is yes, but the world that will need to exist to make the 15-hour work week possible will look dramatically different than the one we have today. What will that world look like? Allow me to illustrate using my neighborhood cafe, the C&M, as an example.

    The Real Implications of the 15-Hour Work Week

    My favorite neighborhood cafe is the C&M. It’s a hangout sort of place with good food, good coffee and Wi-Fi. The C&M is usually staffed by two employees during its business hours—7 a.m. to 5 p.m., seven days a week. Between them, they take orders as well as make the food and deliver it to the tables.

    Let’s do the math. Let’s figure that the actual working day at the C&M is 12 hours—10 hours of operation time and two hours of setup and cleanup. That comes out to 84 hours a week. Thus, excluding the owners’ time, the number of employee hours needed to run the C&M is 168. (two employees at 84 hours a week.) This comes out to around four people required to staff the business using the current 40-hour work week model, again excluding the owner’s time.

    Now, let’s say the business is quite profitable and the owner can afford to pay employees $20 an hour, plus health insurance. Adding in payroll tax and workman’s compensation (more than $5 an hour) plus the cost of health insurance ($400 a month, for illustration purposes), the weekly cost of each employee working 40 hours is $1,100, which translates into a total weekly labor cost for the C&M of $4,400.

    So far, so good.

    This time, let’s interpret the C&M labor situation in terms of the 15-hour work week. To cover the 168 hours per week that the C&M is operational, at a 15-hour work week per employee, the C&M needs to employee 11 people—actually, it’s 11.2 employees, but I rounded down. So, under Keynes prediction, if each employee is entitled to the established full-time compensation of $1,100 as calculated earlier, the weekly payroll for the C&M goes from $4,400 a week to $12,100—an almost three times increase, which is not an affordable number. Even though the number of employees has gone up, the odds are that the actual sales will remain the same. Instead of having to employ four people producing $14,000 a week in sales—$2,000 a day over seven days, again for illustration purposes—now the owner of the C&M will be employing 11 people to produce the same amount. Bankruptcy is imminent.

    Clearly, the C&M cannot tolerate 11 people working 15 hours a week for a full-time wage under current conditions. So much for the 15-hour work week. Well, not so fast. Let’s reimagine the scenario from a different angle: Suppose that the number of employees stays at four, but instead of working 40 hours a week, each employee works 15. What could we add to the mix to make this scenario possible? Give up? OK, I’ll tell you: robots.

    Imagine that instead of having two people on hand to set up the cafe, take orders, make the food, bring it over to tables, bus the table and then clean up at the end of the day, we had one person on hand to do what we’ll call human essential work. All the other work gets done by robots. Then, the typical interaction looks like this: Customers enter orders directly into an iPad, the robotic coffee maker gets the order and makes the double espresso, a robot in the kitchen makes the food, with the intermittent help of a human when necessary, and a robot delivers the food to the table. The one human on hand interacts with customers and picks up the slack work the robot can’t do. You can think of the scenario as the restaurant equivalent of a driverless Uber ride.

    Is such a world possible? Yes. In fact, it’s happening as you read this article. There’s already a chain of waiterless sushi restaurants in Japan. As the technology drops in price, more restaurants will make the transition.

    The 15-hour work week could indeed become a real possibility provided that two conditions exist: affordable robotic technology with a high degree of manual dexterity is available, and the employer is willing to pay the higher wages necessary to support the model.

    In the past, workers such as Ben Hamper used their ingenuity to take advantage of the reduction in labor that automation made possible. Sadly, such efforts were clandestine and deceitful. All that GM needed to do to realize a better return on labor was to speed up the assembly line. Yet, when you think about it, back then GM wasn’t doing that badly when Hamper was doubling up. 1984 was a record-setting year in sales, despite his shenanigans. Speeding up the line would undoubtedly increase GM’s bottom line. But, would it double Hamper’s take home? Probably not. (Author’s Note:  GM’s sales dropped 26 percent in 1986, but profits were still a healthy $1.06 billion.)

    So here are two questions to contemplate: As companies, large and small, adopt robotics to increase productivity, will they indeed share the benefits of the increased productivity with the average worker so he or she can enjoy a 15-hour work week? And then, should the 15-hour work week indeed become standard, what will the average person do with all this newfound leisure? As the saying goes, idle hands make fretful minds. According to Keynes:

    “Yet there is no country and no people, I think, who can look forward to the age of leisure and of abundance without a dread. For we have been trained too long to strive and not to enjoy. It is a fearful problem for the ordinary person, with no special talents, to occupy himself, especially if he no longer has roots in the soil or in custom or in the beloved conventions of a traditional society.”

    For those of you that think about such things, I will leave up to you to answer these questions. As for me, I can’t wait for the robots to take over so I can go back to my studies, full-time.

    — Bob Reselman

  • DevOps and Security: The Path to DevSecOps

    DevOps and Security: The Path to DevSecOps

    A secure DevOps is highly beneficial for organizations. However, a secure DevOps environment shouldn’t be the end goal. When it comes to DevOps security, it’s important to integrate security right from scratch, secure the entire architecture, automate the security and use this technology to test the environment and the codes and respond to concerns immediately. This can help organizations safeguard their creations, protect the confidentiality of their customers and strengthen their applications, all before data breaches can occur.

    DevSecOps is a philosophy that focuses on introducing a culture of security in the DevOps environment. It is a collaboration of the DevOps teams with cybersecurity and system security personnel, where the focus is on finding faster and more efficient ways to safely deliver codes in an agile architecture. DevSecOps strives to bridge the gaps between IT and security while responding to bottlenecks in the existing environment.

    Some of the biggest benefits that organizations will get when they move from traditional DevOps philosophy to the DevSecOps philosophy is:

    • Improved operational effectiveness and efficiency.
    • Stronger and healthier collaboration between teams across the company.
    • Greater agility for security teams.
    • More conducive environment for automated builds and quality assurance testing.
    • Easier to identify system and application vulnerabilities.
    • Greater freedom for personnel to focus on high-value projects.
    • A greater degree of transparency into the environment.
    • Improved scalability in the cloud.
    • Increased ROI.

    Key Elements of the DevSecOps Environment

    Microservice-Based Infrastructure

    Single-function modules that contain well-defined interfaces and operations is essential for the success of focused DevSecOps. Constantly monitoring, upgrading and tweaking the microservice-based infrastructure will help organizations to be equipped for new developments.

    Hybrid cloud environments, software-defined networking and network micro-segmentation must be integrated into the infrastructure, and these must be used to better define parameters, assess and identify connections, verify access and monitor the organization’s online assets.

    Continuous Feedback Loop

    The next most important element of the DevSecOps environment is feedback. Setting up a continuous feedback loop will help developers and machines get a comprehensive insight into system/platform vulnerability to security threats. This type of real-time, continuous feedback can help organizations set in place the right policies and rule sets, which can keep the application security testing tools updated and relevant regarding the security status of the organization’s software/network/platform, in addition to keeping all parties updated about the potential threats to the DevOps environment.

    This type of continuous feedback loop acts as an enabler, as opposed to an inhibitor of business, by allowing organizations to stay well-equipped and constantly on guard.

    Focused Automation

    Finally, continuous and focused automation is essential to the success of the DevSecOps environment. Automation, when woven into the software development life cycle right from the start, can reduce the friction that may occur between development and security teams over software/platform security by quickly addressing existing and potential concerns at the lowest cost.

    There are certain open source tools on the market that can help organizations automate their security:

    • Continuum Security: This tool works on a BDD-Security framework, which is compatible with unit testing frameworks, issue trackers, SAST and DAST. It offers an open IriusRisk API for anything the tool doesn’t natively support.
    • WhiteSource: This particular tool specializes in addressing open source vulnerabilities, alerting users about the existence of threats throughout the pipeline. It is compatible with 200 programming languages and it actively analyzes the license, quality and security of all open source codes.
    • ThreatModeler: This platform uses the functional information that developers input to analyze the software and provides information about potential threats. It also offers actionable inputs and security test cases to enable easy implementation of security.
    • Evident.io: This solution is designed for the deployment stage and helps assess and manage cloud security risk, particularly on Azure and AWS. Evident Security Platform (ESP) offers continuous monitoring, early threat identification and threat mitigation.
    • Aqua Security: This tool is ideal to manage end-to-end DevSecOps pipeline security. It has very tight runtime security processes and controls in place. It offers full control over the containerized environment and prevents any intrusion or vulnerability across the pipeline.

    There are many other tools that organizations can use to automate their DevSecOps environment. These include: Dome9 (SaaS) Security, Contrast Security RASP & IAST tool, IMMUNIO RASP tool and Checkmarx SAST tool.

    Shifting to the Left

    In today’s agile world of development, following outdated waterfall philosophies is a death sentence for companies.

    For successful implementation of DevSecOps, organizations should shift left. In other words, they should integrate deployments and testing right from the start, and these must continue till the very end when the software/platform in question is vulnerability-free. Etsy and Amazon, for example, conduct more than 1,000 deployments per day, each aimed at recognizing potential threats to their systems. Such a highly dynamic DevSecOps environment ensures that the velocity of new development isn’t slowed, and the quality of new developments is maintained at a high level.

    This type of “shit left” philosophy not only accelerates new developments but also helps limit the security threats and addresses existing threats at the least cost with minimal damage to the software/platform.

    Incorporating AI and Machine Learning into DevSecOps

    Research shows that more than 50 percent of all companies will implement machine learning in their DevSecOps operations in 2019, due in part to the various benefits AI and ML offer to organizations that are actively maintaining a DevSecOps environment. These benefits include:

    • AI and ML will bring down DevSecOps security review time. They will do this by increasing the speed and quality of false positive identification, which will reduce the time spent on threat vector identification. This will help developers improve the speed at which they recognize the threats to their systems.
    • AI and ML will make up for the cybersecurity talent shortage, thereby ensuring that an organization’s DevSecOps environment isn’t left unmanned at any time. AI and ML will dip into human intelligence and use this to fuel their involvement in the DevSecOps environment. Additionally, AI and ML give organizations the ability to understand how other machines function, thereby helping cybersecurity personnel understand the psyche of cyberattackers.
    • AI and ML will actively find defects in the DevSecOps, help developers identify what they’re doing wrong and what they need to do to rectify these concerns. Constant monitoring is a core feature of DevSecOps, and AI and ML will serve to add more advanced technological backup to power this feature. AI and ML will also offer developers customized secure code patterns based on the organization’s unique DevSecOps landscape, which will assist in vulnerability detection.
    • AI and ML can help organizations move their DevSecOps from a small scale endeavor to large-scale. This will be a possibility because of the sheer technical prowess and the real-time information that AI and ML will furnish to developers and cybersecurity personnel.

    7 Rules to Successfully Implementing a DevSecOps Environment

    • Integrate security from the start and across the pipeline.
    • Automate your security.
    • Track and monitor each software stack meticulously to identify which needs patching.
    • Implement code dependency checks such as the OWASP Dependency Check, vulnerability assessment and discovery tests regularly.
    • Put in place robust policies to manage the DevSecOps environment.
    • Break your tasks into manageable chunks—this will improve the consistency of deployments.
    • Set in place one-click compliance reporting to increase traceability and transparency of the pipeline, right from code planning to code changes to release.

    Conclusion

    DevSecOps will bring massive economic and technical advantages to organizations, apart from equipping them with the capabilities to create, run and offer state-of-the-art software/applications. Organizations wanting to remain relevant and competitive in the industry must consider DevOps security as their primary goal in 2019.

    — Subramonian

  • How SRE Creates a Blameless Culture

    How SRE Creates a Blameless Culture

    People in tech love to praise failure as essential to innovation. But at far too many organizations, when failure happens, it is punished. When an IT system goes down, an individual or a team is immediately ID’d, blamed and shamed. This is counterproductive. Blame damages companies by creating a play-it-safe atmosphere and stifling innovation; even worse, when mistakes are made, they are often hidden.

    Fortunately, more and more organizations are recognizing the damage that blame can do and embracing a blameless culture. This is a big shift, yes, but companies can make the move to blameless—and make it stick—if they bring site reliability engineering (SRE) best practices to their technology teams.

    Why Blame is Bad

    I’ve worked at several fast-growth companies that suffered under a culture of blame. At one, we were scaling quite rapidly. Change was constantly being introduced to the infrastructure, which meant that it broke all the time.

    Because we had customers running their core business on our systems, our reliability requirements were very high—so high that for a while we stopped feature development altogether, in fear that new features would bring our systems down.

    This was difficult enough, but the culture of blame made it worse. There was no psychological safety net and fingers were pointed constantly. There was an us-versus-them mentality—engineers versus non-engineers, developers versus operations, developers versus developers. Developers dedicated way too much mindshare to protecting themselves and their domain.

    In a blame-rich environment, developers who should be delivering concrete results spend too much of their time in meetings trying to justify their work. There is a culture of retribution for mistakes. This leaves little room to learn and grow from failure because developers get harassed by management when they do make mistakes, or they get fired.

    Your best people—those empowered to make decisions—see their responsibility undermined and go elsewhere. Creativity and innovation slow to a crawl. Meanwhile, competitors run ahead.

    Why Blameless is Better

    In a blameless culture, everyone feels safe and no one is afraid to make mistakes. It’s a psychologically secure environment, where true DevOps can happen. Developers feel confident enough to express their ideas and take chances. Development folks and operations folks collaborate well, and everyone is aligned on the problem.

    The work environment is positive and workers are assumed to be doing their best. When mistakes happen, people aren’t blamed. Instead, any error is viewed as a manifestation of an underlying vulnerability in the systems. Attention is focused on fixing those vulnerabilities and, as a result, systems are constantly improving.

    How to Get to Blameless

    Let’s say you just had an outage and your database crashed. Don’t start by placing blame on a team or individual. Rather, start by conducting a postmortem. Ask questions and find the answers: Why did the database crash? Because Alex pressed the wrong button. Well, why? Because we didn’t have a system in place to enable automatic checking or a review process. So why did we not have that?

    Now you’re getting to blameless and you’re reaping the benefits. You’re having a productive conversation and you’re focused on fixing your systems, not affixing blame. It’s not about Alex pressing the wrong button; it’s about how your organization is not set up to ensure success. It’s about this vital opportunity to learn from a mistake and get better. Don’t fire Alex. Put a solution in place so the problem doesn’t happen again.

    How SRE Can Help

    To get to a truly blameless environment, you need to implement SRE best practices. Why? Because SRE creates ultra-scalable and highly reliable software systems, by building in automation and tooling—moving the human element out of the picture and focusing on the systems.

    One of the founding principles of the SRE movement is blamelessness. By implementing an SRE team and establishing SRE practices, your organization can move from the traditional operational model of break-fix to an environment that applies a development approach to IT operations, with the goal of improving reliability via automation, continuous integration and delivery.

    For this to happen, you will need a SRE champion to quarterback your SRE effort. You will also need organizational buy-in to blamelessness. It has to be practiced top-down and have the full support of all leaders in the organization.

    Tooling is critical, too. Look for tools and dashboards that can quickly do postmortems and find action items that need attention, that can identify the most commonly impacted services, products and customers, and the contributing factors that most often lead to incidents. The right tools will help you resolve incidents faster, by providing a clear overview of metrics related to incident identification and the actions that need to be taken.

    You want to move fast and be innovative. But can you do it reliably? With a blameless culture, you can. You’ll have a safe environment that attracts and retains the best talent. You’ll move quicker, because you’ll be focused on fixing systems that break and finding out why—not the blame game. By delivering a higher degree of reliability, you’ll build greater trust with your customers.

    You’ve heard the saying: Failure is not an option. In a blameless environment, failure is always an option—because it means that systems are always improving and innovation is always happening.

    — Ashar Rizqi

  • SauceCon Speaker Profile: Richard Bradshaw

    SauceCon Speaker Profile: Richard Bradshaw

    This is the sixth in a series of articles highlighting speakers at SauceCon 2019. SauceCon brings together the global community of Sauce Labs users and continuous testing experts, to learn from each other and level up their automated testing and continuous delivery skills. This year’s event will be held April 23-25 in Austin, Texas.

    Richard Bradshaw is known for running the Ministry of Testing, speaking at events all over the world and for being the “Friendly Tester”—a nickname given to him by a developer.

    However, one thing toward which Richard isn’t 100 percent friendly is the Test Automation Pyramid. He says it can and should bring about conversations, but thinks it lacks too much to function as a solid automation strategy, which is how many people use it. At SauceCon 2019, Richard will present some other options in his talk, “Pyramids Are Ancient – Let’s Talk Automation Strategy.”

    Richard hopes that people will take away the fact that to truly be successful with automation, you need to fit automation into your overall testing strategy. During his talk, he will review the steps that he takes when conducting an automation audit, steps attendees will then be able to immediately take back to work and begin applying. “I also hope that observing me critique existing models will motivate them to do the same to some of the models used in their current workplace, and identify ways to improve their approach,” he said.

    Richard is well-qualified to help testers improve in this area. As the BossBoss (aka CEO) of the Ministry of Testing, his primary role is to ensure they stick to their mission of “co-creating better testers.” Richard and his team offer numerous ways to learn and share testing knowledge. They run the TestBash conference, manage an online learning platform called The Dojo and host meetups all around the world.

    When he is not working or thinking about work (a rarity!), Richard loves cooking up a storm, hiking and traveling.

    You can hear from Richard and more than 30 other expert speakers at SauceCon 2019, the third-annual Sauce Labs user conference. To see a full list of presentations or to register, visit the SauceCon website.

    — Rebecca Cramer

  • Break-Even Analysis: Understanding the Impact of Automation

    Break-Even Analysis: Understanding the Impact of Automation

    Determining whether automation is helpful beyond the CI/CD pipeline can be easier through a break-even analysis

    The pursuit of automating away all the operational tasks in your organization doesn’t stop after you finish building a solid CI/CD pipeline infrastructure using the myriad tools available and making it stable.

    There are many more one-off tasks not part of the CI/CD pipeline, but which are very important for managing the infrastructure and operating the applications running in production, that are not yet automated. These tasks could be very specific to your organization, but some common categories of these tasks are:

    • Provisioning and maintenance of infrastructure, including patching, updating certificates and licenses.
    • Maintenance of monitoring systems.
    • Generation of reports and dashboards.

    To Automate or Not to Automate?

    A CI/CD pipeline is an end-to-end automated system that handles all aspects, from builds triggered by code change through deploying the built artifacts into production, with very little or no human intervention in between. The non-CI/CD tasks described above could be automated or be carried out manually.

    An inexperienced DevOps team can easily get carried away by the notion of  automating everything and end up spending time on low-priority tasks—sometimes, simply because using a new tool or the coding work involved in automating a task can be very attractive to the team members. While such endeavors would look great in a sprint demo and on a resumé, they won’t help the business achieve operational velocity. When there are multiple automation projects competing for the team’s time, it would make sense to do a break-even analysis to obtain better insight on the returns of automating an operational task.

    The Agile methods to select and quantify a task such as backlog prioritization and estimating time for a story are not adequate to assess how the organization would benefit from that project overall. The break-even analysis proposed here would help to determine whether an automation project is worth doing by looking at the overall impact of rolling out that automation in the organization. Agile is limited by its narrow focus on the team that rolls out the automation—the DevOps team—and it cannot provide any metrics on the overall impact of an automated process on the organization.

    The Break-Even Analysis

    Let’s define various metrics involved first and then do the simple math of overheads and breaking even with the benefits.

    Development time (d) – This is the time needed to develop and roll out an automation task. This would be same as the time estimate used for a related story in an Agile sprint. In hours.

    Maintenance time (m) – As any experienced DevOps engineer can attest, developing a script or tool suite is not a one-time deal. The changes will be needed due to many factors:

    • Infrastructure change.
    • Fixing bugs in the tool.
    • Enhancement requests.
    • Training users of the tools, such as SREs and fellow team members.

    Budget the hours needed annually for this task, depending on the complexity and possibility of changes down the road.

    Manual working time ™ – The time needed to complete the task without automation. Doing things manually can cause human errors which adds to the total time. Factor that in the estimate  if this task has been causing issues. In hours.

    Automated working time (ta) – The time needed to complete the task using automation. In hours.

    Jobs count (c) – The number of times this task is run. Make an annual estimation so even infrequent operational tasks can have a score.

    Though arbitrary, my suggestion is to try out an automation for a year for its benefits. Check if the project would bring in impressive returns during that time frame:

    Project overhead = d + m

    Savings from automation = (tm – ta) x c

    Net benefit to organization = Savings from automation – Project overhead

    To embark on an automation project, the organization should benefit greatly from it to do things faster and better. While an Agile way of prioritizing an automation task would narrow the focus only on the DevOps team, this method also gauges and factors in the users’ time.

    DevOps Benefiting Customers

    The tools developed might not be used internally always, which is a major assumption in the above break-even analysis. It is quite possible that an automation process could benefit end users as well. I think it is very important to factor in the time saved by our customers also.

    Happy customers always bring in goodwill to a company.

    — Thomas Theakanath

  • DevOps: Don’t Let Detection Be a Bottleneck for Security

    DevOps: Don’t Let Detection Be a Bottleneck for Security

    AI and automation can help ensure DevOps security doesn’t impact performance

    The world revolves around software and internet-based applications—and speed is crucial. Users have very little patience for delays and will quickly jump to something else if performance lags. Organizations have embraced DevOps and containers in an effort to accelerate development and deployment of software and maintain a competitive edge over rivals. One of the biggest challenges, though, is how to identify vulnerabilities and detect security issues without significantly degrading performance.

    There will always be some impact on performance. You are adding an extra layer of functionality—a layer of security intended to detect and resolve security issues. No matter how fast that detection is, it will still take more time than not having any detection at all. The goal is to implement detection with as little impact on performance as possible. You don’t want detection to be a bottleneck for your cybersecurity efforts, or a drag on performance in general.

    Bridging the Gap Between Speed and Security

    One of the defining characteristics of a cloud-based, containerized, DevOps environment is its dynamic and continuous nature. In an effort to streamline and accelerate business, organizations embrace continuous development, continuous integration and continuous deployment combined with continuous monitoring, continuous testing and continuous improvement—all of which require continuous security.

    Real-time monitoring for suspicious or malicious activity is crucial. The internet doesn’t sleep, and attackers are constantly scanning and probing for vulnerabilities and weak links to exploit in your network and applications.

    Security is important, but not at the expense of productivity. The challenge is how to bridge the gap between speed and security—and ensure you can detect attacks effectively without introducing undue friction. You need balance—security that provides necessary protection without defying the whole point of trying to streamline and accelerate business. In other words, security needs to become a guardrail rather than a roadblock for DevOps.

    Improve Detection with Automation and AI

    Real-time protection is necessary—but not all real-time security solutions are the same. How attacks are detected is as important—or more important—than just detecting them.

    Why? Simple. Attack detection based on signatures or generic patterns such as a core rule set or regular expressions are not customized to recognize threats in the context of the application. For example, with a RASP (runtime application self-protection) solutions, even if the control points are good, the end result will be poor without the right context and detection techniques. This approach is also reactionary and leaves you exposed for some period of time. It is generally ineffective until the signature is developed, and the signature can’t be created until the threat is detected and identified.

    Automation and artificial intelligence (AI) can accelerate the process and provide more effective protection with less friction. An AI-powered platform can learn from stateless traffic and deconstruct application logic to create application-specific rules—and update the rules dynamically without the need for human intervention. Using dynamic, application-specific rules rather than signatures and manual rules can result in efficient detection and an exceptionally low false-positive rate. An automated solution that leverages artificial intelligence also can protect without waiting for signature updates.

    Modern Security for Modern Networks

    The days of periodic scans are long gone. The network architectures and threat landscape today demand constant, real-time protection. Legacy detection techniques are cumbersome and can’t keep pace, but an AI-powered attack detection platform that is automated will be more effective for protecting a dynamic, cloud-based, containerized, DevOps environment.

    — Tony Bradley

  • Self-Service Integration: 3 Areas to Watch

    Self-Service Integration: 3 Areas to Watch

    Self-service integration is a priority—more enterprises are turning to it for help in retaining their customer base, delivering a delightful customer experience and making it easier to do business with. It has become a de facto standard for modern-day integration solutions. Enabling business users to build integrations strategically addresses a dire need to establish a smoother symbiosis between people, processes and technologies; marshal them in an order; and align them with business objectives.

    This approach is taking root across digital economies, and more advanced self-service integration features have emerged over time, which means bare minimum features are no longer enough. Enterprises with basic integration capabilities face the same old IT issues they faced earlier with conventional development tools.

    In this blog, we’ll take a look at three critical features of self-service integration capability that can help enterprises sharpen their edge:

    • Business User Capability: Enables business users to develop integrations and helps IT to drive innovations. Business users get built-in constructs to build integrations with heavy coding and rollouts, while IT can monitor all processes and technologies in a B2B network and avoid potential IT issues. With this advantage, business teams can operationalize data without IT getting involved and reduce time to revenue.
    • Any Data Conversion: Modern-day integration solutions offer AI-led data transformation capabilities to convert data between source and target elements. The solution uses past traffic for suggesting data mapping recommendations and further reducing the time that goes into mapping data. Business users get a single interface to map data between source and target elements. Moreover, they can convert multi-gigabyte data in different formats in few minutes, rather than months.
    • IT Governance: Self-service integration provides a drift-to-drive approach for IT governance. IT teams can combine old and new enterprise information systems and set up a concurrent integration strategy to use them for best of advantage. Start-to-end integration helps IT teams to streamline governance and enables business users to expand B2B connectivity. Teams can connect with a universe of applications without heavy resources involved.

    Factoring these three capabilities in the zero code integration strategy can help teams to improve efficiencies, reduce the IT cost and improve B2B data exchange. They can counteract IT challenges in the form of multiple sources of truth and IT silos in minimum steps.

    These three capabilities can help enterprises in improving  process, people and technologies across business. By using these capabilities, enterprises can acquire knowledge faster and interpret data faster. Physical and digital environments can be populated with heuristic methods. Enterprise networks can be connected for more openness, connectedness, intelligence and scope.

    End-to-end data integration improves the analytics process and drives the decision-making process: Data can be prepared for complex operations without complex coding.

    Additionally, with self-service integration, enterprises don’t have to train citizen data scientists for data integration. Data scientists can use sophisticated functionalities for processing data from multitude of sources, and can re-engineer every piece of integration for syncing data with extremely powerful edge devices. They can establish strong neural networks for setting  up diverse and robust architectures. Such systems can be used for complex use cases such as biometrics optimization, personalized medicine, material sciences and more.

    A self-service integration framework is more than an enterprise service bus (ESB) or SOAP web services integration model. it helps in driving IT innovation, keeping things flexible and reducing costs. Modern- day integration solutions deliver out-of-the-box flexibility and reusability for bringing together composite services and executing them in a particular order across enterprisewide deployments. They help organizations grow their B2B networks and add new partners, suppliers, services and sales and support channels.

    Enterprise information systems today generate massive volumes of data. There is a tsunami of information distributed between different B2B networks. Today’s data is being generated in variety of forms and the workloads have become difficult to predict. This veracity—or the ability to handle uncertainty caused by incompleteness, inconsistencies and anomalies of data—is a major barrier to unlock audience intelligence and customer segmentation in high-density computing.

    Coalescing around a self-service integration strategy around these features is important for enterprises. It can help them in decimating the constraints they face on the road to B2B data integration: IT complexity that steadily decreases the pace of business, and silos that make them difficult to work with and slow down time to revenue.

    — Jitesh Banga