devopsy.kinsta.cloud

Tag: devops adoption

  • Every Business Has Become a Technology Business

    Every Business Has Become a Technology Business

    Contributor: ITSM ACADEMY-Drew Lapatin

     

    Every business has become a technology business.

    Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog), and when should we retire them (retire).  We literally could be an app away from becoming irrelevant.

    It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often.

    By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer requirements more effectively. Normally projects will start with a given set of requirements.  In an Agile project (yes, we are going to use an Agile project format to continue the theme of blending ITIL and DevOps) the product backlog will contain these requirements as user stories, but as we all know those stories/requirements/attributes can change very rapidly. One tool that could help us rank these attributes and ensuring the delight of customers is the Kano model.

    A Kano model shows us there are three different factors in customer satisfaction.

    They are as follows:

    • Basic factors are aspects of the service that have to be in place for the customer to receive the service. They may not offer any obvious value, but if they fail, or are not delivered, customers will become very dissatisfied. These factors are sometimes called ‘must-have utility’ or the very least the service provider can deliver for a particular service.  Basic factors are not responsible for high levels of satisfaction, unless they alone fulfil the customer’s requirements completely.
    • Performance factors are factors that enable a customer to get more of something that they need, or a higher level of service quality. These are the factors that customers are interested in and the price they are willing to pay is directly impacted.  These factors result in customer satisfaction when delivered and customer dissatisfaction when unfulfilled.
    • Excitement factors are attributes of a service that are generous, and which customers do not expect. When they are offered (within reason) they cause higher levels of satisfaction. The service provider is seen to be ‘going the extra mile’. While excitement factors result in the quickest and highest levels of customer satisfaction, they are expensive to maintain, since the service provider is offering more than necessary at the same price. These factors may be exciting, but they are not essential to the service, and are therefore also referred to as ‘nice-to-have utility’. Internal service providers should be careful of introducing excitement factors in the interest of ‘customer satisfaction’ without doing a proper business case to justify the additional costs.

     

    Drew Bio

    — Alice Acedia

  • A DevOps Checklist for Traditional Service Providers

    A DevOps Checklist for Traditional Service Providers

    As companies such as Amazon and Google rapidly innovate to deliver new services, traditional service providers recognize that change is necessary to keep up with shifting customer expectations. Given the pace at which technology continues to morph, creating better, faster and more innovative solutions is a necessity, and if this isn’t achieved, even longtime customers will eventually look elsewhere.

    For younger businesses, taking a collaborative approach to IT and product development often comes naturally as it’s built into the company’s DNA. However, for more established service providers, adapting to this new way of doing business can prove challenging. Traditional service providers have spent years perfecting their technology and require multiple layers of review prior to rollout. While these checks and balances are in place to ensure a level of quality customers have relied on for years and expect to receive from traditional providers, it also can hinder their ability to react quickly to client demands. However, the adoption of the principles embedded in DevOps can allow traditional service providers to work more like a startup by accessing their technology and human skills in a new way, while also continuing to deliver products which meet the expectations of their established customers.

    Now the question is, how can traditional services providers successfully implement this DevOps approach? While it can (and has been) done successfully, there are five critical steps that need to be taken into account:

    1) Establish a clear goal. The most important step is the first: Management must have a clear understanding of what they are looking to accomplish with the DevOps transition. Service providers have a long legacy of well-defined, reliable services, so all changes must complement their current product offerings and live up to the quality their customer base has come to expect. If an overall goal is not defined, customers will be left confused and disappointed, and ultimately, there will be no impact on the bottom line.

    2) Set a timeline. While creating an unrealistic timeline is never advised, it is critical to set an aggressive, pragmatic and adjustable one. As mentioned above, without aggressively pushing forward, an organization will find itself continuously playing catch up to its competitors. The timeline is meant to push an initiative forward even when there are setbacks or changes that need to be made along the way. The right timing is a balancing act: too fast and you have a poorly crafted product rollout; too slow and you are stuck behind the competition. The key metric to measure progress is the degree of evolution to the DevOps model within key stakeholder organizations. If solutions are delayed due to existing processes, then either the scope of the team needs to be adjusted to encompass those processes or the goal needs to be changed so they are no longer an issue.

    3) Collect necessary resources. Typically, the biggest gap that needs to be filled to move forward is with human resources. For many established companies, having design and architecture skills—core capabilities needed to develop a new product—hasn’t been a priority. Creating the right team that consists of new talent that have these missing skills, along with the addition of current employees who have a more intimate understanding of the company and customer, is a critical aspect in making sure this more collaborative and innovative approach to solution development and delivery works. And it doesn’t stop once the team is created, it is important to continue to foster an environment that encourages the new team to work together and promote their process within the broader organization.

    4) Create benchmarks. To ensure the established timeline is being met and that there is an opportunity to change course if necessary, it is important to set clear deliverables at various stages of the process. These benchmarks must look to what people are doing today, not just the end goal. Initial measures should focus on the pace at which progress is being made, and later, focus on the end products being delivered.

    5) Get the entire company on board. Changing an embedded philosophy isn’t easy, especially one that has worked well for so long. No matter the organization there is almost always resistance on some level when fundamental changes are being made. It is up to leadership and the DevOps team(s) to demonstrate internally and externally that the changes being made are not just for the sake of change, but in the end will benefit the entire company, as well as the customer.

    While taking a deeper look at an organization’s “people, process, technology and information” and moving to a new mindset doesn’t happen overnight or come without its hiccups, the status quo is no longer sufficient to compete. The reality is, a more collaborative and faster delivery model is necessary to be successful in tomorrow’s marketplace.

    About the Author / Tim Pearson

    timpearsonTim Pearson is the director of product line management at Ciena. In his role, Tim leverages DevOps practices to break barriers in network delivery to meet the demands of mobile, VR and video applications.  Driven by challenge and fueled by deep industry knowledge, he has built a reputation for developing innovative business and product strategies to drive growth and open new markets. Tim holds a Bachelor degree in Electrical Engineering from Memorial University, a Masters degree in Management Science from the University of Waterloo and an MBA from the MIT Sloan School of Management. Connect with him on LinkedIn and Twitter.

  • Keep Applications Running by Testing Early, Continuously

    Keep Applications Running by Testing Early, Continuously

    Almost every product we buy or use today goes through some form of extensive testing before it’s released on the market; typically, these tests are designed to replicate the worst-case scenarios that a product may encounter under real-world conditions.

    Automobiles, for example, go through extensive hot and cold weather testing in remote locations, and are driven over obstacle-laden tracks designed to push the limits of their durability. Even seemingly mundane objects such as children’s toys are exposed to abusive simulations to ensure that they don’t harbor any potentially hidden and harmful effects.

    On the current landscape, applications are the face of your business, often serving as the battleground where consumer loyalty is won or lost. Given this reality, it seems crazy to think that any applications are released having only been exposed to a minimum of tests. Yet, in the name of getting to market quickly, that’s far too often the case.

    As disciplines including agile and continuous delivery continue to increase the speed at which development teams can release software, it’s easy to put the crunch on testing in the rush to get an update released. But that’s a costly mistake in the long run, as research has shown that it is 50 percent less expensive to find an error in testing than to address the same error once it has reached production, and more than 90 percent cheaper  when addressed in the development/coding phase.

    Given the dramatic cost savings of addressing errors in development, clearly the goal of any organization focused on continuous delivery should be to shift testing left so a greater number of defects are found early in the development process. This is what we refer to as continuous testing, and it’s a huge part of the reason why I am so excited about CA’s acquisition of BlazeMeter.

    Performance load testing should be a core element of any continuous testing strategy because it is a critical factor in determining system reliability. Similar to the worst-case scenario testing that consumer products undergo, performance testing can quickly uncover applications defects that might otherwise go unnoticed. After all, the manner in which a system operates with a few hundred concurrent users may be very different than how it runs with thousands of users.

    BlazeMeter enables today’s development, operations and DevOps teams to conduct this critical performance testing earlier in the development process, saving countless hours and resources. The company is also competing—and winning—in a highly competitive marketplace where it has been pitted against much larger, more entrenched competitors.

    Part of the reason BlazeMeter is winning is its focus on offering a SaaS-based solution that is highly cost-effective and easy to engage. Using this model, customers can try  out the testing software with a few clicks, and then quickly move forward to broadly adopt the system. Another catalyst to its success: BlazeMeter was built using open source tools, such as Apache JMeter, used widely in the development community for performance and load testing. As a result, BlazeMeter can easily run and analyze JMeter and other open source-based load tests—such as Selenium, Gatling and Locust—within a commercial-grade performance testing system.

    This combination of a SaaS delivery model and incorporation of open-source tools, augmenting strong performance testing functionality, make BlazeMeter very complementary to CA’s existing continuous delivery solutions, including its CA Service Virtualization, CA Test Data Manager, CA Agile Requirements Designer and CA Release Automation products.

    At CA, we’re committed to providing the most comprehensive, integrated and open continuous delivery ecosystem, allowing our customers to release swiftly, test agilely and constantly increase reliably. The addition of BlazeMeter will further enable customers test continuously, thereby increasing agility and the overall quality of their software, to ensure that applications don’t break down on the side of the virtual road.

    — Aruna Ravichandran

  • Introducing DevOps Express!

    Introducing DevOps Express!

    The DevOps Institute (DOI) is proud to join industry leaders as a founding member of the DevOps Express. The DevOps Express is a bold initiative between tool providers and others to create a solutions-oriented approach that will make enterprise DevOps adoption easier using popular technologies spanning multiple solution components. Working together, DevOps Express members have committed to improving interoperability within the DevOps stack, and creating a framework for industry partners to develop reference architectures that will be better integrated with better support.

    The 14 founding members of DevOps Express include vendors spanning multiple solution categories in the software delivery process, as well as service organizations providing consulting, training and professional services:

    • CloudBees
    • Sonatype
    • Atlassian
    • BlazeMeter
    • CA Technologies
    • Chef
    • DevOps Institute (DOI)
    • GitHub
    • Infostretch
    • JFrog
    • Puppet
    • Sauce Labs
    • SOASTA
    • SonarSource

    DOI is honored to be a part of this important and innovative program. We believe this initiative represents the industry’s commitment to “walking the DevOps walk” by agreeing to collaborate, align and integrate for the betterment of the market. We are excited that major industry partners are unifying to give enterprises potential starting points for creating a DevOps stack, while also increasing quality and lowering risk. As knowledge, best practices, architectures and models emerge from the work of DevOps Express, DOI will ensure that these are available to the DevOps learning community and embedded into DOI courses, articles and future member benefits.

    The DevOps Express is leaving the station, and DOI is on board! Read the press release for more information about this historic initiative.

  • What DevOps Skills are Organizations Looking for?

    What DevOps Skills are Organizations Looking for?

    DevOps is a cultural, philosophical and organic approach toward automating workflow and getting products to market more efficiently and effectively.

    DevOps engineers are in top demand right now. According to studies by Gartner, 25 percent of top global 2000 organizations will have adopted DevOps as a mainstream strategy by the end of 2016.

    DevOps is both a cultural movement and a philosophy … which can make it difficult to define the specific skill set you need a DevOps team to possess in order to function successfully.

    Of course, an excellent way to show fluency in DevOps is by earning a DevOps Institute certificate—for example, DevOps Foundation®.

    That being said, there are some “mission-critical” DevOps skills that organizations are searching for pretty universally right now.

    1. Experience with infrastructure automation tools and fluency in web languages

    Experience with tools such as Ansible, SaltStack, Puppet, Docker, Chef and Windows PowerShell DSC as well as fluency in languages including Ruby, Python, Java and PHP are must-have skills for DevOps pros.

    Organizations are searching for DevOps candidates who are highly proficient in many of these tools and languages and open to increasing their competencies further when given the opportunity to do so.

    2. Expertise in “soft skills”

    DevOps evolved as a way to enhance collaboration across project life cycles and connect front-end and back-end professionals on either side of the software development and operations spectrum.

    When software developers and operations staff (system engineers, systems admins, DBAs, etc.) collaborate effectively, communicate honestly and work as a cohesive team, the software development life cycle (SDLC) is streamlined, risk factors are mitigated, and projects are completed and deployed with a minimum of bugs, quality defects and glitches.

    In addition, it can be useful for organizations to have DevOps specialists on their team who are comfortable in the role of client consultant, able to interact effectively and build positive business relationships with customers while addressing their needs and wants.

    Organizations look for DevOps candidates who are skilled in interpersonal communication, with an arsenal of listening, negotiation, problem-solving and team-building skills at the ready.

    3. Familiarity with CI (continuous integration) tools

    Continuous integration is a DevOps methodology that continually merges source code updates from all developers on a specific software build, notifying the team of any failures in the process.

    This offers a real-time window into the developing software system, allowing immediate and constant engagement of all team members throughout the project lifecycle.

    CI tools DevOps candidates should be familiar with include CruiseControl, CruiseControl.NET, Jenkins, Bamboo, Hudson, ThoughtWorks’ Go, Urbancode’s Anthill Pro, Microsoft’s Team Foundation Server and Jetbrains’ Team City.

    4. Bonus Skills

    Other skills hiring managers are on the lookout for in the DevOps space include:

    • Extensive knowledge of software build cycles
    • Experience deploying code
    • Experience in software architecture
    • Familiarity with application programming
    • Database management
    • System design

    Useful experience and certifications include:

    • Project Management
    • Risk Management
    • Scrum Master

    The good news is that the industry’s need for DevOps team members with diverse and evolving skill sets is in sync with what DevOps candidates want from their workplace. According to the 2014 State of DevOps Report from Puppet Labs, an atmosphere conducive to learning is a primary component of job satisfaction among DevOps engineers.

    About the Author / Robin Borough

    Robin BoroughRobin Borough is President of Omnikron Systems, Inc., which offers IT and management training and IT staffing services. As an advisor to technology professionals and executives for over 25 years, Robin has built a world-class reputation as a “go to” career strategist in the IT industry, one who’s capable of successfully guiding executives and specialists, at any level, through transition. 

  • The DevOps Devil is in the RFP Details

    The DevOps Devil is in the RFP Details

    The request for proposal (RFP) process in IT outsourcing is, at its best, a challenging, time-consuming process rife with pitfalls for both customers and outsourcing providers. The process is made even more complicated if customers are unable to provide clear and detailed requirements because of haste or inexperience in software development outsourcing.

    In my work matching companies that need to outsource their software development to international partners, I’ve seen this particular challenge, where less mature customers do not offer potential partners enough of the needed detail in the RFP process for determining an accurate estimate. The question remains, What is the best way to navigate a situation like this?

    There are two key considerations at the very start. First, because IT outsourcing can mean several types of services, including help desk, cloud enablement, network monitoring, etc., outsourcing of custom software development is a type of IT outsourcing that has specific best practices for engagement, methodology and process. Second, I recommend dropping the word “vendor” from your lexicon to refer to a company you hire for custom software development; instead, use the term “partner.” In my experience, treating your software outsourcing partner like a vendor inevitably leads to an adversarial relationship that shuts down creativity and innovation. For software development outsourcing to work, it is absolutely critical to maintain good communication between equal partners. A good working relationship cannot be underappreciated as a key element of success.

    From the provider perspective, there is no ethical way to respond to an RFP that lacks details with an accurate time estimate and cost quote. Any proposal offered should be for a discovery phase, where the service provider uncovers the details the customer is unable to provide on its own. The customer can use the deliverable from a discovery phase to have a more realistic discussion with multiple service providers and receive credible proposals. If the prospective customer is unwilling to pay for the discovery phase or provide the required details, then the service provider should turn down the opportunity.

    From the customer perspective, the answer to the question of how to resolve unclear requirements, then, is to require that the contract governing the relationship be for a dedicated agile development team that can start developing software as the highest priority requirements are defined. The team may grow or shrink over time to accommodate changing priorities, and the release plan can be updated every three or four sprints as you learn more about the requirements and what users want.

    The customer should be prepared to commit contractually to providing a dedicated, easily accessible and available product owner to resolve questions and issues quickly. A “local” product owner can also be on the outsourced team to facilitate communication when developing apps with complex software requirements, but he or she should not be considered a replacement for the customer’s product owner.

    The provider, then, should be prepared to provide at a minimum:

    • Team ramp-up time
    • Monthly rates per developer at various levels of seniority
    • Historical retention or attrition rates of team members
    • References to other customers using similar software technologies and/or domain experiences for what is needed for a particular project
    • For customer experienced with agile development, an estimated velocity of story points per sprint

    An additional challenge from the client perspective is to be able to define the IT outsourcing speed that is needed for the task at hand. The recent concept of two-speed IT defines two kinds of IT software development—slow and fast. Each kind can be outsourced, but with different types of service providers.

    Slow IT outsourcing is most typically used for the careful update of legacy software systems that are changed slowly over months and years to maintain the stability of the business. Fast IT outsourcing is most frequently used for product development and digital transformation and requires an agile approach that includes UX design, user testing, development and DevOps. By recognizing the distinction between fast and slow IT outsourcing speed approaches, you’ll be able to select a partner company with the right experience.

    By abiding by a few key parameters, customers and providers alike can make the RFP process a constructive and productive experience. While it’s true that customers always seek the best possible deal in an outsourcing bid, they don’t always offer the information required during the RFP process to help providers meet their needs. An RFP should be viewed as an opportunity to build a relationship, rather than executing a transaction, and a commitment by both customer and provider to trust and transparency will go a long way toward long-term success.

    About the Author / Steve Mezak

    steve.005Steve Mezak is CEO of Accelerance, a Silicon Valley firm that, since 2001, has matched hundreds of U.S. companies needing software development with international, outsourcing partners. Steve has more than 30 years of experience in the IT industry, from writing software code to facilitating and managing software development teams. He’s authored two books, including most recently, “Outsource or Else! How a VP of Software Saved His Company” (June 1, 2016). Contact Steve by email: steve@accelerance.com; or Twitter: @SteveMezak.

  • Iterative Indicators: Measuring DevOps ROI

    Iterative Indicators: Measuring DevOps ROI

    It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.

    The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.

    At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.

    For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.

    With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.

    That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.

    For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.

    Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.

    The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.

    As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.

    Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.

    Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.

    If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.

    Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.

  • State of DevOps Report: Reaping Results

    State of DevOps Report: Reaping Results

    The newly released 2016 State of DevOps Report concludes that DevOps is “no longer a mere fad or buzzword,” but rather an established set of practices and cultural patterns. Yet, a closer look at this year’s findings reveals progress is far more substantial than any matters of perception.

    The report was conducted and analyzed by the experts of DevOps Research and Assessment (DORA) and sponsored by CA Technologies. Among its findings is proof that high-performing organizations that have embraced agile and DevOps methodologies deeply are outperforming massively those that have not. And the gap is widening.

    The State of DevOps Report also shows leading DevOps practitioners are appreciating benefits that span nearly every area of their business. If I know my colleague Gene Kim, he will assert this point exuberantly on our upcoming State of DevOps Report Webcast.

    It’s noteworthy that high performers are surpassing incredible milestones related to core elements of the applications life cycle. Examples include deploying code 200 times more frequently than low performers, driving 2,555 times faster lead times, 24 times faster recovery times and producing three times lower change failure rates. This is evidence that DevOps is having the desired outcome on applications delivery, software quality and organizational velocity. It also shows organizations truly committed to wholesale transformation of culture and process are actively succeeding.

    At the same time, the State of DevOps Report shows employees working at organizations enjoying this success are more satisfied with their jobs and more closely engaged with their companies. Chalk this up to the halo effect of operating in a fundamentally more sensible, innovative fashion. Cultural change is undoubtedly the greatest hurdle to DevOps advancement. Here’s proof that if you can navigate the process, your workers will be happier and more productive.

    Using Employee Net Promoter Score (eNPS) as a barometer, the report finds that employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work. They also were 1.8 times more likely to recommend their team as a great working environment. Previous studies have found that such an air of positivity can be directly correlated with improved business outcomes, researchers noted.

    Shifting the manner in which you build applications to better adapt to changing customer expectations is a necessity. That’s what began driving this movement years ago. That said, proof it also makes it easier to keep valued software engineering and IT operations employees should not be overlooked.

    In addition to positive conclusions on the impact of continuous delivery and improvement of test data management, the report offers some important metrics related to return on investment. This is nothing short of landmark, as for decades we have struggled to make a hard case for IT investment beyond implied competitive advantage. It actually was impressive that last year’s report highlighted such a “predictive relationship between IT performance and organizational performance.”

    One such new measurement of note is that high-performing teams occupy the least amount of time responding to unplanned work and rework—efforts widely recognized to be results of flawed processes. On a related note, DevOps leaders spend 49 percent of their time on new work‚ surely, in many cases, the next “must-have” feature which impacts competitive standing and, ultimately, the bottom line.

    This report is fantastic. It reaffirms powerfully that so many of the promises made about DevOps over the last few years are neither hype, nor overstated. The gap between the leaders and laggards is growing. Industry landscapes and business models are being redefined.

    This is critical transformational work that every organization must adopt to survive.

    Are you on board? Download the full State of DevOps Report here.

  • DevOps Matchmaking: APM + CI = A Perfect Marriage

    DevOps Matchmaking: APM + CI = A Perfect Marriage

    As anyone who has ever been set up on blind dates by friends can attest, finding the right match in today’s world is a tricky feat.

    There’s a lot of evidence suggesting that the frantic pace of life makes such matchmaking more difficult than ever. That said, when the right set of complimentary traits exist and there’s a willingness to find common ground, things can work out.

    Spike Jonzian-notions of artificial intelligence aside, certain technological partnerships are increasingly being perceived as “a perfect marriage” within the context of DevOps automation.

    Register today for the upcoming webcast: “Using APM to Turbocharge Continuous Integration”

    These technological matrimonies closely support the underlying tenets of DevOps methodology—collaboration, experimentation and increased velocity. In fact, it’s easy to wonder why no one ever conjoined them before. But we were using traditional waterfall development and operations and so couldn’t conceive of such a thing. On the other hand, emerging availability of tooling supporting new integrated workflows represents a significant catalyst.

    Finding the Perfect Fit

    One such DevOps confederation getting a lot of attention is the matchmaking of continuous integration (CI) and application performance management (APM) technologies. Tying together these once-disparate systems makes a lot of sense, despite the fact that few tools would seemingly appeal to more (traditionally) polarized constituencies.

    Continuous integration has been a staple of the development community for many years. It emerged as teams evolved the practice of long build times into more frequent check-ins to deliver code and look for potential errors more quickly. Today, with the rise of CI tools such as the Cloudbees Jenkins platform, some development teams are touting tens of thousands of builds per day.

    On the other end of the spectrum, squarely on the turf of IT operations, APM has been evolving rapidly over the past few years as organizations have sought to improve use experience and applications reliability via dedicated monitoring. Enabling this ability to identify and address emerging issues has resulted in APM becoming the fastest-growing segment in the IT ops management market, according to Gartner.

    DevOps matchmaking factors in when you bring these tools together to create an automated workflow that spans their respective use cases. A cross-functional team can leverage APM-level monitoring and KPIs within the domain of CI and testing to identify potential performance obstacles introduced in new code. Doing so then rather than waiting to respond later in the applications life cycle benefits everyone.

    Reaping the Benefits

    For example, say an e-commerce applications developer has implemented a new inventory search functionality—something considered a key differentiator by business management. The developer knows this feature could rely heavily on some back-end database system and wants to ensure it’s tested properly, even as the code is being introduced.

    Integrating APM and CI allows the entire team to monitor the process and test various conditions related to the update, tracking multiple builds and looking out for related performance issues. Such integration also allows for centralized tracking of other key attributes such as build number, status and build date, to further ease management.

    Most importantly, by tying these two critical aspects of the applications delivery life cycle together, the collaboration and feedback loops required to truly embrace DevOps methodology become ever more valuable as these core Dev and Ops functions become intrinsically linked.

    If this type of DevOps advancement gets your heart pumping, you’re not alone. Later this month, we’ll host a webcast here on devopsy.kinsta.cloud featuring experts from CA Technologies and Cloudbees. They’ll be discussing the benefits of matchmaking with APM + CI integration. They’ll also detail real-world benefits organizations leveraging integration of our respective technologies (CA APM and Cloudbees Jenkins) enjoy.

    We obviously feel that this is a DevOps tooling marriage that will mature, change and stand the test of time. We’d love to garner your questions and feedback on the topic.

    Which is all good, because thankfully there’s no such thing as Tinder for DevOps … yet.

  • Simulation: The ‘Aha’ Moment for DevOps Adoption

    Simulation: The ‘Aha’ Moment for DevOps Adoption

    Every IT transformation requires that people, process and technology align and work together to achieve success. As organizations begin to appreciate the benefits of a DevOps approach and look to change to a DevOps model of software development and release, there will be significant pressure on people, process and technology to support that change properly.

    The technology and process changes required to enable DevOps to work efficiently shouldn’t be underestimated. Considerable time and investment is required in embracing the automation technologies that support a proper DevOps environment, and in developing the processes that make best use of that technology.

    But DevOps cannot work unless your people are ready to change. Development teams and IT operations—who traditionally have worked in silos—must work together, integrate seamlessly and understand not only their roles and responsibilities within the new environment but also the roles and responsibilities of those around them.

    And therefore, like every change, the real key to success is your people.

    Creating Successful Change

    The benefits of taking a DevOps approach are numerous: By moving toward more frequent delivery with reduced elements of change, you lower risk and increase system stability. Although automation is costly to implement, it allows teams to work far more efficiently, increases reuse, reduces errors and brings development teams closer to the customer. New functionality released continually and rapidly can be validated in the market, feedback can be received, lessons can be learned and improvements implemented quickly.

    But in making such a radical cultural shift, how do you ensure you change the mindset of people who have been used to working in a certain way? How do you provide your people with the helicopter view of what that future state will be, instill in them your fervor for change and provide them with the understanding and motivation necessary to embrace new ways of working? How do you ensure everyone is rowing in the same direction? Because without that, your change—already difficult and challenging—will become impossible.

    The Key to Change

    The key to any successful change is communicating your vision to your people. But providing your staff with a clear vision of what that future state could be is enormously difficult. You can outline the benefits of change, explain to them what good will look like, tell them what is in it for them, and all of these are hugely important.

    But there is no substitute for allowing people to actually feel what your future state will be like.

    Nothing compares to parachuting them into a situation where they can work through the changes required in a risk-free environment, experience the pitfalls and live the successes. As you move them to a fully functioning and productive DevOps environment, you will accelerate buy-in from your team rapidly, and give them a much more profound understanding of your vision and future state.

    The Power of Simulation

    Simulation training is one of the most effective tools to explain complex concepts and operating models quickly and convincingly. A presentation on DevOps—or almost any other topic—is not a productive method of showing someone the difference it can make to their work or their business. It’s the difference between reading a script and performing a play. More and more, companies are using simulation training as a shortcut to inform, educate and convince their teams of the value of large-scale organizational change—and DevOps is a prime example. 

    One of the key benefits of the simulation model is that people learn together. Your team learns at the same pace, working toward the same goals—and, as a result, they collectively show each other the value of change. With a traditional change program you need each employee to go on his or her own journey to recognize and adopt your vision. With a group simulation you take everyone present down the road toward a collective “aha” moment. Once that moment has happened you have an instant group of advocates who can go out to the business together and begin to effect change on a much more fundamental level.

    Simulation Brings Agility to Adoption

    Providing a simulated environment in which to train is not new; it has been used extensively and successfully by the military for decades. Commercial pilots train on simulators to provide them with as close to a real-world experience as possible of some of the life and death decisions they may need to make in an emergency. They understand the power of experiential learning.

    Simulating a DevOps model brings that power of experiential learning to your business, allowing you to immerse your people in a concentrated and deeply focused environment where they face the same challenges as they will in the real world.

    In one short morning they get to experience building a culture of DevOps themselves, making mistakes, understanding them and learning from them. It demonstrates the business value and positive impact of a DevOps approach in only a few hours, and can accelerate the adoption of DevOps across the enterprise, successfully turning DevOps opponents into advocates.

    In a world where the quality of your software can make or break your organization, it is critical to create an environment where developers and operations are not only aligned and more efficient, but also empowered and able to concentrate on developing and releasing products that add the most value to the business.

    Rome wasn’t built in a day, and you can’t effect convincing organizational change in a single morning. However, by immersing your team in a simulation, you can take a giant step forward and create a team of advocates who will go out and sell your vision for you.

    About the Author/Andrew Macintosh

    A_Macintosh_PhotoAndrew Macintosh is a Creative Solutions Director for G2G3. He works with clients across the globe, helping to understand requirements and craft technology based solutions to engage staff and customers, internally and externally. Prior to joining G2G3 Andrew ran a production company and worked within the TV industry for 12 years.