staging-devopsy.kinsta.cloud

Tag: continous

  • Can Culture Detract from Success with DevOps?

    Can Culture Detract from Success with DevOps?

    Collaborative culture is considered to be an essential best practice for enterprises. DevOps culture correlates strongly with enterprises that achieve the highest level of business performance. However, is it possible that an organization can get overly fixated on organizational culture improvements? Can culture actually detract from achieving success with an enterprise DevOps transformation?

    An article by Curtis Franklin Jr.,”8 ways to fail at DevOps,” indicated that there are “plenty of places in the DevOps process where an organization can run aground on rocky shoals of woe.” My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is collaborative culture. These pillars are not silos, but rather foundations that need to be kept in balance.

    I bet most of us have experienced situations in which cultural improvement missteps hindered an enterprise DevOps transformation.

    Culture Missteps

    I’ve listed some examples l below which I have personally seen. Have you experienced these? I would love to hear examples of your experiences and solutions you have observed, too.

    1. Unrealistic expectations from leadership: Business expectations from leadership get too far ahead of the DevOps implementation reality—then teams reporting to leadership end up feeling unappreciated and experience frustration, resulting in organizational friction.
    2. Ops-side transformations fall behind Dev-side transformations: The Dev team accelerates ahead of the Ops team and implements “its part” of a DevOps transformation before the Ops team has a chance to implement complementary changes. The Dev-side is disappointed that Ops has not kept up with the complementary Ops-side planned changes. Dev changes cannot be put into effect, which deepens the mistrust between Dev and Ops.
    3. Dev-side transformations fall behind Ops-side transformations: This is the reverse of the second example, with similar effects.
    4. QA tester roles are confusing: When new continuous test strategies are implemented, the lines of test responsibilities between Dev, QA and Ops team members became blurred. Communication between cross-functional team members become confused, resulting in misunderstandings, dissatisfaction and organizational friction, which obstructs progress.
    5. Infrastructure and tools teams are siloed: Dev, QA and Ops teams maintain separate, siloed tools and infrastructure staff and do not cooperate to support end-to-end infrastructure and tools improvements. The transformation needed for a smooth DevOps pipeline stalls.
    6. Rewards and measures are not consistent with DevOps goals: The organization makes changes toward a cooperative culture but fails to change the way people are rewarded and measured. Conflict results between the teams.

    Solutions

    Below are solutions that were applied to the situations listed above. Do you agree with these solutions, or have others to suggest?

    1. Leaders were coached to be more aware that DevOps transformation is a journey of continuous improvement. Leaders then understood that there is really no “end state” to DevOps—there are specific business improvements that can be expected along the way. Each DevOps improvement initiative was refocused on realistic specific use cases and goals. With improved clarity, leaders were more realistic in their expectations for each improvement. This drove alignment between leaders and their teams, improved satisfaction and productivity.
    2. Project goals and team meetings were realigned and organized. Dev and Ops sides could monitor end-to-end progress together. When situations occurred in which one team got ahead of the other, the end-to-end progress visibility helped overall group communication. Empathy across the Dev, Ops and QA teams improved. With improved communication, team members celebrated the success of each other’s improvements. Teams shared a common end-to-end goal.
    3. Same as 2.
    4. QA testing responsibilities changed significantly during the DevOps transformation. Separate independent test team member responsibilities changed toward QA testers being more integrated with Dev teams. New skills requirements for the QA engineers emphasized test automation more than in the past. Training for the cross-functional team helped mitigate concerns related to the new QA responsibilities. QA testers were uplifted with new skills and became more valuable and respected by their peers. Cross-functional productivity improved.
    5. The tools and infrastructure teams from the separate Dev, QA and Ops teams were combined into a common tools and infrastructure team. Project goals were realigned. The improved clarity around knowing they are working toward tools and infrastructures for a common end-to-end pipeline accelerated implementation of DevOps.
    6. Rewards and measures that had been in place for separate Dev, QA and Ops roles were changed to rewards and measures that encouraged end-to-end cross-functional team activities. This improved overall morale and job satisfaction and reduced organizational friction that was previously impacting progress.

    Summary

    From the above real-life examples, it is clear to me that culture and organizational practices must evolve in concert with progress on other DevOps pillars. And as the pace of change increases with each transformation, the cross-functional teams must be even more cohesive. Continuous acceleration of interactions between team members drives the need for tighter relationships, more end-to-end responsibilities, improved customer awareness, continuous skills training and end-goal focused leadership.

    The is no need to create the “perfect culture” before starting a DevOps transformation journey. It can be counterproductive for sections of the culture to get too far ahead of itself, as indicated in the examples above. Perhaps it is best to evolve the culture carefully. Changes most important for each transformation project should be the focus. Continuously communicate goals and progress, and evolve the culture together with evolution of other pillars. What do you think? Do you agree is it possible that an organization can get overly fixated on overall organizational culture improvements?

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all of their IT systems.

  • Three Ways Dev and Ops Teams Can Manage the Integration Lifecycle

    Three Ways Dev and Ops Teams Can Manage the Integration Lifecycle

    Many enterprise organizations did not invest enough money into integration as they built their cloud or hybrid infrastructures. As if integrating on-premise systems and applications wasn’t tough enough, in today’s cloud era with the rise of hybrid environments, connectivity has only gotten more complicated – especially when combined with the increased speed of deployment. Puppet Labs found that high-performing organizations deploy code 30 times more frequently than their lower-performing counterparts, meaning dev and ops teams are struggling to break down data silos while simultaneously managing constant technology upgrades for line-of-business users.

    There’s no doubt that, whether public or private or hybrid, the cloud is now part of most companies’ infrastructures, and its share will only increase. Goldman Sachs estimates that spending on cloud computing infrastructure and platforms is expected to grow at a 30 percent CAGR from 2013 through 2018 compared with 5 percent growth for overall enterprise IT, while Forrester predicts that 25 percent of all software applications purchased will be cloud-based by 2020.

    With the speed and agility the cloud imposes on businesses, dev and ops need to come together to look at data integration throughout its entire lifecycle, from developing new apps or services on top of existing apps, all the way to the ongoing service, maintenance and upgrades of those applications. The two teams must join forces to manage this process as one comprehensive integration lifecycle, where dev and ops play equal roles solving for new data integration challenges brought about by hybrid deployments and siloes created by line of business users’ cloud purchasing habits.

    Today’s dev and ops teams have to look at data integration as a service, not just a one-off implementation they can hand off. Here are three strategies to help bring the two teams together to jointly manage the data integration lifecycle.

    1. Assess Current Integration Challenges Collaboratively
      Without alignment between dev and ops teams, integration lifecycle can’t be managed successfully. Organizations need to align on the people and process portion first, asking questions like: what systems does each business unit need data from? How likely is it that their needs will change, and how can you plan for a flexible integration as a service? What capabilities will ops need after dev implements the integration?

    After reaching agreement, teams will need to jointly assess and select a data integration as a service technology or platform that allows for joint requirement setting, collaboration, testing and ongoing adjustments throughout the lifecycle of the applications. Selecting the right integration platform as a service at the onset is critical to minimize cost, time and wasted dev and ops cycles down the line as business and technology needs change. The most agile integration option typically consists of a plug-and-play, flexible platform that makes use of APIs and also allows for deeper customization down the road.

     2.Understand the Four Key Stages of Integration Lifecycle Management
    Dev and ops teams are now part of the same cycle dealing with frequent updates and agile product development. It’s no longer about developing, testing and then having ops maintaining, but about a seamless and transparent handoff from dev, to ops and back throughout the entire application and data integration lifecycle.

    To capture the most value from disparate organizational data and to minimize ongoing data and application synchronization costs, dev and ops teams need to adopt a joint integration management strategy that accounts for the four distinct phases of data and application connectivity. These include:

     3. Design phase. After understanding business use cases and selecting a platform, dev and ops must collaborate on priorities – what near-term functionality can they design for based on the plug-and-play layout, and how can they tackle that low-hanging fruit while maintaining the flexibility to meet future requirements?

    By starting with the right technology and a common integration framework, dev and ops teams can design connected core systems and data early on with plug-and-play API connectivity for solutions like CRM and ERP, while maintaining the ability to easily expand functionality with custom/deeper integration capabilities with marketing automation, business intelligence and other apps.

    In addition to functional capabilities, the design phase should address performance and scalability by taking into account throughput and latency. This process involves planning to meet performance expectations, even with the customization and extensions users will likely want down the road. Dev and ops should ask themselves questions like: which company systems will be on premise, in the cloud or hybrid? What are the performance, scalability and security tradeoffs of each approach?

    1. Develop phase. Dev and ops need to work together in the development phase to carefully document key aspects of the integration while building connectivity for specific use cases. This documentation will be critical to the seamless handoff between the two departments, so they both need to be involved in the process. Strategic collaboration and thorough documentation can improve the efficacy of maintenance and debugging activities, help companies adjust to staffing changes and more easily transfer integrations to and from the two teams during the ongoing development and roll-out process.
    2. Deploy phase. Given that you’ll likely deploy in a hybrid environment, make sure you test both on-premise and cloud integrations to ensure that data is flowing freely. To help test integrations and move them into a production environment, look into staging and production environment tools that streamline the process. Infrastructure costs should also be considered, as they may increase unexpectedly if you don’t watch them throughout the deploy phase.
    3. Run phase. Continuously monitor to confirm that the data is flowing as designed. If dev and ops selected the right technology platform, the teams won’t have to worry about ongoing API management, because the platform takes care of it.

    The right platform will also lower downtime and maintenance costs with a multi-tenant management environment that allows the expert for any given situation to dive into the integration backend or runtime. The platform should also provide ongoing diagnostic reports and proactive alerting to allow ops to home in on potential performance issues.

    1. Build a Responsive IT model
      With dev and ops coming together to take advantage of the speed and agility offered by the cloud, the resulting just-in-time services for businesses are turning IT from a cost center into an innovation center. The data integration lifecycle is another result of the new cloud-shaped world, helping dev and ops teams create a more responsive IT model and allowing them to better meet business needs while driving innovation. While shared environments bring with them an additional element of risk, a responsive IT model is an important step towards both short-term and long-term success in the modern connected enterprise.

    These three steps allow dev and ops teams to offer the value, speed, efficiency and opportunity that today’s enterprises require. By adding collaboration and agility at every stage of the integration process to plan, implement, track, debug and update continually, dev and ops teams can scale to respond to the data-driven needs of the business more precisely.

    How have you overcome cloud and hybrid application and data connectivity challenges in your organization? Connect with me in the comments below, or on Twitter at @scribesoft.

    About the Author/John Joseph

    John-Joseph head shotJohn Joseph, VP of marketing for Scribe Software, earned a master’s degree in business administration from the MIT Sloan School of Management, a master’s degree in electrical engineering from the University of Southern California and a bachelor’s degree in electrical engineering from MIT.