devopsy.kinsta.cloud

Tag: devops

  • Forecasting Culture: Sunny with Accumulating Collaboration

    Forecasting Culture: Sunny with Accumulating Collaboration

    Bryson Koehler believes the most important enabling factor for DevOps success is culture.

    Koehler is CTO of IBM’s newly formed Watson and Cloud Platform group. Prior to this role, he served as executive vice president, distinguished engineer and CIO/CTO of The Weather Company (TWC), an IBM business since 2016. He has a record of successfully leading significant business transformations and underlying cultural transformations, which he maintains in tech companies must be incited first at the developer level. As such, while at TWC Koehler built a DevOps culture and practice that encourages transparency, accountability and collaboration, and it is his mission to replicate the successful model in the transformation of IBM’s culture.

    Since I experienced some of the TWC culture firsthand, I asked if he would be willing to share his thoughts on enabling a high-performing culture as well as maintaining that culture during periods of rapid growth or change.

    He started the interview with a theme clearly central to his core ideology as a transformational leader, and one of TWC’s key factors for success:

    Culturally, the goal is to find people who really love what they do. I want people to wake up in the morning and love what they do—not tolerate it, not like it, but love it. We work very hard to find people who love what we do and love the mission we are on. If you work very hard to assemble a team that loves what they do, the culture will take care of itself as long as you enable it … it’s about enabling them, with as much freedom and flexibility as possible, while still maintaining some level of consistency and control. It’s a balancing act and at TWC we worked very hard to give the right tools that enable people to work on any device, anywhere, at any time. The tools were an enabler; it was the culture that really invented itself based on the fact that we hired people who love what they do.

    Koehler’s commitment to finding the right people with the skills and passion consistent with his company’s mission put the base focus of enabling DevOps practices where it needs to be—with the people.

    For those that have read some of my other blogs, one of the things I’ve written about before is the mistake of choosing tools without first addressing the critical underlying aspects of DevOps including, a solid agile foundation and the cultural changes required to facilitate DevOps practices. Needless to say, Koehler’s comments about tools being an enabler really resonated with me because it was clear he still views the tooling as very important but puts the real emphasis on having the right people. The other key message that really resonated with me during the interview was his commitment to accountability and transparency:

    … from a leadership perspective, it’s around making sure there is clear accountability. There is single-person accountability for work. If you walk into a meeting and you don’t know who the single decision maker is in the meeting, my recommendation to the team is to leave. Don’t have the meeting, because it’s a waste of time. There should be one person that everyone knows is the decision maker, whatever the topic. If we don’t know that, then it’s my job to make sure I make that crystal clear. You can’t walk into a meeting with five people all thinking they own the decision when also working to create a culture with high velocity, high throughput and high passion towards meeting objectives and getting stuff done. You hire people who love what they do, you enable them with great tools, you have crystal-clear accountability and decision-making so that things can get decided quickly and that we know who is accountable for making sure that decision was successful, and then constantly work against the goals of the business. You also have to be very willing to adjust your tools, very willing to adjust your people, and very willing to adjust your decision-making. We must be constantly willing to look at ourselves and figure out how we improve.

    Koehler’s willingness to continuously look inward and adjust what is not working demonstrates another key success factor for high-performing DevOps teams. Having an executive driving that culture of continuous improvement is critical for DevOps success.

    He also is dedicated to core agile principles that allow for flexibility and responsiveness while maintaining some degree of focus and clear prioritization. With the rapid TWC growth, we also discussed how he maintained and adapted the existing culture in response to that growth:

    It’s really critical for me as a leader to stay very in tune with how these teams work and function, calling out any bad behavior and correcting it quickly. I’m just as willing to roll up my sleeves and get dirty as the next guy, and I expect everyone else to do the same. Kingdom building is not something that will get you very far in how we work. If you do that [roll up your sleeves], then as part of your culture, everyone puts down their guard and realizes that nobody is any more or less important than anyone else. We are all here to accomplish the same thing.

    Common goals and people that love what they do! It’s a great mix and Koehler has some fascinating perspectives on driving cultural transformation in support of DevOps practices, not only for the efforts he successfully led at TWC but for the efforts he will continue to lead within IBM. His commitment to culture can best be wrapped up by one of his final comments:

    None of our great technical ideas has any chance of seeing the light of day if we don’t get the culture right.

    Thank you again to @brysonkoehler for the interview and insight into TWC’s amazing culture and your vision for IBM!

    About the Author / Bryson Koehler and Shelbee Smith-Eigenbrode

    Bryson Koehler is CTO, IBM Watson & IBM Cloud – GM & Distinguished Engineer at IBM Connect with Bryson on LinkedIn and Twitter

     

    Shelbee Smith-Eigenbrode is a Senior Software Engineer/IT Architect at IBM and has been in IT for 19 years.  She has worked across varying roles spanning the software development lifecycle.  Her experience across functional roles as well as performing that work deeply inside traditional silos has contributed to her passion for embracing the DevOps culture and transforming the way teams are delivering technologies by adopting DevOps practices.  She is a member of the IBM Academy of Technology as well as an IBM Master Inventor committed to driving innovation and technical advancement. Connect with me on Twitter @Shelbee_SE.

     

     

  • DevOps is More Than Just Automation

    DevOps is More Than Just Automation

    DevOps is a lot of things. What DevOps is, what DevOps does and how an organization adopts and implements DevOps tools and practices are largely subjective, but there are some foundational elements that are fairly ubiquitous. One of which is automation. As pervasive as it is, though, DevOps is not automation and automation is not DevOps.

    The Preface of “The DevOps Handbook” lists a number of prevailing myths about DevOps, including the idea that DevOps is just “infrastructure as code” or automation. The book goes on to explain:

    While many of the DevOps patterns shown in this book require automation, DevOps also requires cultural norms and an architecture that allows for the shared goals to be achieved throughout the IT value stream. This goes far beyond just automation.

    The book also shares an anecdotal quote from technology executive Christopher Little: “DevOps isn’t about automation, just as astronomy isn’t about telescopes.”

    I prefer a golf analogy. If DevOps is the game of golf, then automation is like the putter. The game itself may be played for different reasons by different individuals—exercise, competition, just to get out and enjoy nature—but the fundamentals are the same no matter what the ultimate goal is. There is a wide variety of clubs available and strategies that can be employed to get the ball from tee to green, at which point the putter is somewhat indispensable. It is technically possible to tap the ball in using some other club, but everyone will agree that the putter is the best tool for the job. As necessary as a putter may be, though, the putter is not golf and golf is not the putter.

    The important thing to remember is that automation is simply a tool or method for achieving the goal. It, like any other facet of DevOps, has to be part of a broader cultural shift and mindset.

    It was about a year ago that I theorized that microservices could make the “Ops” in DevOps obsolete. If everything—infrastructure included—can be implemented in code and automated, will we still need people to be involved? The answer then—and now—is yes, because DevOps is about more than just automation. Its evolution is to one of enabler rather than job-killer. As more functions are automated, people can focus on bigger and deeper issues and create new innovations instead of focusing on mundane, repeatable tasks.

    You can’t do astronomy effectively without a telescope, and you can’t play golf effectively without a putter. Similarly, you can’t effectively do DevOps without automation—but it is theoretically possible, because it is just one element of DevOps.

    I can’t imagine why anyone would want to do DevOps without automation, though. It wouldn’t make any sense—like trying to look at the stars without a telescope, or sink a golf ball from 18 feet with an 8-iron. Although DevOps is more than just automation, the most effective and efficient way to succeed at DevOps is to automate everything that can be automated so you can stay focused on the big picture.

    — Tony Bradley

  • DevOps by the Book in 2017: Where we Really Stand

    DevOps by the Book in 2017: Where we Really Stand

    Now that the year-end prediction season is over, it’s time to focus squarely on the actual here and now—where the DevOps movement actually stands at the start of 2017.

    As we’ll need to wait another six months or so for the annual State of DevOps Report to emerge from the good folks over at DORA and IT Revolution, which forces us to take stock of the situation using other resources. In this case, I’ll point to the recently released book, “DevOps for Digital Leaders,” authored by my colleague Aruna Ravichandran along with co-authors Kieran Taylor and Peter Waterhouse.

    Register today for the upcoming webcast, “Chart a Winning Course: DevOps for Digital Leaders,” and enter the chance to win a free signed copy of the book [U.S. only].

    Why should you value this book over any of the other DevOps-related titles inundating the technology literature scene, in particular those issued by (gasp!) technology vendors? I’d cite two very specific reasons: real-world metrics and use cases.

    I often preview any comments I make in cross-functional meetings with the phrase “shameless marketing.” That is because I work in marketing. For 12-plus years prior and sometimes in between marketing gigs I’ve served as a journalist, wherein my job was to attempt to be as objective as possible. Today, I work for a vendor that would really like to sell you stuff.

    That said, this current career path does not preclude me from being able to see beyond my own not-so-secret agenda. While many onlookers understandably groan and roll their eyes at the manner in which DevOps has been co-opted by marketers as a means to advance products, this doesn’t mean we’re all full of it.

    Like myself, working at CA—in particular, leading marketing efforts that span a huge array of strategic technologies actively being leveraged by global enterprises to attack various elements of DevOps—has given Aruna and her partners tremendous insight into where many people stand in terms of maturity.

    To that end, this book is written around some fantastic stories about how some of these organizations are refining best practices and measuring real success in domains including continuous testing, release automation and shift-left monitoring. IMHO, these are some of the hottest areas of DevOps being advanced as we speak.

    In addition to these use cases and related practices, the book takes an up-close look at critical aspects of the DevOps build, test, deploy and manage stages, along with key processes related to tuning and continuous improvement. And it even goes so far as to talk about essential DevOps tooling. I hope people are ready to acknowledge that beyond culture and leadership, automation absolutely plays a significant role in all of this.

    Specific to metrics, one of the areas where the State of DevOps peeps attempted to break new ground in the 2016 report, there’s a lot to appreciate. The book takes a close look at how these same organizations are attempting to tie DevOps-driven change directly to ROI, including the all-important customer experience.

    Worth noting, in the coming days we’ll also see the release of a new report from Coleman Parkes that charts numerous KPIs being used to this same end, so stay tuned.

    So there you have it, the marketer has officially hijacked this blog space to do little more than market a book about DevOps written by marketers. But, the truth is that’s not all.

    If you really want to hear the best parts of this story, sign up for the upcoming devopsy.kinsta.cloud webcast, “Chart a Winning Course: DevOps for Digital Leaders,” in which Aruna and Alan Shimel will discuss the high points, with an emphasis on fielding questions from the audience live Q&A style.

    If you don’t have time to read the book—or, better yet, you want a preview to ensure that what I’ve written here is true—post up and ask your own questions. We’ll also be conducting live polls about DevOps maturity, audience use cases and the leading types of DevOps metrics.

    It’s worth noting that all proceeds from the print edition will go to Foundation for Excellence, which provides STEM scholarships to children in India. Order your own copy today (or download it for free).

    — Matt Hines

  • Automation: Achieving Faster Rollouts with Better Accuracy

    Automation: Achieving Faster Rollouts with Better Accuracy

    A changing landscape requires new processes

    At the recent Symposium/ITxpo, Gartner shared a list of technologies and trends that will be important for organizations to embrace and prepare for in 2017. These trends, which are listed in the report, “Top Strategic Predictions for 2017 and Beyond: Surviving the Storm Winds of Digital Disruption,” reinforce the breadth of technology that IT must support, roll out and engage with. This includes everything from the 100 million consumers who will shop using augmented reality to dealing with the roughly 21 billion endpoints expected to be in use in 2020.

    The report also demonstrates how fast technology changes directions. For example, Gartner predicts that in 2019, 20 percent of brands are expected to abandon their mobile apps. “Many brands are finding that the level of adoption, customer engagement and return on investment (ROI) delivered by their mobile applications are significantly less than the expectations that underpinned their app investment,” the report notes. However, this doesn’t mean less work. IT departments continuously have shift gears to support new processes, news apps and new technologies, such as the Internet of Things (IoT) and the massive amount of data that it produces.

    The dynamic needs of today’s businesses are driving organizations to increasingly adopt new technologies and applications that oftentimes don’t play nice with the existing set of infrastructure and legacy systems in place. So, while it’s clear that the technology landscape is changing, what isn’t so obvious is how IT and business decision makers should be adapting to an industry that is in constant motion.

    In-Steps DevOps

    To keep up, IT must implement agile methodologies that can adapt quickly to market changes. The DevOps mentality is making its way into many organizations and involves the development team creating, building and evolving products to ensure the organization is up to date, while the operations team confirms everything is running smoothly prior to a launch going live. This level of checks and balances isn’t just a nice to have, it’s a necessity—one mistake and the entire system can be brought down. Fostering a greater level of collaboration between development and operations makes it possible to efficiently and effectively build, test and correct new features and new products.

    While the shift to a more collaborative environment between the Dev and Ops teams can take time, using modern IT automation solutions can make this transition easier. Such solutions automate many of the routine—and even not so routine—elements of the application release process within DevOps. Many of the actions necessary to move from code to production—not to mention maintenance, testing and cleanup tasks—can be taken off the backs of developers and operations, saving them time so they can focus on higher-level projects and reduce manual errors.

    Finding the Balance Between Speed and Accuracy

    In 2012, Facebook announced it was increasing the speed at which it released code to twice a day, every day. As Chuck Rossi, director of Release Engineering at Facebook said, his team follows the advice “ship early and ship often.” Facebook continues to follow this model, and while the company certainly didn’t invent it, the model has caught on and is spreading among companies developing virtually every type of technology. The catch? It’s an incredibly time-intensive process and not every company has the resources necessary for a dedicated release team. Plus, a true shift to DevOps doesn’t happen overnight, especially since there is a ramp-up time for folks to get on board. For example, Phil Dibowitz, systems engineer at Facebook, told TechTarget that it “led its Chef team through a three-year process to rethink configuration management to scale on par with the web-scale company’s data centers.”  This took three years, he said, “not because of the technological change, but because of the structural change.”

    A slow transition to a new technology or new way of operating is a common occurrence because historically the production systems are cordoned off from development groups. While the Ops team has to ensure the rollout will meet certain standards, the Dev team wants to speed the process to begin the final rollout process as soon as possible. A happy medium exists, but if it isn’t found, things can go very wrong. Unfortunately, 2015 gave us two major examples of what can go wrong if products can’t speak to each other and rollouts are completed too early: Remember the New York Stock Exchange and United debacles?

    Breaking Constraints Through Automation

    This is where modern workload automation comes into play. Automation and solid change management allows IT to flexibly add on new technologies with automated processes for building, testing, upgrading and configuring IT—all while reducing the slack time between various steps. For instance, a workload automation solution should be able to trigger a build, deploy the build to the test environment, run the test suite and, assuming testing meets acceptable criteria, promote the build to production. If something does go wrong, necessary remediation can occur, and through monitoring and alerting capabilities, the required parties can be notified proactively.

    Additionally, automation solutions with pre-built integrations make it easier for disparate applications to communicate, creating an end-to-end approach to workflow creation and maintenance. As a result, IT organizations can minimize the risk of business disruptions and achieve a more fluid technology delivery to the business.

    Although it’s not a silver bullet that will solve all DevOps transition issues, automation does reduce manual intervention, which leads to fewer delays and errors and improves speed at which tasks are completed. However, beyond the technological aspects, there must be a clear understanding by both sides (the Dev and Ops group) on what their counterparts need—and this requires a high level of trust and coordination.

    While the specifics around the DevOps methodology certainly will change, automation will remain a critical piece of the process. With IT automaton, DevOps teams are able to refocus on critical IT business and operational processes, thereby reducing delays, decreasing errors and improving the speed at which tasks are completed. Ultimately, automation makes it possible to increase the speed of product releases and enable companies to stay ahead in the age of unpredictable customer preferences and ever-changing technological developments.

    About the Author / Mehul Amin

    Mehul Amin, a 21-year veteran of Advanced Systems Concepts Inc. (ASCI), previously held roles as product engineer and technical support manager and played an integral part in building the company’s workload automation solution, ActiveBatch. In his current role as director of Engineering, Mehul drives high-profile initiatives and leads both the Product Engineering and Release Engineering teams. Mehul received a master’s in computer science from the Stevens Institute of Technology.

  • Time, Training: How to Implement DevOps Effectively

    Time, Training: How to Implement DevOps Effectively

    Successful implementation of DevOps solutions requires two very important investments: time and training.

    New technologies have always transformed how the commercial world operates. The steam engine for example, fueled the industrial revolution of the 18th century and changed the face of business forever. This dramatic shift didn’t happen overnight, though; people had to learn new skills to manage steam power and operate trains, ships and equipment that previously did not exist.

    Adopting a new system within a modern day organization is no less challenging. It takes in-house expertise and top-down leadership to crest the learning curve as quickly as possible.

    Training Your People

    To realize the benefits of DevOps, businesses need people—particularly, system administrators and their managers, who know how to operate the systems. It really is that simple, yet most companies just don’t have the skills. Training, training and more training, coupled with lots of hard work and practice, is paramount.

    Middle managers in charge of integrating the new systems are first in line for training. They deal directly with upper management as well as with the new software’s end users. To communicate the importance of DevOps to both audiences successfully, they need to understand exactly what DevOps can achieve—and how to get it up and running in line with the company’s wider business goals. They need to know what skills are needed to implement DevOps companywide and identify the right people to learn the ropes quickly and efficiently.

    Push from the Top

    A successful switch to DevOps also is dependent on support and buy-in from upper management. They don’t necessarily need to have an in-depth knowledge of the systems, but they do need to push for fast and effective implementation—and allocate the resources to make it happen. With all key stakeholders working together to reach the same realistic timelines and deadlines, the new systems will be introduced far more seamlessly. If the process is at all disruptive, people will be reluctant to change their way of working and do things the same way they always have.

    Senior management must support the system change and encourage its use across the organization by openly embracing its potential.

    Test the System

    Traditionally, implementing a new production system was a long, onerous process with lots of restrictions and administrative hurdles to jump. In many instances, a committee of key stakeholders was needed to verify and approve each step. Forms had to be filled out, a thorough backup plan would be prepared and a bureaucratic chain of command would be followed. The further removed from the actual implementation project each signatory was, the less committed they were—which often led to repetitive meetings and costly delays.

    This labor-intensive change management approval process was in place to help prevent any failing in the production plan, which could have disastrous effects. Should for example, an online retailer’s check-out or internet banking infrastructure go down, business profits and reputation would suffer significantly.

    Implementing DevOps is different. It uses a test environment to speed up the onboarding process and minimize errors. IT engineers can do dry-runs before going live to check how the new systems are integrating and if anything is wrong before it actually does go wrong. Bugs and glitches are fixed without impacting the current systems and the approval process is far faster and much more confident. All of which can speed the entire implementation process and its success.

    The potential of DevOps is inextricably linked to the people who implement and operate the new systems as well as the old. To achieve the best possible outcome, your team needs to have the experience and skills to ensure a seamless integration that enhances core business functions without losing or disrupting the organization as a whole.

    About the Author / Francis Miers

    Francis Miers is a Director at Automation Consultants – Automation Consultants (AC) is an IT services and software company with a mission to improve the speed and reduce the cost of IT project deployment by implementing automation across the software life cycle. AC develops and deploys advanced software automation solutions. Customers include BskyB, HSBC, Invensys, Orange, EverythingEverwhere and Vodafone.

     

  • DevOps Leaders Share 2017 Reflections, Predictions

    DevOps Leaders Share 2017 Reflections, Predictions

    As the New Year kicks off, it is a time for reflection and a chance to look ahead and plan for what is to come. While many are making personal resolutions pertaining to their physique, job performance or travel plans, there is a lot of chatter in the software delivery space around what DevOps will look like these next 12 months.

    Looking back on 2016, suffice to say it was a big year for DevOps. There was no lack of resources for those in any phase of a transformation, with global conferences touting its name to weekly (if not daily) podcasts and webinars designed to share the latest expertise with the community. However, as DevOps moves from buzzword to phenomenon, it will be held to even higher standards and scrutiny, becoming ever-more polished and perfected as challenges are faced and overcome. But don’t just take my word for it.

    Electric Cloud recently hosted a live, online video podcast featuring notable DevOps luminaries discussing their own reflections and conjectures. The panel included Nicole Forsgren, CEO and chief scientist at DORA; Robert Stroud, principal analyst at Forrester; Chris Riley, analyst at fixate.io; Manuel Pais, author at InfoQ and SkeltonThatcher; Alan Shimel, editor in chief at devopsy.kinsta.cloud; Sam Fell, VP of Marketing at Electric Cloud; and yours truly. This article highlights 16 different insights from our discussion with these great minds in DevOps. Here’s to what has been, and what is to come!

    • Expect to see a trend toward strategic DevOps transformations in 2017, according to Forsgren: “I think there’s going to be a huge trend moving forward to do really careful and strategic assessments about where you are, intentional prioritization and strategy about understanding what your constraints are, so that you can do strategic capabilities development moving forward.”
    • Riley hopes 2017 will be the year we stop talking about DevOps and start doing it: “In 2017, we’re going to stop defining DevOps, and we’re going to hopefully use the word a lot less. We’re going to be real about what it is and getting it done. It’s going to be a lot less talk and more doing.”
    • I emphasized that having good architecture in place is crucial to successful DevOps: “What’s starting to happen is that you’re going to have a really hard time doing DevOps well with a crappy architecture, whether that be a crappy architecture for your pipeline or crappy architecture for your application. Application architecture matters in your ability to do DevOps well.”
    • Stroud emphasizes the importance of experimentation in DevOps: “Organizations [will] look to drive mainframe R&D in a DevOps methodology—not just mainframe development, but also supporting velocity in rolling it out to production, with organizations moving from one or two major releases a year, to now experimenting with both quarterly and monthly releases using DevOps practices and experimentation and techniques.”
    • While tools and processes play a major role in a DevOps transformation, we must not forget to maintain a culture of empathy, emphasizes Shimel: “Have empathy for your fellow workers, empathy for your fellow humans. Don’t think because you’re the dev, that what you’re doing is more important than what the ops guy is doing.”
    • DevOps certifications are the future, according to Pais: “I think we’re seeing more and more DevOps education and certifications. I know, for example, there’s an IEEE standard for DevOps being worked on.”
    • Sweat the small stuff, advises Fell: “It’s never been truer than in this accelerated cycle that we’re seeing with productivity and all this awesome value being created from relatively minor, incremental improvements in process, in tooling, and all the stuff that we do, and the feedback that we’re getting.”
    • I believe 2017 will bring major disruption in the FinServ community: “We will see some, hopefully, interesting disruption in the financial technology area, because the financial institutions have always treated technology as a key differentiator. Now, the problem they have is that their culture, by and large, sucks.”
    • Some wise words from Stroud: “Strategy without execution is wasted time. We have to execute. We have to be prepared to fail. We have to be prepared to come and share our experiences.”
    • Measure, measure, measure is Forsgren’s DevOps focus in 2017: “What’s going to be my goal is having all of us think about measuring in smart ways, so that we can actually do these experiments that are small, that allow us to fail, because big massive failures are scary, but those are the ones that are easy to measure with crap measurements. Because when you fail big, you know you failed big.”
    • In 2017, we will see a breakdown of DevOps tools’ silos, per Shimel: “It’s really ironic that in something like DevOps, where the idea was to break down silos between dev and ops, dev and QA, and QA and security, but what we’ve done is we’ve built new silos of DevOps tools.”
    • Pais on the trends he sees in early adopters of DevOps: “For the majority of organizations that have already been doing DevOps for a while, they’re now focusing on what’s the best way to organize teams. Moving, often, from having just specific people who know about continuous delivery, DevOps and so on, to actually getting platform teams that embed all the services that they want the development teams to use.”
    • Oddly enough, development teams are still more likely to adopt DevOps than operations teams, explains Stroud: “One of the data stats we pulled has to do with DevOps adoption in development versus operations. Isn’t that ironic? Because the name DevOps is dev and ops. We still see significantly more DevOps adoption in development than operations, but the good news is the gap is closing, based on the Forrester data.”
    • Containers will continue to be a major player in 2017, says Riley: “Where I believe there will continue to be growth is container-native tooling, container-native security and container-native release automation.”
    • The reality is, there are still a lot of organizations not doing DevOps, remarks Fell: “We are living in this bubble, happy bubble, of everybody gets DevOps and we’re all Agile. But we talk with folks that we talk to who are just like, ‘Yeah, we do nightly builds, and we’re really looking forward to doing continuous integration.’ Your jaw drops, like, ‘Wow. Yeah, that’s a good idea. You should do that.’”
    • And, finally, I share some sage wisdom to keep in the back of our minds: “If what you’re doing on any given day isn’t moving that ball forward, what is the point? I think we need to focus a little more on that.”

    Bonus 17th quote for 2017, from Shimel: “I think the story of 2016 is DevOps has gone mainstream. We’re seeing pockets of DevOps come together as bubbles, but we still have the majorities in front of us, going forward.”

    For more reflections and predictions, watch the full episode:

     

    About the Author/Anders Wallgren

    leadership-anders-wallgrenAnders Wallgren is Chief Technology Officer of Electric Cloud. Anders brings with him more than 15 years of in-depth experience designing and building commercial software. Prior to joining Electric Cloud, Anders held executive positions at Aceva, Archistra, and Impresse. Anders also held management positions at Macromedia (MACR), Common Ground Software and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7 and various Shockwave products.  Anders holds a B.SC from MIT.  Connect with Anders on LinkedIn or Twitter.

  • DevOps in 2017: From Building to Executing

    DevOps in 2017: From Building to Executing

    In 2016, DevOps grew in popularity and use, new tools were introduced and enterprises across industries realized the influence and benefits derived from agile development. But there are even more developments to look forward to as enterprises engage DevOps teams further.

    Scaling-out solutions, providing a baseline for a new cultural approach to problems and continuous improvement will continue to be priorities. But there are a few items that we’ll likely see come to the forefront in the new year. In fact, 2017 should be an even more exciting year for DevOps.

    Here are my top four predictions for what we can expect this year:

    The next phase of DevOps will focus on security

    Security was a perennial news event throughout 2016, and we can expect the same in 2017. However, DevOps teams likely will be challenged to build good security practices into code as a part of application development, rather than refining security post-facto. This will lead to DevOps, QA and operations bringing security teams deeper into the DevOps environment, if not outright incorporating them as a part of the team.

    The foundations for this development were put in place in early 2016 as the DevSecOps model gained traction in cybersecurity circles throughout the year. In 2017, we’ll see DevSecOps teams build on these foundations. After all, every company is at risk for a data breach.

    Containerization will go mainstream

    The convenience of containerization makes it one of the most desirable technologies for DevOps teams, and next year we’ll see it gain even greater use. It’s easy to understand why: Containerization solutions, such as Docker, grant teams the ability to provide a consistent environment from development to production. We may even see containerization move to non-production environments over the course of 2017 due to its portability across multicloud platforms. And that portability is critical not just for production purposes but for security as well.

    DevOps will extend into pay-as-you-go

    DevOps will, almost by necessity, develop an on-demand model in 2017. Companies are realizing the stark demand for DevOps skills and they will be meted out according to internal needs and external demands.

    In particular, we’ll likely see a lot of opportunity for DevOps in cloud implementation, since enterprises leverage solutions across cloud providers. With cloud provider “lock-in” still a real concern for many enterprises, any provider capable of operating cross-cloud development—thereby allowing customers to switch to a low-cost cloud provider—will be in high demand. This is good news for customers, as it allows them to finally benefit from the elastic nature of cloud pricing models.

    DevOps will become pervasive across the enterprise

    Finally, enterprises will use DevOps across the enterprise. Thus far, large enterprises have been experimenting with DevOps in discreet projects, but they have started to plan for employing DevOps principles at enterprise-level, and we will see this roll out next year.

    Watching the Shift

    Thus far, DevOps has been focused on adopting and orchestrating technology and tools to build automation pipelines. But moving ahead, we’ll witness DevOps change its focus from building to executing. With this industry development and the shift within DevOps to security and containerization at an enterprise level, we’ll begin the true potential of DevOps.

    About the Author / Tan Moorthy

    Tan Moorthy is Head of Global Services for Application Development and Management at Infosys, a next-generation IT services provider. Connect with him on LinkedIn.

     

  • Best DevOps Practices for 2017

    Best DevOps Practices for 2017

    Because the idea of DevOps is still so new, we’re continually having to hone what we view as best practices. At the start of the new year, many people make their own personal goals clear for the year (regardless of whether they intend to keep them), but we tend to head back to our work desks without reassessing how our projects are going. We just jump back in unquestioningly and continue down the path we were on before the holiday.

    Mindless plodding away at a goal that had been set too far in the past is perhaps the biggest business mistake we can make. Re-evaluating our approach is often the difference between stagnation and real innovation. A willingness to change tacks and the agility to do so speaks volumes about an organization—that flexibility is rewarded by a market that demands responsiveness from its providers, and it can be a big differentiator between a company and its competition. With that in mind, there are six big goals that we can adopt as DevOps practitioners that will have enormous results on our ability to answer the demands of our users.

    Make paying off debt a priority

    Most companies are so saddled with technical debt that they hire more people just to cope with it. This is like putting more hoses on a forest fire. When fighting a forest fire, a portion of the team creates a firebreak to deprive the fire of fuel. Likewise, organizations need to dedicate a portion of their workforce to do nothing but eliminate the technical debt that is fueling their operational fires.

    Set ambitious goals, but don’t sweat the details

    Have goals and objectives, but allow the minutiae to be developed over the course of short intervals. We need to set business-level objectives for our DevOps teams, but we have to be careful to not overprescribe the details. There are many DevOps tools and methods and more arrive every day. Plan to work in two- to four-week sprints with measurable outcomes, instead of six-month project plans. Use the feedback and lessons learned from those short sprints to inform the next sprint’s work.

    Don’t leap, but get moving

    DevOps is meant to be about quickly moving product from left to right. A common mistake is for companies to wait for “the perfect moment” and then jump headlong into DevOps, creating a lot of disruption at once. This is a recipe for disaster. Identify workstreams that are ripe for improvement from DevOps and start by moving one new benefit from concept to production. Remember, single-piece flow is your friend.

    Identify the ‘credit hawks’ and neutralize them

    I once heard the saying, “Just because you run out in front of a parade doesn’t mean they are actually following you.” One of the critical pieces that makes DevOps work is a culture of sharing. That means sharing in knowledge, work, credit and blame. A “credit hawk” is someone who likes to jump in front of work already being done and claim he or she is orchestrating it. This seems to be commonplace in situations where DevOps teams exist under mid-to-upper managers with “old guard” mentality. If they take the credit, that leaves the DevOps team with the blame. Neutralize the credit hawks at all cost; they will undermine your culture.

    Plan for failure, success through learning

    Planning for failure does not equate to “expect failure,” but because we want to move faster so we can try more things, the law of averages tell us that we will also fail more, too. Planning to fail means we know how to conduct a blameless post-mortem, understand lessons learned and incorporate that feedback cycle to increase the likelihood of success.

    Promise to break the rules

    Your DevOps team needs to be trusted to find the best path, even if that means ignoring a 70-year-old process. This statement might invoke a knee-jerk reaction, but this does not imply “anything goes.” Your objective is to find more productive ways to get product to market and to create safe systems of work. Part of your lease to your DevOps teams also should be to explore new processes that eliminate red tape, bureaucracy and waste. What has worked for the last 70 years may be what is holding you back today.

    2016 rewarded those who were able to move fast, and 2017 promises to require us to move even faster. By resolving to make these changes in your company or organization, you are making a commitment to shed the shackles of yesteryear. When freed of these fetters, your application teams will be able to focus and deliver on the one thing we are all trying to do: deliver value directly into the hands of our customers. Is 2017 the year your company will triple its release cadence? Is this the year you deliver every new product into all markets simultaneously? Or perhaps this is the year when your applications suffer zero outages. The goals and the stories are yours to tell, but one thing is for sure: Resolutions without action are just wishes.

    About the Author / Adam Bowen

    Adam Bowen is an information technology leader with more than 15 years of experience in technical, sales and senior leadership roles. As the Worldwide Innovation Lead at Delphix, Adam works with thought leaders of the Global Fortune 100 to eliminate key business constraints through innovative new  processes, offerings, and technologies. Connect with him on Twitter and LinkedIn.

  • Customer Demands Outpacing Business Requirements

    Customer Demands Outpacing Business Requirements

    As more organizations adopt agile and DevOps, many recognize quickly that the related gains are significant but further business efficiencies can be realized.

    IT and the business now are working closer than ever. No longer is the business throwing requirements over the wall into the IT “sausage factory”—they’re now an integral part of the entire process. IT has finally transitioned into a profit center.

    In the application economy, it’s not the layout or cleanliness of your brick and mortar store nor the friendliness of a customer service representative that makes your business successful. It’s the application’s user experience.

    As a result, the gains we’re seeing must be optimized continuously. One of the biggest challenges we face today lies in how we get business requirements translated into IT output, at the speed of business.

    In the old days, it was easy to move your best-selling, highest margin products into the ideal location or open another checkout when the lines got too long. With today’s virtual stores, the question becomes, How can we quickly pivot to tend to our real-time customer needs and shareholder expectations?

    We must be able to deliver software faster, and to do that, we need to marry our strategy to execution and delivery. We must optimize across the entire business to create true agility that paves the way for reactive and proactive acceleration.

    Case in point: If you optimize execution but not delivery, you’ll be creating software that cannot realize value at the pace of development. In reverse: If you optimize delivery but develop software slowly and poorly, your efficient delivery process will merely sit waiting—or worse yet, deliver poor quality software quickly.

    As a result, we must optimize all three of these areas while working in conjunction, overlapping and providing constant feedback and properly timing the impact of revenue and potential risk to customer experience.

    Unsurprisingly, to support all of this, we’re also seeing broader adoption of an end-to-end solution stack that supports acceleration of process from ideation through outcome. Let me walk you through this scenario:

    Your business is managing your strategy through the lens of its portfolio. As changes are set in motion at the highest levels, that data must be tracked—how much it costs to implement new functionality, how much time it should take and what ROI looks like—along with constant reviews to inform ongoing decision making.

    Your portfolio decisions are then loaded and tracked systematically at the project level, with resources assigned systematically to deliver the designed functionality through epics and user stories. Related data must also be made available in real time to be viewed at the program, project, epic or user story level, providing complete visibility from the level of developers all the way up to the board of directors.

    Simultaneously, your user stories must be imported into a system that turns them into test cases and test automation assets, then builds the test data synthetically to validate each test case. Once the data is generated, it’s imported into your service virtualization system, where application behavioral virtualization eliminates the need for constrained and non-existing back-end systems, simulating an end-to-end environment for any application that is being tested. This also should update your virtual services automatically with the data required for the test cases and any planned test automation.

    Let’s pause and review what we just did.

    We’re now managing our new functionality items across portfolio, program, project, user story and resource levels, all in real time. We’ve automatically created our test cases, test automation, test data and virtual services, all from the epics and user stories.

    So what have we done? We’ve provided the visibility and insight necessary to make business decisions in real time and track progress. We’ve also also minimized the need for test-case designers (or the business analysts that create them), test automation engineers, test data engineers and the DBA support for test data, freeing these experts to focus on other activities.

    Hopefully, we’ve achieved the desired result of massive reduction in resource allocation, acceleration of the entire software development life cycle, elimination of error-prone manual tasks and, most importantly, elimination of the ambiguity involved in translating actual requirements into test cases.

    Finally, we’ve now got all the necessary elements—team execution, prioritization by value, connection of value to execution, a platform that provides a single source of the truth, communication, and metrics—that will allow you to focus on creating value for your customers, instead of simply creating process.

    Transformation is difficult. Culture/environment eats process for breakfast. However, by focusing on changing your entire approach instead of merely recasting process and teams, you can truly change how you provide value to your customers and shareholders.

    This is how we translate business requirements into innovative software at speed.

    For added perspective on all things DevOps and Continuous Delivery, join my colleague Aruna Ravichandran for a live webcast highlighting the details of her new book “DevOps for Digital Leaders”—it’s sure to be an exciting discussion.

    — Ron DeCanio

  • Automic Helps DevOps Transformation Sparkle

    Automic Helps DevOps Transformation Sparkle

    Working closely with Automic, an international wholesaler and retailer of jewelery transformed a department of project managers, developers and operations responsible for all of the customer-facing websites into a DevOps organization. As a result, project delivery was completed with 90 percent fewer delays, and first customer-facing releases of projects could be delivered in less than half the time. The usability of its websites increased significantly, resulting in more customer traffic, longer average time spent on the sites and increased revenue.

    Haphazard Development

    Prior to the DevOps implementation, new projects were delivered by “waterfall” project management means. The cyclical resource planning process was based on the project portfolio and business priorities. Project managers then planned project milestones working closely with business stakeholders, business analysts and application developers. Analysts created specifications and developers were assigned to work on packages and tasks to implement them.

    Different web technologies were used with varying levels of dev and ops expertise in each technology. The  Operations team members usually fulfilled requests made during the course of a project as part of their overall daily tasks—for example, to provision a new environment, deploy a package or change the environment configuration.

    This approach had a major disadvantage. Delays in one project impacted the overall resource planning and could have a cascading effect on other projects. Delays in projects could be for multiple reasons, such as waiting for business stakeholder impact, frequently changing requirements, unexpected sick leaves of developers or poor estimates. Other frequent causes included delays in operations tasks such as a deployment or provisioning of a new environment. These delays were caused by unaligned planning as well as a mismatch in priorities between projects and operations. Besides delays, some developers were underutilized, which also was exacerbated because they were specialized in a technology or component.

    DevOps Transformation Solution

    Working closely with the customer, Automic restructured dev and ops by:

    1. Switching the development from a project to a product mode (cross-project development teams based on capabilities rather than assignment of individual developers to projects).
    2. Moving project managers from development micromanagement to focus on major milestones and deliverables to the business.
    3. Enabling some project managers as product owners (project management remained necessary).
    4. Providing developers with agile methodologies through initial training plus ongoing coaching (six to 12 months).
    5. Providing ops with an agile methodology.
    6. Organizing both dev and ops into multiskilled teams focused on individual products rather than technologies.
    7. Aligning ops into delivery teams, initially part-time and later full-time.
    8. Giving delivery teams the end-to-end responsibility for their products, including their operations.
    9. Standardizing the technology stacks within teams (but not across them) over time.
    10. Delivering projects into production (or alpha, beta) in slices (releases) instead of just once to get early feedback and improve.

    Results: Fewer Delays, Better Usability

    By standardizing, this customer has transformed its dev and ops teams, creating an agile, scalable environment that can drive the business forward. The company achieved the following specific results:

    • Project delivery are now completed with 90 percent fewer delays. First customer-facing releases of projects now are usually delivered in less than half time.
    • The usability of websites has increased significantly, resulting in more customer traffic, customers remaining longer on the sites and increased revenue opportunities.

    About the Author/Michael Schmidt

    Courtney-Glymph_avatar_1435225162-96x96Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.