Tag: Organization

  • DAOPS Foundation Hosts Global DevOps Forum

    DAOPS Foundation Hosts Global DevOps Forum

    DAOPS Foundation recently hosted its “Global DevOps Development Forum” in Santa Clara, California. The meetup, which was held May 13, was hosted by Jeff Liu, a DevOps expert from Google, and drew DevOps experts from Tencent, JFrog and JD.

    The topics of this meeting were the history of DevOps and the introduction of DevOps capability maturity model. Liu shared the theme of DevOps’ development and current situation: Before the advent of DevOps, the lack of communication between development and operations teams always made it difficult to solve problems when they happened.

    Since 2007, a movement to combine development and IT operations has occurred in Europe, and people are increasingly aware of the importance of combining the two. With the development of the movement, the scope of this concept is also expanding. It is no longer simply the communication between developers and IT operations personnel, but has been extended to the entire development life cycle, from the beginning of the process to the automation through deploying solutions in incremental build systems. The term “continuous delivery” is now used, especially for dynamic applications deployed on the internet. DevOps capability has become the focus of many enterprises’ transformation; we need to continue to move forward in the repeated failures and find out the suitable transformation path for ourselves.

    DAOPS MeetupDuring the meeting, Liu invited experts from JFrog shared their understanding of DevOps and expectations for the future.

    The meeting was also the opening ceremony of DAOPS Foundation. Liu and Kohsuke Kawaguchi attended the meeting as governing board members.  Alan Shimel, editor in chief of devopsy.kinsta.cloud and another board member, was unable to reach the scene for personal reasons, but sent a welcome via video recording. As partners in future course development of DAOPS Foundation, Jayne Groll, CEO of DevOps Institute, also sent her founding wishes.

    About DAOPS Foundation

    As an international organization, DAOPS Foundation hopes to gather experts from home and abroad to work together to improve the IT engineering efficiency (R&D efficiency) of enterprises in different industries around the world and to assist enterprise transformation. This is also called Advanced Software Engineering Model (ASEM), which based on DevOps framework. DAOPS Foundation introduces ASEM.

    Future tasks of DAOPS Foundation:

    1. International DevOps Capability Maturity Model and ASEM output
    2. Open Source Product Promote
    3. GNSEC-Global Next Software Engineering Conference
    4. Lesson based on DevOps Capability Maturity Model and ASEM
    5. Enterprise DevOps Promotion Program
    6. Technical Publication

    DAOPS Foundation conference attendance:

    1. Participate in Cloud Expo-Hong Kong, May
    2. GNSEC Taipei Station, June

    DAOPS welcomes your participation as co-founders or individuals. If you are passionate about DevOps or AIOps and are enthusiastic about the future development of DevOps and AIOps, we sincerely invite you to join our team to contribute to the future development of DevOps and AIOps.

    Any questions, please contact DAOPS Foundation via email or look for us on Twitter.

    — DAOPS Foundation

  • Living in a DevOps World, Part 2

    Living in a DevOps World, Part 2

    Part one of this article focused on some of the more behind-the-scenes benefits of an Agile DevOps approach. In part two the focus turns to some of the other traditional problems that a well-executed DevOps approach can address, and how doing so can benefit an organization in more ways than just a technical perspective.

    By way of quick review, DevOps was born out of the Lean and Agile software development methodologies when it became clear that, while those methodologies did indeed speed up the development process, a bottleneck still occurred when push came to shove and new code had to be moved to quality assurance and production environments.

    DevOps was created to more seamlessly connect the development and operations processes, making code migration, testing and promotion to production a more efficient process. To accomplish this, the DevOps approach had to find solutions for some of the issues that caused operational delays, and create new ways to organize, implement and continuously optimize the operations process.

    Overproduction/Overprocessing

    For those who have been in development and/or operations for any length of time, it quickly becomes clear that there is a multitude of operational safety checks that serve to protect a production environment. While that is vitally important, it was also clear that there had grown an “over” problem around many operational procedures, and in many cases that manifested itself in the development process. That includes overproduction, when making or requesting more than was needed from requirements and/or operations perspective to clear arbitrary operations process hurdles.

    Alternatively, overprocessing, when development and operations resources do more work (as opposed to just enough, as Lean and Agile would suggest) than required to smooth the transition of code and functions from development to operations. This created waste regarding time, resources and budgets that were not proportional to the benefits derived from following the operations process.

    Motion and Transportation

    Similarly, DevOps also sought to solve the operational problems of both motion and transportation. That is, the amount of excess work required to deliver new code to meet the operational requirements for code migration. The friction caused by such requirements slowed the motion and momentum of the development process. The same is true of transportation, or the difficulty in moving code between environments such as testing, quality assurance and production.

    In both cases, development and project momentum was sacrificed for what often turned out to be a series of artificial hurdles that had long since become less effective or even obsolete parts of the operations process.

    Correction and Inventory

    In most instances, all of the above resulted in the final maladies of the pre-DevOps development and operational ways. The first was the number of in-flight corrections required when timelines were squeezed, and the rush was on to get to production. Unfortunately, this went hand in hand with the ultimate problem of good code being sacrificed for expedient delivery, often resulting in inadequate functionality, system outages and, in the end, lost market opportunity and revenue.

    3 Keys to DevOps Success

    Any successful DevOps implementation must address three critical factors in this order: culture, organization and tools.

    Culture

    It’s critically important to connect an organization’s values to the DevOps process. Valuing quality, timeliness and organizational alignment of goals and objectives is the first step toward DevOps success. Such cultural values translate directly into a DevOps organization.

    Providing empowerment and accountability to DevOps team members helps to build ownership among the team, and trust from their customers in the rest of the organization. It also helps to provide a physical environment that fosters collaboration, teamwork and continued learning. Co-working spaces and collaboration tools such as Slack are a good start. Attending external conferences to broaden perspectives and to bring new ideas back to the team is often beneficial. From there, brown bag lunch sessions where ideas and experiences can be shared, frequent post-mortems on implementations to hone best practices, and even internal mini-conferences where several departments come together for a day to discuss DevOps practices are all effective ways to build a strong DevOps culture.

    Organization

    Any good DevOps organization is two-sided; that is it has to work from the top down and from the bottom up at the same time.

    The top-down part is in the ability to “see the system” from a macro level, allowing for process understanding and insights from a business workflow perspective. This helps to identify the pain points and bottlenecks in the current process that can be optimized through the DevOps process.

    Once that’s accomplished, the bottom-up work begins. Identifying things such as inconsistencies in code deployment environments that cause delivery issues, elimination of manual and custom built deployment processes and quarantining inefficient and poorly written code until it can be redone or eliminated are all part of optimizing the time, quality, resources and success factors for deploying production systems on schedule. It’s also important here to continually audit the current processes with an eye toward eliminating the processes that are no longer required or useful but have been kept in place out of the fear of  “breaking something we don’t understand.” If nobody understands it, then it shouldn’t be in production software.

    Automation Tools

    The final factor for DevOps success is to have the right toolset.

    Communication: Any DevOps team requires the ability to quickly and directly communicate with other team members sans meetings. For this purpose, tools such Slack (real-time chat), Skype (video chat), and Confluence (for storing persistent information) are pretty good options.

    Planning, Monitoring & Consistency: For the team’s planning needs, a tool such as Trello that can provide Kanban board functionality is worth a look. For issue tracking and monitoring of any system’s overall health, tools such as Jira and NewRelic respectively provide some good functionality. Likewise, consistency is vital in a DevOps world, and using automation to ensure that all systems are configured as desired across different environments is a crucial best practice. For this, a tool such as Ansible is worth a review.

    Integration & Deployment: For continuous integration of systems in development and as a way to tighten the feedback loop for developers to determine if the central build used for deployment to production is working as intended, the Jenkins toolset might be a good fit. And finally, when it comes making any deployment process as painless as possible, a tool such as Docker that can handle created containers for an application that includes all dependencies, reducing the complexity of deployment to multiple environments, is a solid way to go.

    The point of all of this is to create an environment—culturally, technically and physically—where DevOps can succeed, grow and thrive. Organizations that can create an effective and efficient DevOps environment have also created a competitive advantage for themselves.

    — Dave Farinelli

  • The Leadership Suite DevOps and Business Alignment Success Guide

    The Leadership Suite DevOps and Business Alignment Success Guide

    There’s not much point to DevOps if the business isn’t directly benefiting through increased efficiency, productivity and, hopefully, profitability. This is possible only when IT and DevOps teams are delivering the technology the business actually needs to succeed and compete.

    As IBM director in IBM Cloud writes in his post, “Putting the ‘Biz’ in DevOps“: “The goal in any meaningful DevOps practice is to reduce the time and improve the efficiency in moving from the “Business Need” on the left to the “It’s Live!” on the right.”

    That alignment, while essential, isn’t easy to achieve. As I mentioned previously in my post, “The Big Digital Transformation Trends Through 2017,” the Deloitte 2016 – 2017 Global CIO Survey found that the expectations business has for IT are out of sync when it comes to what IT actually can deliver. The survey found this to be true when it comes to customer focus, technology-enabled business growth and innovation. For example, “even though 57 percent of the CIOs surveyed said that customers were their organization’s top business priority, less than half were involved in delivering customer experience (45 percent) or working on customer acquisition, retention and loyalty (44 percent),” that report found.

    That survey also found, startlingly, that while only 5 percent of organizations say that strategic alignment of IT activities with business strategy is a leading-class capability in their organization, 80 percent of organizations believe such alignment is critical to success.

    With this in mind, we’ve cultivated some of the best stories and other content on devopsy.kinsta.cloud when it comes to effective alignment of DevOps efforts and business strategy.

    The Big Digital Transformation Trends Through 2017

    Some of the most important trends in 2017 will include CIOs struggling to break out of the role of IT plumber and to better align the business with IT.

    How to Align Your DevOps and Cloud Initiatives – devopsy.kinsta.cloud

    One of the best ways to align with the business is to move software more swiftly with continuous delivery efforts. In this post, Michael Schmidt, head of the Automic DevOps Practice, details how to best manage IaaS, PaaS along with DevOps so that organizations can develop more quickly, and rapidly move to continuous delivery.

    The Conundrum of Adopting DevOps within Organizational Constraints

    In this post, devopsy.kinsta.cloud regular contributor JP Morgenthal explains that as with most changes within IT, with DevOps adoption, there is a need for bottom-up support as well as a top-down requirement that provides the coverage, financing, motivation and accountability to the business to enable change to occur.

    Putting the ‘Biz’ in DevOps

    Here, Rick Weaver, director IBM Cloud, explains how by adopting the right business-oriented metrics will help expand DevOps capabilities into a broader, more meaningful “BizDevOps” practices.

    Enterprise DevOps: Organizational Change a Must

    In this article, Sanjeev Sharma, IBM Worldwide lead, details the principles necessary to foster application delivery team alignment from a people and team perspective—something that is essential if teams are to successfully align with DevOps.

    It’s Time to Couple Security, Business Leadership

    In this post, yours truly reviews the importance of aligning security and business leadership, and if organizations conducted themselves that way, there’d be a much smaller gap between security teams and their organization’s board of directors when it came to cybersecurity expectations and reality.

    — George V. Hulme

  • Organizational Dysfunction: The original vulnerability

    Organizational Dysfunction: The original vulnerability

    During your teenage years, you may have figured out a way to get a ‘yes’ from your parents by playing off of the responsibility and knowledge gap between them…walking up to your mom and saying something like, “Hey Mom, Dad said he would drive me, can I go out tonight?” and then proceed to your dad and say something like, “Hey Dad, Mom said I can go out tonight and you need to drive me.” There is nothing cleverer than a determined teenager wanting to get his or her way. Such is the case of targeted attackers and the way they play one IT department’s responsibilities off another. This is the grey area where the organizational chart and separation of duty can introduce weaknesses exploited by the more advanced threats we face today.

    You don’t have to look far into your organization to see this at work. The security team does its thing, networking engineers do their thing, and IT operations teams in general all have administrative realms that define functional boundaries as to what they can see and do. To borrow from Colonel John Boyd’s OODA loop, each team has its observation and orientation (OO) process for gaining operational visibility and making decisions, as well as specific decisions and actions (DA) they can execute within their administrative realm or set of capabilities to bring change to their organization. The weakness I’m highlighting in this post is when the decision and action appropriate for a set of observations, and the observations themselves, exist in two separate departments and can be exploited by the attacker.

    To exemplify the problem, let’s begin with the question: Is a distributed denial-of-service (DDoS) attack a security or a network engineering issue? The problem I see most often is that one department will have a precise view into network telemetry for early threat detection, but will not yet have the ability to mitigate or remediate the threat.

    Or how about the situation where credentials for one of your executives are harvested, and now the attacker need not trigger any security events at all in order to carry out an attack. In this situation, the attacker merely needs to log in and plan the next stage of the attack, roaming freely and without suspicion across your network because they are only generating networking traffic. The network team does not act because everything is still available, and the security team does not act because there is nothing being denied in access logs, no firewall violations, and nothing triggered on the IDS/IPS.

    Let me be clear in that I am not saying that everyone has to become an expert in everything; specialization is healthy, but only when it does not compromise communication! In the example of Mom and Dad being played by the teenager, if Mom and Dad had a better communication protocol, the teenager’s tactics would be thwarted. If you look at some of your operational procedures, and start to think like an attacker (or teenager again), I’m sure you will find at least half a dozen communication gaps that a clever attacker could exploit.

    This organizational dysfunction is going to require change that may appear to be radical because the systems that support it are so ingrained. Big analyst firms have defined their technology categories as law and they police them as if you were breaking the law if you dare to create something different – something more cross functional. Some best practices out there are, in my opinion, worst practices because they are so focused on the operational effectiveness of the department, and they leave out other departments or the active threat entirely. Lastly, even some prescriptive compliance requirements force organizations into strict separation of duties, but when implemented, create a broken OODA loop where the ‘OO’ does not connect with the ‘DA.’

    There is an opportunity for DevOps to completely recalibrate how we deliver a cross functional operational unit which is why I took the time to write this article for devopsy.kinsta.cloud.  Through the lens of Boyd’s OODA loop, you can already see the security ramifications because the tempo of DevOps allows the defense to loop at a faster rate than the adversary – the dominant strategy of the OODA Loop.

    I hope this post is a call to action for all you big thinkers. Get creative, get innovative, and do not be afraid to erase some lines and boundaries within your IT organization if it fosters a higher level of communication amongst your teams. Think of your organization like a great band playing live music. All of the performers play different instruments, yet they are listening to one another just as hard if not harder than they are producing sound. They improvise and adapt to one another; monitoring systems are put in place so they can have just enough of each sound in their own ear. This is what effective, cross-functional teams look like.  I’m just going to say it: DevOps is Rock and Roll!

    Oh, and hey, follow me on twitter: @tkeanini

  • Step One Of DevOps Ignores Technology

    Step One Of DevOps Ignores Technology

    I’ve spent a bunch of time talking with Adrian Cockcroft, former cloud tzar at Neflix, and listening to his various talks and presentations. I’ve also spent a bunch of time looking around the various rooms within which he presents and seen the dazed look of attendees who have rightly assumed that just seen a picture of the way organizations should be. Netflix is unquestionably an exemplar for IT reinvented – where innovation, agility and developer enablement are natural parts of what they do.

    But then I’ve seen these new disciples of the “Netflix way” write a list of the technologies that Cockcroft detailed and attempt to shoehorn those same approaches into their own organization. All to often the result is disappointment, failed projects and a swing back to the traditional rigid ways of doing things.

    These thoughts struck me then I hear about this new masthead and its aim of creating a hub for DevLops thought leaders – surely giving IT practitioners a good place to find the latest tools and techniques will help spread the DevOps gospel?

    Well yes, and no. You see I’m a firm believer in the viewpoint that DevOps has very little to do with products, processes and policies, and instead is a direct result of a particular type of culture. On the one hand you have Netflix, clearly a cultural outlier with its openness, willingness to experiment, embracing of failure-driven iteration and aim of planning for failure. On the other hand you have traditional IT shops that are top-down, driven by a rigid policy framework and consider the “operations department” and the “developer team” as two distinct entities.

    This was a topic that Christian Reilly (he of the sartorial elegance and funny accent tendencies) and I discussed a couple of years ago, before the DevOps hype had really started to hit. In the video, he reflected directly on his organization, Bechtel, as an outlier at one end of the spectrum, while Netflix is an outlier at the other. It’s a somewhat dated video, and talks about public/private cloud, but the themes in terms of organizational readiness hold true for DevOps as well.

    [youtube http://www.youtube.com/watch?v=gVG1Pj4cW-g&hd=1]

    So my aim in my regularly irregular DevOps column in here is to talk about everything but the technology. And where better to start that the first step towards DevOps which is, I believe, all about building cultural bridges rather than making technology choices. It should be a natural concluding that, since DevOps is all about bridging the developer/operations span, that perhaps getting people in a room to talk about their particular drivers and metrics would be a good idea. But alas most people go from talking about DevOps to deploying their choice of automation tool.

    There’s so many things to think about in embarking on this process – over on the ScriptRock blog Alan points out that visibility is a key first step before automation is embarked upon. While I agree with him that visibility is key, for me the money quote comes in his post where he writes:

    Don’t automate what you don’t understand

    But to then suggest that the first step should instead be a visibility tool does little to improve the outcomes – unless both sides fo the organizational divide are in the same room and accepting a common lingua franca and viewpoint on the data – visibility achieves little. So takeaway #1 focus on the culture. There’s lots of ways to build the bridges needed to change the way an organization looks – I’m going to cover some of that stuff over time.