devopsy.kinsta.cloud

Tag: silos

  • Orgs Shift Toward Centralizing Automation Initiatives

    Orgs Shift Toward Centralizing Automation Initiatives

    A survey published today found that 75% of respondents recognized that automation silos hamper their ability to unify cloud operations across functions.

    Conducted by CloudBolt Software, the survey polled 350 senior IT and DevOps leaders at organizations with more than 3,000 employees. On a positive note, the survey found 57% of respondents were starting to pursue a more centralized approach to automation, with a total of 88% acknowledging that having all previous and new automation centralized for the entire organization would ensure compliance, bolster security, enable business continuity, encourage reuse and reduce risk.

    Rather than taking a more holistic approach, well over half of respondents (57%) reported automation efforts are limited to specific silos. On average, organizations are employing 27 different automation tools their organizations have deployed, using one or a few as they see fit, with little to no consistency across teams. More than half (55%) of respondents said they have four or more separate automation teams, with 95% noting that each of those teams operates in their own silo.

    CloudBolt CTO Rick Kilcoyne said that lack of continuity clearly creates inefficiencies and redundancies that conspire to raise the total cost of IT. The challenge is that each team tends to favor one approach to automating a silo with little to no regard for a larger overall strategy to create an automation standard, he said.

    That approach also creates issues whenever a member of one of those teams leaves an organization, he noted. In fact, the survey found 77% of respondents reported that continuity is at risk any time a vital member of the team leaves.

    CloudBolt has been making a case for a federated automation platform that can be invoked either via application programming interfaces (APIs) or a graphical user interface (GUI) that provides access to low-code tools. The goal is to make the platform equally accessible to DevOps teams or IT administrators that tend to lack programming skills, and do so in a way that doesn’t require individual teams to replace their automation platform of choice. Instead, each of the automation platforms can be programmatically invoked via a central framework, said Kilcoyne. That approach eliminates any political debate over the potential need to replace one team’s favored automation platform with another, noted Kilcoyne.

    Regardless of who is accessing the platform, most organizations would be well-advised to develop a center of excellence for automation, he added.

    DevOps teams have always been committed to ruthlessly automating as many IT processes as possible, but in many cases, that has resulted in a plethora of automation tools being employed. In effect, automation may have become too much of a good thing. One approach to regaining control over those platforms is to create a platform engineering team that centralizes the management of DevOps workflows.

    Regardless of approach, Kilcoyne said the most important thing for any team to do before automating an IT workflow is to first understand how to manually set it up. Too many IT teams are trying to apply automation to processes they don’t really understand with mixed results, he added.

    The one thing that is certain, especially with the rise of artificial intelligence (AI), is the management of IT is going to become more automated.

  • Does it Matter That We’re Still Working in Silos?

    Does it Matter That We’re Still Working in Silos?

    Seventy-two percent of business leaders believe that cross-departmental working at the enterprise level benefits their employees’ experience and engagement. However, 68% of these same organizations admit to working in silos—the complete opposite of collaboration.

    So, there seems to be a conundrum. We know that working in silos is detrimental to our employees, customers and the business as a whole, yet, we’re still doing it.

    The question is: why?

    Our Protective Bubble

    To work in a silo means to build a protective bubble around you and your team, where nothing comes in and nothing goes out. It’s a zone of comfort, shielding your department from the rest of the organization.

    Siloed teams keep processes and knowledge to themselves. They work independently, for the most part, toward their own goals. By actively keeping themselves to themselves, they resist cross-functional collaboration of any type.

    As a result, those in the protective bubble are oblivious to the problems, processes, knowledge and successes outside of their immediate vicinity. Imagine what they’re missing! Someone from inside the bubble could have an idea that could solve one of an enterprise’s issues, or they may be the key to elevating an existing idea to the next level. But they’re in the bubble because they tend to feel overprotective of their work and that of their team–so forget about hearing those great insights.

    Silos Are a Hard Habit to Break

    The likelihood is that if one of the teams in your organization is working in a silo, then many others are too. And letting departments stay safe in their protective bubbles is far easier than rocking the boat and trying to change the way that several groups work.

    And once we have silos, they become part of the furniture. We build our routines and the way we work around them and suddenly they become ingrained in who we are, much like a bad habit we never intended to continue, but now cannot stop.

    This explains why we continue to work in silos despite knowing the detrimental impact they are having. A habit is hard to break. And even if we do start on the journey to change, it’s often easier to give up when the going gets tough than push through the problems. Take smoking for example; (one of the most difficult habits to break, sure, but hugely beneficial if you can do so) a 2015 survey found that only 7% of those who attempted to quit did so in six to 12 months. Changing ways of working has to be easier than that, right?

    Bursting Those Bubbles

    If staying stagnant and failing to grow or develop is more your thing, then, by all means, stay in your safe silos.

    But if becoming a more efficient, engaging, and effective business is important to you (which it should be), then you cannot expect to grow if all organizational teams are moving in different directions, not sharing their processes, ideas and insights. And much like quitting smoking cold turkey is a recipe for failure, expecting to diminish our silos in one day also is not a viable option.

    There is a solution that can incrementally burst those bubbles in a manageable and effective way: enterprise service management (ESM). Collaboration and communication are the main benefits of working in an ESM system; it provides organizations with one place for all departments to work in. Each team can set up and share processes, import knowledge and provide services through ESM.

    And by working in this unified area, departments are unconsciously collaborating. Teams can learn from each other, thanks to the universally available knowledge, and can share processes without even realizing it’s happening.

    For example, say the IT department is alerted to a printer fault in the ESM system. They first try to fix the defective item, but unfortunately, it’s not possible; they mark the printer as needing to be replaced. A notification is sent to the purchasing team asking them to buy a new printer; the order and delivery information then goes to facilities that will procure and fit the new device.

    Departments are able to keep their responsibilities and meaning, which was often their primary reason for staying siloed, while also being empowered to work better with their colleagues–and they don’t even have to lift a finger to improve the collaboration; ESM provides the space and the processes to do so.

    The Domino Effect

    The thing with ESM is, though, that we can’t just chuck all of our departments into the system at once and expect it to solve all our problems. We must implement it slowly, sometimes even one team at a time. But once we have freed one department from its protective bubble, it becomes the catalyst for something of a domino effect.

    It’s easy to work independently when everybody else is doing it, but the minute others start collaborating, it’s a different story. Imagine it’s a Friday night and you’re at home with no plans and all your friends are, too. It’s easy to be content with the situation. Now, imagine all your friends are out at a bar socializing and having fun instead, with all the pictures flooding your social media feed—the fear of missing out sets in.

    The same is true of siloed working. When we’re all in our bubbles, there is no organizational connection that we’re missing out on. But if we suddenly start to see departments collaborating and succeeding thanks to shared knowledge and processes, we want to be involved, too. And the more teams suffer from the fear of missing out, the more bubbles we’re bursting until there aren’t any more left.

    Stick or Break the Silos?

    It’s easy to unconsciously take up the habits of siloed working; after all, we thrive with our own responsibilities and a close-knit team. But it has to be a conscious decision to break down our organizational silos; it can be a long, difficult journey to do so.
    So, are you going to stick with the habit? Or find a way to collaborate and communicate better together?

  • DevOps: The Ultimate Way to Break Down Silos

    DevOps: The Ultimate Way to Break Down Silos

     Let’s imagine Jim works on the development team for a food company and his colleague, Julie, works on the operations team. On a daily basis, Jim focuses on analyzing users’ needs, testing and developing software, while Judy manages IT infrastructure and policies.

    Although they share the responsibility of software deployments and application support, Judy and Jim rarely interact with each other. In other words, they operate in siloed functions that do not encourage teamwork.

    Many organizations recognize these silos. So, to enhance cross-team collaboration and reduce repetitive work, they are implementing the DevOps mindset. This methodology facilitates constant feedback and creates an environment where the building and testing of software occur simultaneously. But to successfully implement DevOps, business leaders first need to understand what a silo is, how it’s created and its impacts on employee morale.

    What is a Silo?

    Take development and operations teams as an example. Development and operations work with two distinct mindsets. Operations values stability, which can slow down software updates. On the other hand, development values speed and is encouraged to create, innovate and generate as much as possible.

    Silos develop when these departments are structured to work as separate entities with their own visions, goals and responsibilities. If development employees aren’t passing information about software bugs to the operations team, then workflow quickly becomes bottlenecked and productivity suffers.

    How Silos Impact Employee Morale

    The lack of information-sharing across teams takes a toll on employee morale and transparency, preventing development and operations teams from forming trust and mutual respect. Within silos, the development team might not report a software bug to operations out of fear of being reprimanded. Without an honest and open information sharing system, workflow is not only delayed, but the potential for misinformation increases.

    Silos create a structure in which departments focus on their own goals instead of working toward organizational objectives. Eventually, this mentality can lead to hostile relationships between departments, which negatively impacts efficiency and harms the bottom line.

    How DevOps Can Eliminate Silos

    Implementing DevOps is the natural first step when shifting employee attitudes from departmental focus to organizational goals. This way, employees don’t have to face the daunting task of completely eliminating all silos at once.

    By breaking down silos with DevOps, companies can avoid overspending on departments that may be resistant to change. Employers can create momentum for upcoming changes in other teams with the end goal of cultivating a collaborative mindset within every department of their organization.

    To facilitate this transition, organizations should assign a DevOps administrator to act as a mediator between departments. This administrator works to communicate and apply the DevOps methodology across teams while navigating cultural differences to facilitate cross-team collaboration. To successfully implement a DevOps mindset, the administrator should keep the following strategies in mind:

    • Direct teams toward common organizational goals. Team leaders should set specific goals that align with overall business needs. It’s crucial for leaders to point out how departmental goals directly support common objectives.
    • Design shared metrics. A consistent measurement tool holds everyone accountable and encourages stronger teamwork by enabling leaders to track progress and assign workloads accordingly. For instance, organizations can set up delivery cycle metrics for both development and operations teams to measure how much workflow speed increases for both teams while maintaining continuous delivery.
    • Organize regular meetings. Inviting team representatives to participate in recurring meetings creates an opportunity for everyone to give updates on project statuses.

    How DevOps Impacts Organizations 

    Today, IT is no longer an isolated function but an essential department within organizations. It’s important that future leaders invest in technology that drives business success while keeping its employees in mind. For example, enterprise, or employee, service management is popular among businesses for its ability to deliver automated insights and support. Many organizations are turning to a modern IT service management platform to bring their employees fast and quality service—two central qualities of the DevOps mindset.

    DevOps’ culture of continuous delivery helps shorten resolution time and encourages collaboration among development and operations teams. At first, businesses can struggle with continuous delivery due to siloed IT functions because these established support structures often come with lengthy and outdated processes that slow down delivery speed. However, a DevOps-focused culture supported by an IT service desk empowers developers and operators to deliver configuration changes and resolve issues at a faster pace.

    In today’s competitive environment, a silo mentality is a detriment to the innovation required for companies to stay ahead of the curve. Through effective management strategies, the integration of the DevOps mindset will eventually break down silos, increasing collaboration and productivity.

    — Michael Mazyar

  • It’s About Communication, not Silos

    It’s About Communication, not Silos

    Too often, when enterprise folks talk with DevOps aficionados, we get a loud chorus of “Culture Change” and “Take down the silos,” and frankly that scares any sane enterprise IT person. Not because they fear change, but because they fear that those of us who are fans of end-to-end DevOps have no clue what we’re talking about.

    Don't throw the baby out with the bath water.
    Baby vs. Bath Water – By Richfife (Own work) [Public domain], via Wikimedia Commons
    And to some extent, that impression is not misguided. There will still be a development team. There still needs to be a selection of operational specialists. Eliminating these are not changes anyone is proposing for enterprise use. Indeed, if an organization has an investment in Cisco UCS, they still need a UCS specialist. The system is complex, and the more knowledge you have of it, the better it can be managed. Sure, automating as much as possible is a worthy goal for all such specializations, but even automated, the UCS person still needs to be able to expand/modify/maintain the automation. Another good example is NetOps (or whatever we’re calling it today): The person with in-depth knowledge of your ADC will still need to have in-depth knowledge of your ADC.

    So, then, what we’re really talking about is increased communication. We’re talking about a small, cross-functional team to smooth the areas that DevOps is very good at, but specialized knowledge is still needed. Increasing communication is key to every DevOps implementation, regardless of tool set; the ability to predict future work based on updates is almost essential in any faster-moving environment. Indeed, Lori and I were discussing this morning, wondering how many of those enterprise Slack channels are being used to provide a running commentary across the team of what is happening upstream. But that’s another blog, I think.

    It is not that DevOps people are clueless, nor is it that they want to eliminate specializations (well, some claim to want to, but they have a marketing reason to do so), but rather, it seems that many of us DevOps folks have gotten so wrapped up in change (it is a big change to streamline both Dev and Ops) that the baby is being thrown out with the linguistic bathwater.

    If you’re talking DevOps, talk about increasing communication, not destroying silos. Secure DevOps is evolving now, and shows the model more clearly because of it—developers and ops are given more of a role in security and auditing, but they are taught and overseen by the security team. This does not eliminate security, but does increase the security of what is being produced.

    While we’re at it, switch from bulk “Culture Change,” too. While there is a fair amount of culture change—moving to proactive and more frequent, with roadblocks minimized or removed and non-essential changes treated as, well, non-essential. But “streamlined dev/operations” might just be a better way to talk about it. After all, the brazen voices still seem to sing of wrecking balls from on high crashing down, and that’s not an effective way to get buy-in for change.

    In the end, the point is more repeatable, more stable, more manageable processes and systems. Let’s talk more about that, and less about Destructor, shall we? Sell the concept; don’t force-feed it. There’s a lot of good to be had, and using terminology that is both confusing (Define “Culture Change” in a generic, applicable sense) and often frightening is not helping people understand (or want to understand) how it can help.

    — Don Macvittie

  • Swarms: Adapting Guilds To Scale Agility

    Swarms: Adapting Guilds To Scale Agility

    In my first article in this series, “Using Guilds to Combat Information Silos,” I reviewed the adoption of guilds at xMatters. As our company has grown, we’ve used guilds to keep critical information from languishing in silos—as often happens when an organization scales. Guilds have helped our engineers apply their creativity and critical problem-solving skills to other channels and contribute to areas outside their normal scope. It’s a win-win situation for everyone who participates—and especially for the company.

    Implementing guilds began as a grand experiment. We quickly learned a lot about what enhances or hinders a guild’s success, making adjustments and adding a necessary dash of protocol along the way. But, as is the case with any growing organization, new needs and pain points challenged us to adapt and tackle them. One attempt to solve a critical problem led to an entirely new team model: a body we call the Swarm.

    The Swarm arose as a result of key changes in our release protocol. We used to be very focused on getting new features out the door as fast as we could. As it turned out, many of our customers prefer a more predictable schedule. So we gave our customers  flexible options by maintaining continuous delivery of code to production, with flags to stage larger features or more visible changes. Now, customers who wanted more predictable updates could opt for a quarterly release model while others could continue to access features as they became available and were being iterated on.

    While the quarterly release model improved our rhythm for customers, it also created stricter deadlines. A project that just missed a quarterly release could get delayed by almost another full quarter before our customers could start using it. Throwing more engineers at a problem doesn’t necessarily solve it faster—but, being the engineers we are, we thought about ways to parallelize the problem.

    We knew that guilds were very good at collaborating around a shared problem, so we adopted temporary guilds, which “swarmed” around a shared problem, completed work at an accelerated pace and disbanded. Centered around a specific initiative with a definitive start and end, multiple teams from Dev to Ops collaborated to complete a defined project. For instance, we might form swarms to create new product features, and their lifetime would span a finite number of sprints across multiple teams until completion. Due to its nature of focusing on new product features, swarms differ fundamentally from Guilds in that they are typically not self-forming; each one is an entity intentionally designed for a specific purpose.

    We began our swarms experiment with a large architectural change to roll out a new format for our customer hostnames, which involved six Engineering and Ops teams. We realized immediately that this would be an incredibly challenging undertaking on our tight deadline. A slew of teams was working on different stacks in different programming languages, so there were many competing visions and different contextual understandings of the end goal. It became very apparent that the swarm could not be left to operate in a completely flat hierarchy, as a guild usually does. We needed a leader to help ensure there was no duplication of work, things weren’t falling through the cracks and necessary dependencies were completed in the scrum storywriting between teams.

    Having someone take care of all the logistical problems is one thing, but we realized that in-person communication between all the teams in the swarm is absolutely necessary. We tried staying in the loop with each other by defining a process of posting updates from each team in our swarm’s Slack channel, but this was not enough to keep the project on track. Mattius, one of our very talented operations leads, initiated regular in-person meetings across all the teams, which led to far greater clarity. It was absolutely crucial to have all of the teams together and face to face on a regular basis.

    In the end, swarming on this massive endeavor allowed us to get the project delivered a week before the deadline. It was a challenging and imperfect first run, but it absolutely paid off.

    I leave you with these three recommendations:

    1. Create each swarm with a clear purpose and deadline;
    2. Have a leader to enforce consistent communication; and
    3. Have regular face-to-face interactions.

    The lessons we learned were invaluable for refining (and continuing to refine) our approach to tackling projects for faster release, and we’re continually working to improve and enhance this model. Good luck with all your future swarms.

    About the Author / Nick Fletcher

    Nick Fletcher, Engineering Manager at xMatters, started designing and developing websites back in 1998, when the World Wide Web was the Next Big Thing. In the time since that first website, he’s mastered all the aspects involved in creating great products: design, development and strong leadership. Connect with him on LinkedIn.

  • 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 Best Practices: Break Down Silos, Avoid Drift and Optimize for Flow

    DevOps Best Practices: Break Down Silos, Avoid Drift and Optimize for Flow

    In organizations trying to achieve agility with stability and quality, silos (of teams, tools, and processes) create major stumbling blocks to managing configuration drift between pre-production and production systems. Breaking down those silos, improving visibility into configuration drift and facilitating collaboration for improved flow are the keys to overcoming this challenge.

    The challenge of staying in sync when both sides are moving

    Production environments aren’t static. Whether you are applying patches for improved security, optimizing settings for availability and performance, or making changes for a technology refresh, production systems are continuously evolving.  As new releases are being developed, tested, and staged, pre-production environments are continuously evolving too. Ideally you want to develop with production in mind, but that gets harder and harder when both sides are changing and different teams are responsible for different environments and live in their “own worlds.” (e.g. the common split between QA teams, release teams and production operations).

    Even within pre-production, staying in sync is a significant challenge. For example, because applications ride on middleware and middleware settings are unique to each application, keeping systems in sync from QA to staging can be a real challenge.

    QA and staging environments are regularly reconfigured to support multiple releases that are in process at the same time.  The costly way, often employed to minimize changes, is to “protect” QA environments for a certain application or release leading to low utilization and bottlenecks.  The rapid proliferation of mobile applications to front end legacy systems magnifies the challenge by adding another dependency layer.

    Disconnected teams, information, and perspectives (those pesky silos)

    Why are these challenges so hard to overcome if we know the issues?  Many IT teams operate in their “own worlds” with tailor-made but disconnected tools and information resources.  Silos have evolved because they permit the specialization required to deal with the immense, growing complexity IT deals with everyday, but they have now become the biggest impediment to agility and quality.

    For example, the operations team has access to systems management alerts that most others don’t, engineers have access to build systems and scripts that others don’t, developers have access to functional requirements and stories that others don’t, and change approvals are stored in a system of record that only certain people (often managers) have access to – just to name a few silos.

    Coordinating work and sharing information across these silos of teams often equates to lots of meetings, conference calls, and email threads.  This is not the most efficient way to get work done and it’s not particularly effective in sharing information to keep environments in sync.

    “Didn’t you see my email from yesterday with the attachment listing all the middleware settings required for today’s test?”  “Weren’t you in the meeting three weeks ago when I said a Unix server was probably going to be needed in addition to a Windows machine?”  “I told so and so in an instant message on Friday to run this script before he went out on PTO, but he must have forgotten. Who else has root permission to run it while he’s out?”

    Sadly, these kinds of statements are the norm, not the exception, in most IT shops.

    The reality is there is inefficient coordination to manage all the steps and handoffs between application owners, development, QA, release and production functions.  Instead, I recommend thinking about the software development and deployment lifecycle as an “uber change” and “uber collaboration” process that must be viewed and managed from end to end; from business requirements, to development, to QA to staging to production.  All of the different silos of teams must have a way to work together in a unified way with access to critical information from upstream and downstream teams to ensure a smooth lifecycle end to end.

    Automation ≠ DevOps

    The heart of DevOps is collaboration and managing change, yet the conversation often seems to start with automation.  The fallacy here is the belief that we can eliminate the need to collaborate and manage change by removing people from the process and relying on the machine.  This out of balance perspective between the machine and people creates more problems than it solves.

    Automation tools, while important and necessary, are not all that’s needed to truly solve these synchronization and deployment issues. In addition, to have environments only changed by automation tools and never by people during the firefighting of incidents is unrealistic.  You need your people armed with intelligence and tribal knowledge to drive your automations, but all too often we rely on individuals with disconnected perspectives and limited awareness so things get missed or overlooked.

    Automation does what it’s supposed to do, but it makes a critical assumption; what’s being changed is configured how it’s supposed to be configured.  If drift has occurred because critical settings were modified to remediate an incident or compliance issue, without the automation engineer aware of the change, the automated deployment will result in you hearing a loud “boom!”

    As one popular DevOps Twitter handle has said, “To make a configuration error is human – to do it across a thousand servers is DevOps.”  While that may seem like an extreme statement designed for comedic effect, it isn’t extreme to say that thousands of deployments go south every day because systems aren’t configured the way we expect them to be given that the complex software stacks that multi-tiered applications now depend on are touched in so many ways.  Automation alone doesn’t solve the DevOps challenge.

    Negative consequences to business

    Of course, the issues I’m raising here aren’t just IT issues; they are real business issues.  Time to market is typically the number one impacted area. For example, if a two-week development sprint is used to get a business critical need addressed, but then it takes weeks and weeks to get the sprint through the quality cycle and into production due to resource constraints and configuration issues, what have we achieved?  

     Stability and quality are the next big area of impact.  When change is rapidly introduced through new releases and unexpected drift occurs in environments, performance and availability impacts occur.  It is one thing for IT to be perceived as slow and unresponsive to the business, but it is quite another when they are perceived as slow and quality is poor resulting in business impact.

    Just when IT thinks it can’t get any worse, the business asks a presumably simple question, “What happened?”  IT’s typical response, “Let me get back to you on that.”  And then begins a scramble of hours, days or weeks as IT’s best people desperately try to figure out what went wrong.  This is obviously not the best confidence builder for the business.

    Compliance is typically the other casualty as there is often very little awareness of operational policies on the development side of the house so deployment packages and instructions aren’t sensitive to compliance issues.  Building and testing an application without full awareness of policy governance across the whole, multi-tier stack is bound to introduce delays and errors when attempting to deploy in production.

    Visibility, configuration transparency and collaboration; a better way!

    1. Understand drift for the entire application service. Rather than everyone having their own disjointed perspectives on databases, app middleware, network or firewall, and server configurations, provide team members with an understanding from the business service (or application) perspective with direct visibility into the differences between how things should be configured and how they are actually configured for the entire multi-tier application stack.  This enables you to create smarter automations and initiate change processes to bring configurations back in line when necessary rather than waiting for a failed deployment to occur, identifying the root cause, and correcting it while the business waits.
    2. Optimize for flow not individual processes.  As stated in the previous example, making one process faster (e.g. development) without considering its impact on QA, staging and production will generate new constraints downstream.  Instead, view DevOps as one continuous process from goals and requirements all the way through to deployment into production and define success for the team in those terms. When you optimize for flow instead of silos, you will be amazed at how teams share more and collaborate better.

    The benefits of breaking down silos through better visibility, understanding drift and collaboration are significant:

    • faster time to market;
    • quicker ability to react to competitive pressures;
    • deployment with fewer errors;
    • better compliance with policies; and
    • greater productivity for everyone.

     To sum it up, if you break down silos, identify and resolve drift, and manage for flow (while avoiding islands of automation, information, and people) you can unlock agility, maintain stability and ensure the quality your business demands.

  • Services As A Model For DevOps Communications

    Services As A Model For DevOps Communications

    DevOps is an interesting movement. As with any effort of this magnitude, there will be many opinions on what is entailed in adoption and implementation. The issue is that businesses are so diverse and varied in culture that no single method for adoption is guaranteed to fit all businesses. In large IT organizations, this issue is additionally hampered by the fact that multiple cultures and dominions exist.

    Thus, I am not a believer that DevOps adoption comes from the approach that the business commits to adopting DevOps. The business has committed to many initiatives over time that have not panned out. This is not necessarily failure, but perhaps just shifting priorities, shifting political landscape, lack of training or simply a lack of desire to change. “The best laid plans of mice and men ….” and all.

    If commitment is not hampered by people, then there’s a good chance that DevOps adoption may be hampered by silos. This does not make silos our enemy. Silos help to compartmentalize and provide focus. Still, silos limit the ability to orchestrate process without involvement and participation from each of the silos.

    Regardless of the reason, the challenge stands, how to align a process without the use of force. The answer is protocol. With protocol, an individual or group does not need to buy into the entire process, but just needs to understand their role. Short of incompetence or insubordination, or even both, which will eventually result in the removal of these particular types of hurdles, following protocol ensures that every role in an activity will complete their action and, thereby, facilitate the whole with roughly an 80% success rate.

    I posit that the service is the means for defining protocol and of communicating that protocol into an IT organization, such that DevOps is the natural activity and outcome. A proper service entails defining a number attributes, for example:

    • Metered
    • Valued (priced)
    • Advertised / Catalogued
    • Governed
    • Monitored
    • Supported
    • Documented
    • Quality
    • Available
    • Intuitive

    It is up to each area of IT participating in the DevOps process—Design, Develop, Test, Stage, Deploy, Operate—to contribute to defining and providing their completed artifacts that pertain to formulation of the service. The service will guide the development in the understanding of operational characteristics and will allow operations to ensure they can deliver and support the service to the level of expectations of the consumer. Moreover, in those cases where the service is not meeting appropriate levels, it will allow them to provide development with the appropriate data and metrics to take corrective action, thus leading to fewer and shorter outages and failures.