devopsy.kinsta.cloud

Tag: devops skills

  • Google Rolls Out Additional Cloud Certifications

    Google Rolls Out Additional Cloud Certifications

    Google is moving to address a chronic shortage of cloud skills necessary to advance DevOps.

    Specifically, Google plans to add Professional Cloud Developer (GA), Professional Cloud Network Engineer (Beta), Professional Cloud Security Engineer (Beta) and G Suite certifications (GA) alongside Professional Cloud Architect, Professional Data Engineer and Associate Cloud Engineer certifications that already exist.

    Google also plans to localize its cloud learning and certification programs in Japanese, French, German, Spanish and Portuguese to make them accessible to more people.

    Rochana Golani, director of Google Cloud learning and enablement for Google, said Google is trying to increase the number of qualified engineers available to manage IT infrastructure as code. Most of the IT operations community is made up of IT administrators that don’t have much in the way of actual programming skills. The Google cloud certifications are all steeped in the site reliability engineer (SRE) principles that Google defined in 2003. As a more prescriptive instance of a DevOps practice, the goal is to make the skills needed to successfully transition to DevOps more widely accessible, said Golani.

    Google is especially keen to increase the number of networking and security professionals that have demonstrated cloud skills, as the critical role these functions play in cloud application environments is often underestimated, added Golani.

    Those challenges likely will only increase as organizations increasingly embrace microservices based on containers running on Kubernetes clusters that eventually will be tightly coupled to serverless computing frameworks. In fact, the first era of the cloud was defined by a comparatively simple replacement of virtual machines from on-premises IT environments with similar virtual machines residing on a shared public infrastructure. The next wave of the cloud is being defined more by so-called cloud native applications constructed using microservices. That approach is inherently more flexible from a business perspective, while paradoxically being more difficult to manage from an IT perspective.

    On the upside, however, DevOps in general and SRE disciplines more specifically enable IT organizations to operate more hand in glove with the business as it grows and evolves.

    Of course, none of that is achievable without the skills required to achieve that goal. Savvy IT professionals naturally will pursue certifications that enable them to earn higher salaries. But organizations that encourage their personnel to achieve those certifications should be able to at the very least engender more loyalty among IT professionals they help advance their skills.

    In the meantime, it should be apparent that transformation is all but inevitable. Not every workload will move into to the cloud. But the principles applied to managing workloads in the cloud will be increasingly applied within on-premises IT environments. Those on-premises IT environments may not be as programmable and resilient as a public cloud, but the need to process data locally is not going to go away anytime soon. The challenge IT organizations are facing today is how best to define a set of best DevOps practices that can span both environments.

    — Mike Vizard

  • Upskilling: The Enterprise DevOps Skills Survey and Report

    Upskilling: The Enterprise DevOps Skills Survey and Report

    There has been a lot of recent reference to “T-shaped” IT professionals—individuals whose core competence (the stem) is supplemented by a broad range of other knowledge including soft skills (top of the T). T-shaped talent is in such high demand with a limited supply that recruitment efforts have become very competitive for those with upskilled and cross-skilled transformational know-how.

    Unfortunately, the migration from a deeply skilled specialist to a T-shaped practitioner is leaving many confused about what skills they should be acquiring and hiring and when. That’s why DevOps Institute (DOI) recently launched the 2019 “Upskilling: Enterprise DevOps Skills Report” community survey to help individuals and enterprises better understand the current and future state of DevOps skilling across the global IT community. Using data science coupled with hiring manager interviews, DOI’s goal in fielding the report is to provide tangible insight into why and where IT practitioners, managers, leaders and business stakeholders should focus their efforts in growing personal and organizational skills portfolios.

    Eveline Oehrlich, a former vice president and research analyst at Forrester, is bringing her data science expertise as the lead analyst for the report. Founding Platinum sponsor Electric Cloud and founding Gold sponsor Cloudbees are also sponsoring this important project. The “Upskilling: Enterprise DevOps Skills Report” will be a year over year project, and the results will be published in Q1 2019.

    The global survey will remain open until Dec. 7 and can be accessed through the following link: https://www.research.net/r/K9WD2XC

    We encourage everyone in the DevOps community to complete the survey so that the data samples truly reflect the global state of DevOps skills.  Any organization that has at least 20 people complete the survey will get a personal snapshot of the data results. All respondents who complete the survey will be entered into a drawing for four $100 Amazon gift cards.

    — Jayne Groll

  • Simulating DevOps to Discover the ‘Culture Thingy’

    Simulating DevOps to Discover the ‘Culture Thingy’

    DevOps … is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably. — Wikipedia

    We are all, I believe, familiar with the fact that culture is an important factor when adopting DevOps.

    Groan!

    Most engineers and technologists are probably tired of having the “C” word thrown at them: culture.

    Because let’s be brutally honest: DevOps value comes from the automation stuff. The latest “State of DevOps” report confirmed “that automation is a key differentiator for organizations.” All the shiny technology that supports the “continuous-es”: continuous integration, continuous deployment, continuous delivery, with infrastructure as code and spinning up servers in the cloud and then collapsing them when no longer needed, with other cool technology concepts such as containers, microservices and a whole array of sexy build, test and monitoring tools. Just when we start getting excited about it and drooling about the new tools we get to play with, somebody else pipes up with that culture. stuff again …

    Groan. Just let us get on and do IT!

    But equally, probably the most important part of the “continuous-es” is continual learning and improvement, because again, let’s be honest: The real value of DevOps takes years to realize. It is not a one-time, overnight migration with a simple press on the ‘Install DevOps” button. It is an iterative exercise involving people from the end-to-end value stream; therefore, it is all about continual experimentation, learning and improvement—and doing it with people from different siloes who don’t usually like talking to each other. So, it’s a “cultural thingy.”

    If it’s not somebody talking about culture and collaboration and communication, it’s one of those “frameworky-geeks” talking about agile, scrum, lean thinking and IT service management (ITSM) and how we need “flow,” “process engineering,” “voice of the customer,” “kaizan,”kanban,” and a whole host of other Japanese-zen-like mysterious terms which only consultants are qualified to talk about and do, as they are the enlightened-ones (probably with their own secret handshake or Doctor Spock type split fingered salute!).

    “DevOps is a philosophical movement,” we hear. Now, if there are two things that I wouldn’t normally associate with each other it is technical engineers (I was one!) and philosophy. Although I do remember trying to stare down a server once, hoping by the power of positive thought and sheer will power for it to start working again; the alternative was a sledgehammer …

    Where was I? Oh, yes. So what are some of these “culture things” we should care about, apart from the “Wall of Confusion” that everybody keeps talking about? “We’re not confused! It’s the other lot on the other side of the wall that don’t get it!”

    Below are some of the key discoveries relating to the culture, or soft skills, issues that teams experience and recognize during the DevOps business simulation, “The Phoenix Project.” Before you start getting all excited again, this is not a computer game in which you can win points by zapping Ops people who get in the way or setting phasers to stun when you see a developer about to release some more untested code or beam up an uppity product owner who tells you that what you coded may have been what they asked for but isn’t what they were thinking. This business simulation is a dynamic, interactive, classroom-based workshop in which people have to get together—face to face—and, well, communicate and collaborate! The simulation workshop has been performed with literally hundreds of DevOps teams across the globe and across different industries, and is used to support DevOps training and to help empower teams. (see a blog posted on this site).

    What are Some of These Key Learning Points and Takeaways?

    I have mapped these discoveries onto the DASA (DevOps and Agile Skills Association) competence model, particularly the “Skills & Behaviors” area.

    DASA has developed the competence model to help organizations assess and develop the right knowledge and skills within their DevOps teams. The competence model is based upon industry feedback from practicing organizations, and helps organizations assess their level in terms of Novice, Competent, Proficient, Expert and Master. It looks at four key Skills & Behavior areas and eight Knowledge areas.

    Skills & Behavior Areas: Courage, Team-building, DevOps Leadership, Continuous Improvement.

    Simulation exercise discoveries for Courage:

    • “Feedback” is often seen as negative. People don’t like or dare to give feedback. It is perceived as personal, as criticism and often as blame. A blame culture makes it even more difficult to create open, honest feedback which is a barrier to learning and improvement.
    • “Fail fast” often means “blame fast,” or “pass the blame.” A blame culture creates a lack of trust and willingness to experiment for “fear of failure.” Often in the simulations if things go wrong, people revert to asking,”Whose fault was that?” rather than asking, “What happened? How can we stop that happening again?”
    • Sharing knowledge. Still in many organizations, knowledge is power; people don’t like to share knowledge or don’t think others are capable of using knowledge. A critical aspect of DevOps is multi-functional teams with broad shared skills and knowledge.

    Simulation exercise discoveries for Team-building:

    • Teams are unaware of the need for active listening, confirmation of agreements and decisions and verifying “assumptions”—many mistakes are the results of “assumicide” and poor understanding, which causes disruptions and excessive hand-off moments to gain the right information resulting in waste, delays and rework.
    • Ownership, responsibility and being proactive. Many IT people wait to be told what to do. Many people don’t like to admit they don’t know or that they need help. others don’t actively seek out and ask, “How can I help,” asking upstream and downstream, “What do you need from me to be able to do your job?”
    • Many teams have an aversion to getting together as they have poor experiences of pointless meetings with lots of talking and then not a lot of decisions being made or action being taken.
    • Many teams don’t set for themselves goals for a meeting or learning objectives from a training session. They do not ask themselves, “What do I need to take away from this session?” They often don’t ask, “What do you expect from me?” “What should my contribution be?” They often cannot answer the question, “What problem do you want to be able to solve after attending this?” Many times in a session people say, “I was told to come.”
    • Silo thinking: Many teams still think from siloes, e.g the technology team they are in or the development team, and don’t think end-to-end. They are building and supporting a technology solution and not managing end-to-end business value.

    Simulation exercise discoveries for DevOps Leadership:

    • When there are managers in the simulation, people often sit back and wait to be told or managers feel they must come up with the solution and give instructions.
    • Managers have difficulty letting go, and sometimes don’t have the patience to let teams learn and improve themselves.
    • Managers fear experimentation and failure, as they may be blamed.
    • Managers often blame teams for not becoming self-steering, becoming self-empowered or for not taking ownership, yet they do not help coach and empower teams.
    • Often managers are unable to answer the “why” question: “Why are we doing DevOps?” If managers do not know then how can they expect team members to know?

    Simulation exercise discoveries for Continuous Improvement:

    • Teams are poor at reflecting, analyzing, thinking and coming up with solutions. They lack skills in “problem thinking,” also in terms of Kolb learning cycle. Often they recognize one symptom and then leap to conclusions and solutions.
    • Lack of skills in facilitating a stand-up meeting. See the five key team skills mentioned by Jan Schilt on devopsy.kinsta.cloud. These skills are: The stand-up; Facilitating a retrospective; Managing the Kanban (Visual Management System); Managing the Andon: (and swarming problems); and Collaboration.
    • Many teams struggle to record issues in their work, such as a CSI (continual service improvement) register. They agree it is a good idea, then nobody does it, or if they do then nobody looks at the list again. If I ask, “Who owns this?“ they usually look at each other the point to the business or IT manager. There is no sense of ownership for improvements. This confirmed our own mini-survey of 650 organizations: Less than 20 percent had formal CSI.
    • With improvements, teams wait for somebody to say, “You will do this,” rather than suggest, “I can pick up that.” Improvements mean more work and teams are already busy enough, allocating time for improvements and rewarding improvements are not valued.
    • Teams often say they do NOT reserve time to reflect and discuss improvements. They are often too busy and managers do not stimulate, or allow them to reserve time for thinking and acting on improvements to the way of working. Priority is given to completing the ever growing backlog of work.

    Knowledge Areas

    Business Value Optimization:

    • Many technology people do not understand the business they are supporting, the critical business activities and business times, how a system delivers value to the business, what happens at a given time if a critical IT feature, function or technology is not available. There is a technology mindset as opposed to a business mindset.
    • Many technology teams have never seen a user or seen how users or customers use and experience the technology. Many think they don’t need to know this. This is a top-scoring ABC (Attitude, Behavior, Culture) card worldwide in global workshops and has been for 15 years. “IT has too little understanding of business impact and priority,” and is also a top concern for business managers.
    • In every single simulation and workshop I conduct worldwide, the issue of prioritization is raised, again in relation to business impact and business value, yet all teams recognize a growing pressure on scarce resources, a dilemma between “innovation” and “maintenance work” and a need for clear prioritization.
    • Product managers in teams are often unaware of technical debt and its impact. ITSM teams have difficulty quantifying the impact of technical debt and how this impacts current and future business plans.

    And finally, the latest “State of DevOps” report also confirmed the importance of skills and behaviors, particularly what it calls “Transformational Leadership”: “By 2020, half of the CIOs who have not transformed their teams’ capabilities will be displaced from their organizations’ digital leadership teams.” The survey continues: “Leaders are the ones who set the tone of the organization, and reinforce the desired cultural norms.” Oh! There is that “C” word again. Are we ever to escape it?

    What are the characteristics of a transformational leader, according to the State of DevOps findings?
    Vision, inspirational communication, intellectual stimulation (challenges people to think about problems in new ways), supportive leadership, personal recognition. These characteristics are one of the reasons why leadership is one of the four key Skills & Behaviors in the DASA competence model.

    Conclusion

    A simulation experience helps make the “C” word become a reality. Delegates can translate it from a buzzword into meaningful behavior. The simulation allows delegates to see, feel and experience the benefits of communication and collaboration, while helping them to translate DevOps theory into practice.

    As a leader, you can use a simulation exercise as an instrument to communicate your vision in an inspirational way. End-to-end stakeholders can be brought together and stimulated to explore and develop DevOps skills, knowledge and competences together. At the end of the simulation experience teams have been empowered to capture takeaways they want to apply.  As a leader, you can support them in translating the captured takeaways into real behavior and helping shape together a DevOps culture for your organization.

    About the Author / Paul Wilkinson

    Paul has been actively involved in the IT industry for more than 35 years. Fulfilling a wide range of roles ranging from computer operator to IT infrastructure operations manager. He was co-author of the ITIL publication, “Planning to Implement IT Service Management,” and was a member of the ITIL advisory group for ITIL Version 3, and the architects team for ITIL Practitioner. Paul is also co-director and owner of GamingWorks, the company that developed the internationally renowned “Apollo 13 – an ITSM case experience” ITSM simulation game and most recently the “Phoenix Project – DevOps business simulation,” which is based upon the Phoenix Project book . He was also co-author and developer of the “ABC of ICT (The Attitude, Behavior and Culture of ICT)” publications, having conducted ABC workshops and simulation workshops with delegates representing more than 4,000 organizations worldwide. Follow him on Twitter or connect with him on LinkedIn.

  • How to Kick-Start Your DevOps Adoption

    How to Kick-Start Your DevOps Adoption

    A recent survey by CA Technologies found Australian organizations are below par in terms of implementing measures to adopt and achieve successful DevOps strategies.

    According to Ashok Vasan, vice president of DevOps Solutions Strategy at CA Technologies Asia Pacific and Japan, organizations are generally aware of the DevOps methodology and its value, but they either don’t know how to start or they’ve begun but then failed to move to rapid or broad adoption.

    A lot of companies ask CA about the prerequisites for a successful DevOps adoption, he said. It needs to be considered as more than just an IT change, and success requires an understanding and acknowledgement that the business side must lead the transition.

    Starting the DevOps Adoption Journey

    The business perspective is about launching new products or services and gaining market share. To do that, companies will ask IT to not only deliver certain facilities, but deliver them quickly, so the business should see the adoption of DevOps as a first step in achieving those goals. If senior executives are looking at a particular strategic initiative, there is a greater possibility of getting the required resources across the organization, including IT.

    Ideally, that first project will be relatively small, yet visible and significant to the rest of the organization.

    It is important to establish a common set of goals and shared objectives, covering areas including development, testing, APIs, product management and product marketing. “Everybody needs to be measured in the same goal,” said Vasan.

    Then it is time to look at the IT capabilities and activities needed to make it happen. Where are the bottlenecks? What can be automated? How should testing be performed?

    The next step is to identify the weakest link in the existing product or service chain, and work to improve that. If the release process is the bottleneck, then automating that is a good early step to take. Vasan has seen speed improvements of 70 percent to 80 percent from the introduction of release automation.

    One of the main reasons for the improvement is that release management can be a complex task, and automation reduces the incidence of errors, sometimes to the point of practically eliminating them. No errors means no time is wasted on remediation, so significant time savings are possible.

    Reduced downtime is obviously a benefit to the business, but it can even pay dividends in terms of employees’ work/life balance. Making the release process quicker and smoother means there is no need to do it overnight, on weekends or during holidays.

    Indeed, there is a very high return on automation efforts in general, he said. It is important to realize that it doesn’t matter how strong the rest of the links are: For example, even if the marketing people are doing everything expected of them, if a new app receives low user ratings, the organization has failed.

    Successful DevOps Needs More than Tools

    Back on the IT side, a technology platform should be designed and implemented so the people involved have the right tools, the right scalable technology and so on. A commitment to tooling is necessary to realize the benefits of DevOps, Vasan said. But it’s not just about tech, he warned, but rather a combination of the right processes, the right technology and the right people skills for successful DevOps adoption.

    Where an organization is struggling to gain traction with DevOps, Vasan recommends making sure that the process really is business-led; checking that the right employees have been assigned and the right vendors and consultants engaged; ensuring good project management practices; using the lessons learned from initial projects to inform the rest of the organization (possibly by establishing a DevOps center of excellence to spread the word to other divisions and projects); and using an enterprise scorecard to help keep everyone on the same journey.

    The rate of change demanded by today’s environment can be an issue for some organizations, said Vasan, but Australian banks have been very progressive and have done a lot to deliver world-class IT products.

    Even outside of the banking industry, “there are pockets of [DevOps] excellence … that can serve as examples for others in Australia.” There are “exciting” things happening in the government sector, he added.

    CA is working to pass on to a wider audience the experience and best practices developed by pioneers in the DevOps field. “We have seen how companies have started to work in all these [technical] areas, and we take these experiences to our customers.”

  • Top Skills for Enterprise DevOps

    Top Skills for Enterprise DevOps

    There is one question I hear almost every time I talk with my large enterprise customers about DevOps:

    1. What skills do my people need to be successful with DevOps?

    Talk of DevOps almost immediately focuses on culture – like having empathy for fellow workers, being flexible and adaptable, seeking continuous improvement, building relationships, etc. However, while critically important in DevOps, culture is an outcome, not an input; and such attributes are mostly either innate or acquired slowly. Culture cannot easily be taught.

    At the other end of the spectrum, we often look at technologies – agile development, coding languages, virtualization/cloud platforms, management tools, etc. Again, these can be important, but while learning these skills might make you a better dev or op, they may not make you a DevOps practitioner.

    Like most transformations, DevOps will need new people, process and technology skills, so in this post I take a look at a handful of the most important, pragmatic, and trainable skills in all three areas for practitioners looking to adopt DevOps, especially in large and more complex organizations.

    People Skills

    • Communication skills – while this may not come easily to typically introverted IT staff, both written and verbal communications, within and across the organization, and even with customers, are essential to a strong DevOps approach. This skill is learnable from formal courses, groups like Toastmasters, direct mentoring, social activities, or informal sessions like ‘lunch and learn.’ For extra credit, jump on stage for open mic night at a local comedy club!
    • Business alignment – much of a dev or ops life is spent embedded in the technology of software delivery, rather than the business need. This can cause many issues, and is something DevOps tries to address. Understanding the business strategy, goals and priorities is essential to DevOps, helps drive and easily trainable. A ‘big picture view’ helps everyone collaborate on common objectives to deliver high-value business outcomes – a key tenet of DevOps
    • Workplace history – “an appreciation for history, both technical and organizational”* will help staff understand the critical antecedents of DevOps, so they can internalize its principles not just rote learn its actions. For example, understanding hierarchical and network structures, why we adopted open work environments (and why it hasn’t always worked), and the antecedents of DevOps in things like The Toyota Way will help staff not just to act predictably in known circumstances, but adapt appropriately to new ones. (*Thanks to @garethr for input on this!)

    Process Skills

    • Agile development – it may be possible to take a DevOps approach in a waterfall environment, but it is almost definitely less effective. DevOps arose out of the Agile movement, and they pair so well that it is sometimes referred to as ‘agile for infrastructure.’ Teaching on one or more specific agile approaches (Scrum, Kanban, Kaizen, etc.) will give staff an approach and mindset informed by agile practices to help teams work together to improve flow, delivery and quality
    • Lean approaches – ‘lean’ theories born in the manufacturing world (see ‘history’ above) give a pragmatic foundation for applied DevOps, not just new-age ideals. Concepts like Just-In-Time, Toyota Production System, Design for Manufacture, Theories of Constraint and Waste can be learned from original texts, courseware and many business courses. Some are also revised in modern IT-specific texts like The Phoenix Project or Implementing Lean Software Development
    • Process reengineering – DevOps is as much about refining and improving ‘flow’ in the SDLC as it is about encouraging a sharing culture, so classic learning about how to effect change in business processes is invaluable to early stage DevOps adoption. Understanding how and why to analyze needs, identify problems, and effect change in software processes, organizational structures, teaming etc. is essential to DevOps and a long-established body of knowledge

    Technology Skills

    • Coding/scripting – in its current iteration there is a lot of focus on helping operators to understand coding languages; and teaching developers to use script-driven operations tools. From JavaScript (eek!) to C# or .NET, any coding or scripting skills will help both dev and ops to have empathy for each other’s jobs, and help to develop the elusive ‘T-shaped people’ that are so well-suited to a DevOps approach
    • IT Automation – Enterprise DevOps especially will likely involve (require?) a raft of technologies in an automated tool chain. Because DevOps is concerned with end-to-end flow, such skills need to cover the whole SDLC. Look to provide training in Portfolio Management, Agile Project Management, Source Code Management, Version Control, Test Automation, Test Data Management, Service Virtualization, Continuous Integration, Release Automation, Cloud Provisioning, Configuration Management, Process Automation, Performance Monitoring and Event Management, whether through formal training or informal knowledge transfer
    • Workflow mapping – smaller organizations might get away with pen and paper, or even a whiteboard/flipchart, but to document, share, analyze and rationalize the SDLC for large, complex, enterprise applications, you will need to learn to use workflow mapping tools. This will allow team members across the org (and the world) to take ownership of the end-to-end process, and start to collaborate on continual improvement

    This is of course a (very) short list, but should give you a starting point for developing essential skills for enterprise DevOps practitioners. As always, please feel free to drop a comment and tell me what I missed, what is more important, or even what I got wrong. I am always interested in discussing ideas and learning new things!

  • Specialists vs. Generalists for Enterprise DevOps

    Specialists vs. Generalists for Enterprise DevOps

    Welcome back to the devopsy.kinsta.cloud series, ‘Enterprise DevOps Q&A.’ I have a backlog of Q&A in store, but don’t let that stop you sending in more! If I can’t answer them myself, I will try to find someone who can.

    For this post, I was recently asked about the challenge that large enterprises are facing over whether to use generalists or specialists to drive their DevOps transformation…

    Q. Does a DevOps environment prefer generalists or specialists to succeed?

    This question has ricocheted for a while. Google CIO Ben Fried – who spent 14 years in IT at a large enterprise (Morgan Stanley) – spoke as long ago as 2011 about how ‘Generalists, Not Specialists, Will Scale the Web.’ Some webscale businesses like Netflix even espouse a singular ‘NoOps‘ skillset, although they continued to have separate specialists … and maybe still do.

    However, in large enterprises, I have seen DevOps work well with both specialists and generalists.

    The Case for Generalists

    A generalist who can take on more duties from design to deployment is especially productive when application alignment moves to a local or vertical approach, as I have discussed before. Such generalists can move code through the SDLC faster, with greater integrity and fewer opportunities to drop the ball. In such structures, there are fewer handoffs from ideation to production, so there is less chance something will slip through the cracks.

    Local and vertical organizational structures tend to be less complex, with fewer products, fewer services, fewer applications, and fewer technologies involved, so such teams can better emulate smaller startup-sized organizations. DevOps generalists in these structures, for example, will not have to learn the vagaries of 5 different provisioning tools, because they all use just one tool. Generalists will often do better in such structures.

    The Case for Specialists

    On the other hand, in a large enterprise you might have not only 5 different provisioning tools, but also 4 test automation tools, 3 middleware systems, 5 databases, and much more – housed in a dozen different departments! It is perhaps impossible then for a generalist to have the expertise required to be proficient in all of these processes and technologies. As anecdotal evidence, look at any web site or mobile app ‘designed’ by a developer – a good proportion of them are almost unusable.

    In the enterprise even specialists like DBAs or security admins need to specialize within their field. An Oracle DBA, for example, has specialized knowledge that a Hadoop DBA does not. Big enterprises adopting big DevOps need specialists who know specific differences between DB2, Oracle, MySQL, and Hadoop. And as I have posted before, it would be nice to standardize on one, but such a dogmatic approach is simply unrealistic.

    The Case for ‘T-Shaped’ People

    That said, as with many conventions in Enterprise DevOps, a best practice seems to be in finding balance. Build up leaders who can truly collaborate across disciplines with experts in other areas, while still retaining a depth of skills and expertise in their specific field. This is the idea of ‘T-shaped’ people – aka ‘Generalizing Specialists’ or ‘Master Generalists’.

    This seeming oxymorons are actually useful archetypes to apply to DevOps staffing, especially when supported by expertise from specialists from the PMO, architecture, development, DBA, security, testing, QA, pre-prod, and operations teams. This is the best of both words – generalists when you want them; specialists when you need them.

    The Case for Pragmatism

    Perhaps more importantly though, as Donald Rumsfeld once famously noted, “You go to war with the Army you have … not the Army you might want.” In a large enterprise the staff you have will likely be specialists, regardless of the staff you might want, so this will be your starting point.

    Fortunately, building a collaborative cross-functional team from separate groups of specialists, rather than a single DevOps department, is as much of a DevOps best practice as seems to exist. Take for example a large enterprise like National Australia Bank, which has have taken a DevOps approach that started with specialists but ultimately resulted in a ‘DevOps Team.’ On the other hand, organizations like DirecTV and Union Bank started their DevOps journeys by helping dev, test, and QA to streamline within their specialization, as much as they looked to streamline the collaboration between teams of specialists.

    The Case for Another Case?

    Did you handle your DevOps staffing differently? Is there another way to reconcile the differences between generalists and specialists? Please feel free to add to the discussion in the comments, I would love to hear more about your approach to enterprise DevOps staffing.

    And as always, if you have questions you’d like to address about Enterprise DevOps, let me know. Leave them in the comments below; hit me up on Twitter at @AndiMann; or send me an e-mail to me at andi.mann@ca.com.

  • The 7 skills Ops pros need to succeed with DevOps

    The 7 skills Ops pros need to succeed with DevOps

    There’s a lot of confusion about what DevOps exactly is, and what it takes for enterprises and individuals alike to succeed. Some argue it’s about successfully using collaboration toolsets. It’s not. DevOps is about collaboration between software developers and IT operations teams. DevOps grew from the need for a more agile organization, and to knock down the barriers between development and operations so that applications and IT resources could be delivered more quickly, and improved through steady iteration.

    What does all of this mean, specifically, to operations professionals – and the skills they need sharp to thrive? The walls coming down are a bit of a culture clash for most large enterprise operations and development teams. And both developers and operations professionals need to ensure that they have the right skills in place to succeed in this new environment. In this post, we’re focusing on those skills ops members need in the years ahead.

    The skills that are important may surprise some. Consider the findings from CA Technologies’ recently commissioned a study, What Smart Businesses Know About DevOps. “The most in-demand skill requirements for success with DevOps were actually soft skills,” says Andi Mann vice president of strategic solutions at CA Technologies. “I expected to see skills like programming or scripting; experience with specific tools for provisioning, configuration management, release automation, or shared monitoring; or even an understanding of Agile or Lean practices. In fact, those skills were much lower,” Mann says.

    More on the results from the CA study below, but first we want to share the results of our informal anecdotal survey of a handful of DevOps experts and practitioners, well known here at devopsy.kinsta.cloud. Here they are:

    First Up: The Soft Skills
    Interestingly, it is these soft skills that are both needed and often derided. “Everyone doing DevOps, whether Dev, Ops, security, QA, project management all need [soft skills],” says David Mortman, chief security architect and distinguished engineer at Dell, Enstratius.

    1. The ability to communicate clearly and concisely
    “Sharing is a key tenet of DevOps and if you can’t share what you know and what you’ve learned, then having that knowledge is effectively useless. You’ve just made yourself a bottleneck,” Mortman says. The other skill Mortman cited along these lines is striving to actually understand the shoes in which your fellow enterprise collaborators stand. “I can’t emphasize enough the value of having empathy for everyone else and what they need to get done. Every role has its challenges and empathy for those challenges goes a long way to a more congenial workplace,” he says.

    2. Collaboration techniques
    New collaboration techniques are essential, explains Donnie Berkholz
    IT industry analyst at RedMonk, and council member and Sr. developer at Gentoo Linux. “Ops will need to learn effective, distributed collaboration techniques such as those used in open-source software development. Leading-edge DevOps organizations make heavy use of online chat and shared tooling to log both communication as well as action. In some pioneers, this even involves so-called “ChatOps” where you can make changes to infrastructure through calls to an automated bot in an online chat. Typically this includes asynchronous communication in preference to phone calls, both long-form (e.g. email) and short-form (e.g. IRC), in an archived and searchable form,” he says.

    This enables, Berkholz says, on-call ops during any crises or fires that arise, as well as eases the ability to identify and brainstorm infrastructure changes, where everyone can easily contribute their ideas.

    3. A flexible mindset
    We’re not necessarily talking about advanced forms of mental Yoga, but certainly the ability to change as knowledge and conditions change, whether those changes are technical or business driven. “The willingness to make changes and to evaluate alternate options is key to DevOps. Things are going to fail, you or a decision you’ve made are going to be the cause of that failure. Or things just won’t work as well as you’d hoped or thought. Be willing to change your mind and look for better options,” says Mortman.

    4. Good enough is never enough
    It’s about consistently seeking continuous improvement. “This mindset is laser focused on continuous improvement daily,” says BEHR. “It is the ability to unlearn and acquire new more relevant knowledge in light of complexity and emergent information – then disconfirm it with the scientific method and move on to application only where relevant,” says Kevin Behr chief science officer at CXO advisory and board advisory practice Assemblage Pointe, Inc.

    Next up: The Technical Skills

    Understanding of modern software engineering
    5. “To move to a world of “infrastructure as code,” where all systems are maintained using configuration-management tools such as Puppet or Chef, including version control, unit and integration testing, agile software development, as well as continuous delivery and deployment models,” says Berkholz. “Traditional sysadmins may still live in a world of login prompts and manual edits of configuration files, so this will be perhaps the largest hurdle in terms of knowledge,” Berkholz estimates.

    “The technical mindset I look for are skills which allow a team to treat servers more like cattle and less like cats,” says Andrew Storms Sr. director DevOps at CloudPassage. “To work effectively at that kind of systems mentality, DevOps engineers need programming and systems architectural skills. Whether that means Ruby or Python or whatever is needed to effectively work with orchestration tools, APIs, and automation. It’s less about needing to know a specific programing language more about understanding programing algorithms and robust systems design,” Storms says.

    6. Modern software architecture
    This includes cloud deployment and administration as well as distributed systems. “As we move to a cloudy world of software, ops will need to deploy, maintain, monitor, and troubleshoot production problems with this infrastructure. And yet in many cases it’s much more complex than the previous equivalent, although it brings with it significant benefits in agility and uptime if done right. Ops will need to familiarize themselves with cloud instances and services, as well as lower-level software infrastructure such as Linux distributions and databases when deployed in a cloud,” says Berkholz.

    That also includes taking a step back from the trees to consistently stay aware of the forest. “Seeing the system and its boundaries rather than just the tasks and their due dates. This understanding of the interactions between the various actors in a system and [understanding] just how those interactions are making value occur is fundamental,” he says. “Without this understanding we will not know when to push harder versus be silent,” he says.

    7. Understanding that security incident response are continuous efforts
    Security and safety in the new DevOps environment needs to embrace new ways of addressing security and QA. “This requires continually emergent solutions rather than using ‘tried and true best practices.’ The effective team will evolve through relentless self evaluation, study, and application of more relevant and effective methods to work in complex infrastructure environments,” says Behr.

    That’s all great advice, and certainly not all inclusive of the ideal skillsets. We also found it interesting that CA Technologies’ survey of 1,300 senior IT decision makers echoed the need for broader business and so-called soft communication skills when it came to DevOps success.

    These included: knowledge of business priorities/strategies/metrics (47%), knowledge of current business processes (42%), communication skills (36%), and project management and people skills both scoring 30%. In fact, experience with specific tools was dead last in the survey at 12%.