Tag: it

  • SolarWinds Unveils Unified Observability Platform

    SolarWinds Unveils Unified Observability Platform

    SolarWinds this week launched an observability platform that makes available a range of tools and technologies that the company has developed and acquired via a common user interface.

    Rohini Kasturi, chief product officer for SolarWinds, said the SolarWinds Hybrid Cloud Observability platform also makes an observability platform affordable for a much wider range of organizations.

    The platform also makes it easier to discover, map, and understand dependencies in ways that make it easier to achieve and maintain service level objectives, he added.

    The SolarWinds Hybrid Cloud Observability is a suite of tools made available via multiple tiers that make it simpler to automatically discover the root cause of an IT issue in addition to making it easier to manage configuration, reporting, and planning tasks across cloud computing and on-premises IT environments, said Kasturi.

    As IT teams increasingly distinguish between merely monitoring IT environments and achieving observability that allows them to proactively surface anomalies using machine learning algorithms and other forms of data science, the level of depth and insight that can be applied to managing IT is increasing dramatically. In fact, observability is quickly becoming table stakes for any provider of IT management tools, noted Kasturi.

    There is, of course, no shortage of observability platforms. The SolarWinds Hybrid Cloud Observability is designed to be deployed alongside existing monitoring tools rather than requiring IT teams to rip and replace the tools they already employ, said Kasturi.

    It’s not clear to what degree IT organizations are embracing observability. As a core tenet of best DevOps practices, observability has always been a goal. However, even the most advanced DevOps teams have thus far achieved little more than continuous monitoring of IT environments that are based on a set of pre-defined metrics. An observability platform not only surfaces anomalies but also enables DevOps teams to launch queries across logs, metrics and distributed traces to identify the root cause of a performance issue before it becomes a major disruption.

    The biggest challenge, however, may not be the technology as much as it is simply understanding what queries to launch. As IT environments become more complex thanks in part to the rise of microservices-based applications, the number of potential permutations that might impact a highly dynamic IT environment is increasingly beyond the ability of any IT team to manually track. It’s already apparent that many of the legacy monitoring tools that DevOps teams rely on today will need to be rationalized in favor of tools infused with machine learning algorithms capable of discerning patterns across a complex IT environment.

    In the meantime, IT teams will need to spend a considerable amount of time experimenting with observability platforms in the months ahead. After all, applications don’t magically instrument themselves. However, once IT teams do find a way to aggregate the logs, metrics and traces that can be collected from one application environment, it does become easier to define a set of best practices that can eventually be more widely applied.

  • Encore Platform for Running Distributed Apps in the Cloud Arrives

    Encore Platform for Running Distributed Apps in the Cloud Arrives

    Encore has made generally available a namesake backend development engine for rapidly building scalable distributed IT environments across multiple cloud platforms.

    Fresh off raising $3 million in seed funding, Encore CEO André Eriksson said the Encore platform analyzes source code to eliminate the need to manually configure, connect and set up portable cloud computing environments.

    In addition to being able to automatically setup and manage cloud infrastructure based on the metadata surfaced by static analysis tools, Encore provides access to a built-in continuous integration/continuous delivery (CI/CD) platform, previews of environments, live reloads of cloud environments, authentication, secrets management and automatic distributed tracing capabilities.

    Eriksson said the development of the Encore environment was, in part, inspired by how developers of games today routinely use an engine to build application environments rather than presenting developers with a set of text-based editing tools to build those environments using low-level boilerplate code that has to be written by developers for each application instance.

    Written in the Go programming language, Eriksson said Encore platform is based on an open source Encore Go Framework that prevents IT organizations from becoming locked into an Encore platform that today can be deployed on Amazon Web Services, Google Cloud Platform and Microsoft Azure cloud services.

    The building and deploying of distributed applications has always been a major challenge. Encore is designed to automate most of the routine tasks that DevOps teams today need to manually perform for each distributed application they support. As the number of applications being deployed across various cloud computing platforms increases, the challenges associated with managing those environments increase. Encore is designed to enable developers to easily build and deploy application code in a way that can be centrally managed by a DevOps team, noted Eriksson.

    It also takes advantage of the concurrency capabilities that the Go language enables to make it simpler to build and deploy distributed applications in a cloud-agnostic manner, said Eriksson. DevOps teams can also employ Go to extend the Encore environment within the boundary of certain limitations, he added.

    Essentially, Encore is making a case for an opinionated distributed computing environment that, in return for less flexibility, promises to make it simpler to deploy complex applications. Eriksson said Encore doesn’t see many DevOps teams looking to deploy distributed applications that span multiple cloud services, but they are being required to deploy more applications on different cloud platforms. Each cloud platform a DevOps team needs to support only serves to make the overall IT environment that much more complex to manage, he noted.

    It’s not clear to what degree IT organizations are ready to embrace a more opinionated approach to managing cloud computing environments. However, the concept of relying on one is hardly new. Platform-as-a-service (PaaS) environments have been employed for years. However, with the rise of microservices-based applications that are inherently distributed, the issue may soon be forced as IT organizations find simply no other way to keep pace with the rate at which applications are being developed and then continuously extended after they are deployed.

  • Building a Culture of Full-Service Ownership

    Building a Culture of Full-Service Ownership

    In recent years, our reliance on software has exploded. It has been more than a decade since Marc Andreessen made his prophetic observation that “Software is eating the world.” Today, nearly every interaction is mediated through a screen and backed by software. With the massive shift to remote and digital interactions due to the pandemic, enterprises that were already in the process of acclimating to a digital-first future had to quickly pick up the pace to survive today’s increasingly complex tech landscape, putting an inordinate strain on IT teams.

    Developers obviously deliver the most crucial component of the software development life cycle; however, ownership of their developed services and applications is no less important. The idea of ‘full-service ownership’ means taking responsibility for supporting the software and services you deliver at every stage of their life cycle. Excellence in continuous delivery and innovation on them is about speed and velocity while maintaining quality.

    At its core, service ownership is about connecting humans to technologies and services and understanding how they map to critical business outcomes. Achieving this level of ownership requires an understanding of what and who delivers critical business services. A clear understanding of what the boundaries and dependencies are of a given service along with what value it delivers is the starting point. And once it’s in production, a clear definition of who is responsible for it at any given time and what its impact is if it isn’t running optimally or, worst case, fails altogether. Empowering developers with this information brings DevOps teams much closer to their customers, the business and the value they create which, in turn, leads to better application design and development.

    Building a culture around a full-service ownership model keeps developers closely tied to the applications they build and, therefore, closer to the value they deliver. Within the organization, this type of ownership breaks down long-established centralized and siloed teams into cross-functional full-service teams. For enterprises with deeply ingrained processes, this may be easier said than done—but the outcome is well worth the investment. Following these guidelines will allow even legacy IT teams to create a culture of full-service ownership.

    Get Developers on Board for Clear Ownership

    With the pressure to innovate already weighing heavily on software teams, you may be wary about the burden more responsibility might cause. However, the end goal is mutually beneficial: Create clear ownership at real-time speeds. Not only does this allow engineering teams to ship features more quickly but it also empowers them to stay engaged and connected when something goes wrong—reducing hand-offs and mean-time-to-resolve (MTTR). In other words, no panic, no uncertainty and minimal customer impact.

    Decentralize Team Structures

    Reworking team structures and technology for full-service ownership may seem overwhelming, but it doesn’t need to be. Traditional function-based silos are a feature of many legacy IT departments. Provisioning infrastructure and resources, developing code, quality assurance, owning the customer relationship, supporting software in production and so on are too often delegated across segmented, centralized teams. Allowing decentralized teams to own the entire life cycle of their services affords them the ability to add value in new ways. The key is to start small and implement changes gradually.

    Implement a Strategic Rollout

    When beginning the process of full-service ownership adoption, pointing to small wins will gain the support of key organizational stakeholders who can then facilitate larger-scale change. Start with non-critical production systems or greenfield applications. Agile methodologies will also be useful in adapting to dynamic development needs and unpredictable events. Remember to be flexible with the timeline in the initial phases and be patient with your team—mastering the life cycle takes time!

    Keeping long-term goals in mind, your teams should consider not only “build and deploy” but also “run.” Craft your tech stack in a way that comprehensively shows the entire infrastructure, leverages machine learning to reduce false alarms, and uses automation to conserve the manpower and resources involved in going on-call to support services in production.

    Leverage the Right Tools and Technology

    A key requirement here is building trust and an accurate system for identifying who is responsible when something goes wrong. Adjusting to a DevOps approach will fail if developers receive false alarms, too many interruptions or are constantly escalated to repetitive fixes. Building and executing on a strong service directory and supporting their preferred schedules is critical. As is ensuring when they are needed, you contact them via the channels they expect. Failing to do this can result in minutes and hours lost and worse yet, frustrated and burnt-out developers. Recent data shows that developers who get called in to support services too often or incorrectly are more likely to leave their jobs, and that’s only going to stall your progress further.

    With an accurate service directory in place, it is important to remove the false alarms. Teams must make sure “alerts and alarms” are correlated and an incident is confirmed before you interrupt your valuable time-strapped developers. This involves the right observability and monitoring tools but must also involve strong centralized machine learning augmentation to reduce noise and false alarms. As teams mature, automation plays a critical role here. First, by cutting out the common diagnosis and investigation steps that can burn minutes or even hours. Then, reducing escalations to developers (by over 50%) by putting common resolutions in the hands of first responders or even customer service teams. These collections of technologies are commonly referred to as AIOps and as digital business scales, they become a foundational requirement.

    Cross-Functional Teams are Table Stakes

    Today’s digital ecosystem is more advanced and more complex than ever before. Maintaining quality digital services is not just a competitive differentiator, it’s the backbone of your corporate reputation. Recent high-profile outages and cyberattacks have catapulted the fragility of the software supply chain into the international spotlight, meaning the margin for error is slim. Resolving issues proactively and in real-time before they impact customers is critical.

    Transparent accountability and decentralized ownership ensure that teams have a deeper knowledge of issues when trouble strikes and can take swift action. Revealing to technical teams and developers the direct impact they have on business outcomes enables high-quality, innovative code that delivers on its promises.

  • Your DevOps Teams Can Do Better. Here’s How.

    Your DevOps Teams Can Do Better. Here’s How.

    As more organizations focus on digital transformation as the centerpiece of their growth strategy, software developers and IT teams are under heightened pressure to perform—quickly and efficiently.

    That begs two questions: Can we do better? And if so, how can we do better?

    The answers can be elusive, especially for DevOps teams that have over-relied on processes and models that, while previously successful, may not be as relevant for today’s projects. Of course, the point about relevance has been further magnified during the pandemic, when sudden shifts to remote working left many teams scrambling to ensure they had the capacity and infrastructure to support massive work-from-home cohorts.

    Software development and IT operations support teams that are winning by doing better in this new era are truly embracing Agile. And that means taking to heart the definition of “Agile,” which is a mindset of values and principles to continually evolve your way of working (WoW) to ensure your productivity and value are tailored to fit the tasks at hand.

    Conversely, teams that have relied on their go-to framework or approach for every assignment are often missing the boat with respect to efficiencies, effectiveness and even ROI. This is because they aren’t assessing whether their proven WoW is useful for their current projects.

    That can lead to underwhelming results. A report from Digital.ai revealed that while over 90% of software development teams take an Agile approach to their work, a whopping 96% of their digital transformation projects have failed or been delayed. Clearly, that suggests Agile has worked for them in the past, but the nature of digital transformation projects is calling for teams to adapt to new or hybrid approaches that may differ from their go-to WoW.

    Challenging? Yes. Doable? Also Yes

    While there is no quick fix to attain true flexibility amid complexity, the journey begins with the recognition that, yes, you can do better. And to do better—to become an adaptive, lean, responsive and learning organization under any circumstances—there are a number of steps to take to ensure your journey to Agile freedom is successful.

    Here are five that I believe must be considered for DevOps teams to become better and more effective:

    • Consider all options. Agile has been practiced for more than two decades, and literally hundreds of frameworks and approaches have been developed and implemented. If you examine your WoW in a context-driven, pragmatic manner you are more likely to select the best-fitting technique given the situation.
    • Do your homework. Your team leaders may not be familiar with the breadth of the Agile, traditional and hybrid frameworks at their disposal. But there’s help available. Seek out online courses and certifications designed to help organizations and individuals explore and navigate the multitude of Agile frameworks that they may currently be overlooking.
    • Focus on value. It’s great if your gut tells you that your Agile framework is reaping real results, but can you prove it? If your senior leadership has invested in Agile training, coaching and certifications, they’ll demand to see some tangible returns. With well-chosen Agile approaches that match the work required, you will be able to deliver the proof that Agile is driving measurable value that matters. Even further, learning which metrics to use in different situations can help measure this value.
    • Sidestep bottlenecks. By choosing the best WoW for the project at hand, you are more likely to eliminate the wasteful or inefficient processes that can add hours or days to any assignment. Understanding how to unclog these pipes is critical in improving the flow of value to your customers.
    • Motivate with morale. If your team is frustrated and morale is low, productivity, the quality of the work and your retention rate will be, too. But, if you’re able to do Agile well, this can help your teams be happier, more productive and more successful in accomplishing project goals. Ultimately, that means a more joyful customer base, too.

    Conclusion

    In the long run, the framework or approach you choose isn’t as important as your willingness to be open-minded in applying Agile frameworks to projects on a case-by-case basis. As you become more comfortable with new or different approaches, you will promote continuous improvement through carefully considered experimentation.

    That means you’ll become a learning organization, one that is open to change and evolution. With that mindset, your development and IT ops team will do better—guaranteed. Because true agility comes from freedom, not frameworks.

  • Tackling CostOps When You’re a Developer

    Tackling CostOps When You’re a Developer

    The implementation and successful execution of IT initiatives often comes down to developers. From those working with commercial vendors to those working with open source projects, cloud-based software-as-a-service (SaaS) solutions, managed service providers (MSPs) and internal teams, they all play an important role in the successful running of IT and operations teams.

    One challenge developer and operations teams face is the huge time barrier between development and follow-on operations. What a developer builds today for an organization may continue to be used decades from now, and will likely be maintained, patched, updated and modified by other developers. Though it’s a point of pride for the developer—who will have likely moved on in their career—it can be challenging for the operations team who has to continue to deploy it year after year.

    With more applications than ever before, the traditional role of the developer is changing. Today, developers need to start factoring operations cost containment into their responsibilities.

    Opportunity for the Developer

    Developers are rarely responsible for long-term business decisions. Once code is out of their hands, they often have little to no stewardship of their work. The business will make critical IT cost optimization and containment decisions about its code, language and toolchain epochs later. Developers focus on the now and the near future. Spending hours envisioning the one winning outcome out of 10,000 possibilities years later won’t get code out the door or achieve the delivery goals of their managers.

    However, developers have an often-overlooked opportunity to include the gears to activate cost containment support during initial development. From there, if their work is good, it’ll endure; extended support will eventually be necessary. The first step is to ensure new and modernized applications include solid cloud-native monitoring from the outset. This not only helps DevOps and SRE teams but benefits the entire business, who’ll own those applications for the long term.

    Integrating operations-focused monitoring is a top priority for developers. In some cases, an application using platform-managed serverless or orchestrated containerization has no shortage of opportunities to provide developers and operations with detailed performance data.

    A developer’s expertise with dependency analysis, code maturity and ease of integration is a great measurement tool to evaluate tool durability. A solution capable of easily combining cloud-native application performance details with infrastructure performance, user experience and operational expense data is even more likely to help developers and businesses manage costs in the long run.

    A New Dimension

    As cloud-native becomes a mainstream enterprise strategy, cost containment is a key opportunity. To meet the future challenges of application management, leadership is rapidly expanding their definition of application suitability and quality to incorporate all aspects of application ownership. For some teams, cost containment is a new dimension of senior developer maturity.

  • Irreconcilable Differences: DevOps Grapples With Issues

    Irreconcilable Differences: DevOps Grapples With Issues

    DevOps issues can be a thorny subject. The coming together in harmony of Dev (developer) and Ops (operations) represents an arranged marriage of sorts that, for some, will never have a ‘happily ever after’ ending as both parties ultimately grapple with irreconcilable differences.

    But despite the naysayers, the very existence of DevOps as a portmanteau (and perhaps sister labels like DevSecOps, to form a security sandwich) is, in many ways, a validation of the need to form a bond of tighter unity and harmony between two factions that have often been at odds with each other over the years.

    Even with the popularization, extrapolation and democratization that DevOps has enjoyed through the last decade, not everyone will be convinced of its worth and/or its effectiveness—some even doubt its very existence. Some say that DevOps already existed without a formalized label if you look at the software development practices IBM championed a quarter-century ago.

    One thing we can be certain of is that DevOps almost always throws up a few meaty bones of contention. Let’s take a closer look at these issues in the hope that we can harness some of the angst and turn it into positive energy for a DevOps-enriched future. If we are to analyze the most contentious and sensitive DevOps issues in this space, what should we be aware of and how do the big issues break down?

    Is it a Bird? Is it a Plane?

    Arguably, the biggest problem DevOps faces is categorizing it. Some call it a methodology for software application development. Proponents of ‘classic’ software methodologies disagree with this idea as, for the purists, a software methodology can only be Agile, waterfall, extreme, rapid, joint or Scrum.

    These semantics mean that many people would prefer DevOps to be classified as a culture, a workplace ethic, a technique, a culture and/or a mindset or, perhaps in the vaguest terms, an approach. To be truly successful with DevOps you must take a holistic approach and look at the entire development cycle from beginning to end. Closely evaluate the processes that go into development to find bottlenecks and roadblocks to productivity. By finding the areas where your current processes come up short, you will be able to identify the areas to emphasize when implementing a strong DevOps strategy.

    Cloud-Native DevOps

    Anyone who hasn’t been living in a cave since the turn of the millennium will know that cloud computing has grown, faltered occasionally and, ultimately, blossomed to become a new standard barometer for all organizations on their journey toward so-called digital transformation.

    That’s the good news. The not-quite-so-good news is that cloud (and the contemporary drive to go cloud-native) is still complex from initial deployment to ongoing maintenance, management and reporting.

    Taking DevOps into the world of cloud-native will ultimately pay off, but first, there will be challenges as teams get used to the new shape, form and function of the altogether more abstracted and virtualized software toolsets.

    The key to getting cloud-native DevOps right will be a prudent approach to monitoring and observability. As cloud-centric DevOps teams ingest the logs, metrics and traces they need to perform solid and dependable system observability, they will need a consistent set of tools to monitor and observe systems in the long term. Within this practice, it will also be important to remember that monitoring shows you lower-level granular information related to system performance. Observability includes all the information gleaned from monitoring and also includes higher-level tools, some of which will be data visualizations for DevOps practitioners to use. When the two are combined for cloud-native DevOps, system health can be optimized, preserved and maintained while any debugging or root cause analysis is executed at the lower level.

    Machines in the Application Loop

    With machine-to-machine events now happening more prevalently inside the internet of things (IoT), the need to capture, integrate and analyze the event streams that go on outside of the human loop and bring those log metrics back closer to the sphere of ‘human’ software engineering is not a plug-and-play quick fix.

    Getting machines to play nicely and be a part of expansive and progressive DevOps teams should be a given. After all, they’re just machines. In reality, there will be specific skills needed and human DevOps personnel will be required to get used to updates and other alerts that they have not considered before.

    AIOps and Automation Limits

    Related to our last point on machine events, we need to think about AIOps. When we build AI-driven DevOps and create AIOps, we will need to stop and question where we set limits on process automation and where the wider elements of automation hit the limiter/restrictors. To know just how far we should build out our AIOps practice, exhaustive auditing and analysis must to be carried out; the whole technology proposition here is no simple point-and-click affair. Even when we do establish workable AIOps, know that there will be perimeters.

    Add all that to the fact that some AIOps implementations will require what we like to call ‘human handoff’ support when the AI intelligence engine doesn’t know what to do next and needs additional data and training—only then can we start to appreciate that AIOps itself is no simple plug-and-play affair.

    Lift and Shift Doesn’t Scale

    One of the unfortunate truths in too many real-world IT shops today is that, where the cloud is used, it is used poorly. Too many technologies are unceremoniously lifted and shifted to cloud instances that an organization procured. This makes cloud-centric DevOps harder to achieve. But why?

    Because what happens back down in terrestrial (i.e., non-cloud) programming is the development of individual cross-functional software teams. This silo-based approach happens due to corporate legacy structures, company management systems and, sometimes, for personal, parochial or cultural reasons. When different teams are all reinventing wheels (running diagnostics tests, setting up CI/CD pipelines, delivering upgrades and so on) that should be shared and accessible to all, a natural level of inefficiency surfaces.

    DevOps Issues: Conclusion

    These are the five most contentious DevOps issues in the near term, and it would, of course, not be too hard to find and categorize even more. In the future, we might even need to argue over which developers should be categorized as core devs and which core members of the operations department to include.

    For software developers, software architects—really, all the software engineering professionals who work in systems administration, database admin, testing, security and all other forms of operations—there’s quite a lot at stake and quite a lot to fight over. And if you ask me, that’s what makes DevOps great.

  • Elevating Agile With Financial Discipline

    Elevating Agile With Financial Discipline

    A corporate axiom is changing, shifting from “Big eats small” to “Fast eats slow.” But change doesn’t happen overnight.

    While Agile and lean methods continue to chip away at the status quo, making gains and increasingly moving beyond pockets of teams to the portfolio and then enterprise-wide adoption levels, waterfall approaches to delivery persist.

    Rumors of waterfall’s demise, it seems, have been somewhat exaggerated. A survey conducted by the Scrum Alliance (2017) of Scrum practitioners revealed that 78% of respondents said they used Agile-Scrum practices in parallel with waterfall practices. Mixed waterfall/Agile environments are complex. For many large companies, this is the norm. This is when the cohabitation challenges of agile and traditional workstyles become more glaring.

    Importantly, as IT finance management (ITFM) leaders know, becoming “more agile” doesn’t give you a pass when it comes to financial discipline and oversight. Agile organizations are still responsible for their ROI and saying you’ve adopted lean methods doesn’t automatically make you lean. Or fiscally responsible. Or well-governed. Or profitable.

    ITFM Leaders are Under Pressure

    Technical organizations are in the midst of evolving from being project-centered to product-oriented solution delivery and scaling Agile from the team level up to the portfolio/enterprise. In these evolving, hybrid working environments, faced with larger and more vocal agile communities, ITFM managers are facing increasing process dissonance between traditional and agile methods, wreaking havoc with their reporting, planning, budgeting and oversight.

    In a blended traditional/agile financial portfolio, understanding the true cost of projects, portfolios, value streams and OKRs helps companies make better use of their financial resources to drive profitable outcomes.

    And with interest in the value of IT spreading beyond the CIO to the rest of the C-suite, integrated reporting and decision-making that combine Agile work with traditional IT projects, the ITFM role itself is even more essential.

    Technology Business Management: Accurately Measuring the Cost of IT

    For many ITFM leaders, a focus on the discipline of technology business management (TBM) has improved their ability to better understand IT costs and influence governance and behavior through targeted analysis of real-time reporting (and chargeback) for IT resources. TBM provides a decision-making framework to help leaders understand the true costs involved in the delivery of products and services to customers. That has worked well, particularly in industries where project-centric, traditional waterfall projects are the norm. As it turns out, it works very well for supporting Agile, too.

    As agile gains momentum, finance is where it collides with P&L statements, budget dollars and fiscal quarters. With the seemingly irreconcilable Agile release trains and program increments, story points and cycle times, it can be difficult to see an integrated path forward. Fortunately, for teams that have embraced it, TBM provides a well-tested, proven framework that is easily extended to support enterprise Agile transformation.

    Agile transformation and scaling initiatives occur as teams of teams seek to reap the rewards of end-to-end enterprise agility.

    And, as enterprise agility expands, ITFM leaders will likely encounter process improvement initiatives that are key to an Agile transformation and that directly influence IT finance. Central among them are lean portfolio management (LPM) and value stream management (VSM). Due to their direct influence on ITFM and their intertwined agile characteristics, these two especially deserve early focus. And, while there are certainly more dimensions to enterprise agility, this is a good place to start.

  • THE UPSKILLING IT 2022 SURVEY IS NOW OPEN

    THE UPSKILLING IT 2022 SURVEY IS NOW OPEN

    IT SKILLS IN FOCUS

    By Eveline Oehrlich, DevOps Institute

    According to McKinsey, nine out of 10 global executives and leaders are saying that their organizations are facing a skill gap or expect to develop additional skill gaps in the next three to five years. During the past few years, IT organizations, in particular, have already been facing skill gaps. The desire to accelerate technical innovations and digital transformation only makes it harder to identify and narrow current and future skill gaps. IDC predicts 75% of organizations will have a comprehensive digital experience implementation roadmap by 2023, up from 27% today. While 2023 is still a few years away, it is essential that IT organizations prepare for what skills are necessary, how to manage their talent supply and look at the underlying skills of people that must support this digital journey.

    DevOps Institute research team and sponsors, Palo Alto Network, Cycloid, and The Linux Foundation, are excited to announce the launch of the Upskilling IT 2022 Survey. The survey takes approximately 25 minutes to complete, and we’d love to hear from you. Your answers will allow us to better understand which IT skills are essential for the future, ensuring that organizations are able to accelerate their digital journey.

    The Upskilling IT 2022 Survey, by DevOps Institute with its yearly sponsors, is the only and longest running research of its kind. The results provide an unbiased view into what skills are essential across a variety of IT and other skill domains.

    Like the past three research reports, our goal following this year’s survey is to share a detailed analysis to help various leaders and roles, in order to help them determine what skills they should hire, retrain or upskill for, following the publication of the Upskilling IT 2022 Report in the first quarter of 2022.

    Don’t let IT Skill gaps be a competitive liability for today or in the future

    The survey is open for everyone, regardless of the size of your organization, or your organization’s industry. This year we have expanded the focus beyond DevOps and are homing in on cognitive and human skills.

    Some of the key topics we look to deep dive into this year include:

    1. Exploring where the biggest skill gaps currently exist and within which roles, such as leaders, developers or operations.
    2. How skill gaps are identified across the IT industry.
    3. How upskilling is done, funded and executed.

    While each person has their own unique experience, expertise, examples of execution or outcomes and various tolerances for exploration, for the fourth year, we are setting out to explore what the must-have skills are within different skill domains. This year we are focusing on the skills needed within modern IT organizations today and in the future.

    There are a variety of roles that are involved in recruiting, hiring or working within IT organizations. We are setting out to highlight and understand which must-have, nice-to-have and optional skills are essential within key skill domains. The skill domains include Automation, Human skills, Technical skills, Functional skills and knowledge, Process skills and framework knowledge, Business skills and leadership skills. We are targeting the community of IT leaders, developers, practitioners, team leaders, consultants, human resources and other individuals who are familiar with modern IT best practices, such as DevOps. We are targeting all industry verticals and all company sizes. Our survey questions are developed with input from a variety of team members and experts, and our goal is to achieve a sample size of 4,000 individual responses across North America, Europe, Asia Pacific and Latin America.

    Help us shape the future of IT and DevOps and make your voice heard by completing the survey now.

    The survey will remain open until January 31, 2022. We look forward to hearing from you.

    Take the survey now:  https://www.surveymonkey.com/r/Upskilling2022Blog

  • Datadog Allies with BigPanda on AIOps

    Datadog Allies with BigPanda on AIOps

    BigPanda Inc. and Datadog today announced they will integrate their respective platforms to make it easier to form artificial intelligence for automating IT operations (AIOps) to consume data generated by the Datadog IT monitoring service. The two companies are pledging to invest in a go-to-market partnership to create a comprehensive platform for monitoring, analytics and incident management.

    As part of that effort, Datadog is committing to making available an “integration tile” through which BigPanda will also be able to feed root cause analytics based on machine learning algorithms into the Datadog console. That capability will be enabled by a service-to-service topology map created by Datadog that will be used to drive event enrichment, correlation, impact analysis and prioritization.

    Mohan Kompella, vice president of product marketing for BigPanda, said Datadog affords his company a unique opportunity to better train AI models using a massive amount of IT and security metrics that Datadog aggregates daily. That data can then be combined with data ingested from other IT service management systems, which will enable IT operations to automate processes using better-trained AI models, added Kompella. Thanks to modern application programming interfaces (APIs), Kompella noted it’s become a lot easier for platforms such as BigPanda to consume a wide range of data.

    The more data an AI model is exposed to the faster it learns about the IT environment an organization is seeking to automate. Each IT environment is unique, so it usually takes some time for AI models to be optimally tuned. The more data that’s made available, the faster the AI platform is able to make accurate recommendations. It’s then up to each IT team to decide to what degree they want the AIOps platform to automate a task based on those recommendations versus implementing themselves. The more accurate the recommendations become over time, the more confidence IT teams gain in the AIOps platform.

    Of course, IT environments tend to change rapidly and evolve in the DevOps era. The alliance with Datadog will provide BigPanda with a primary source of data from tools that are already widely employed by DevOps teams.

    Ultimately, the goal is to reduce the mean time to resolution for IT incidents, in addition to eliminating as much as possible the need to invite developers and IT operations teams to a “war room” meeting to discover the root cause of an issue. Many IT teams these days find themselves spending weeks trying to ascertain the root cause of an issue that, once discovered, only takes a few minutes to fix. AIOps platforms afford IT teams the opportunity to eliminate a lot of friction that currently exists in those complex IT environments that have scaled beyond the ability of humans to manage without some AI assistance.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, interest in AIOps is clearly on the rise. IT environments continue to grow in size as the enterprise IT becomes more extended. It won’t be long before most IT teams expect to be able to leverage AI to manage highly distributed computing environments. It may, of course, be a while before IT teams fully trust those platforms; however, it’s also clear IT as a whole is reaching a point where there is no alternative.

  • Jump Over the Hidden Barriers to Digital Transformation

    Jump Over the Hidden Barriers to Digital Transformation

    Digital transformation is critical to success in the new normal. Here’s how to achieve it in an uncertain economy

    Bit by bit, we’re reopening the economy. No one knows how long it’ll take to get the economy back on track or what kind of regulations there will be to keep everyone safe. But we do know it’ll take a great deal of tech to get the machinery running again.

    Consumer expectations have changed. Many in-demand employees have learned how much they prefer the flexibility of working from home—so much so that startups and even large corporations are launching “work from home forever” plans (and we can expect companies in other sectors of the economy to follow), and they need to adjust their tech to make this possible.

    Digital transformation—the term we seem to be stuck with—will be the answer; companies that put it off now have to play catch-up.

    Everyone’s trying to regain lost customers. They also don’t want to lose their top employees, who now expect to have a remote workplace (or at least the option of one).

    We’re in a reluctant revolution, and many companies are short on cash because incoming revenue isn’t quite what it was before. There’s never been such a big need for digital transformation while keeping a close eye on the budget line.

    Speak the Language of Business

    Before COVID-19, a McKinsey survey concluded transformation is more challenging to pull off than traditional change efforts: Fewer than one-third of organizational transformations succeed at improving a company’s performance and sustaining those gains.

    A key reason for the failures: a lack of clear, measurable business goals. Right now, no matter the business, eyes everywhere are on IT. To push through the transformation, you need to benefit not just yourself but your organization. You need to be able to speak the language of business, and here’s how you can do it.

    Make It C-Suite Friendly

    If you’re going to ask the company to support your program, talk about it in a way the C-suite can understand. Think about the use case they’ll be most interested to hear about. Shortening customer wait times? They’ll care. Aiding supply chains? They’ll listen.

    Remember, they’ll want numbers, too. The C-suite will do a cost-benefit analysis, but you should preempt this by conducting one beforehand. This shows your commitment to making the company more successful and inspires trust in the project through data. Avoid using too much technical jargon; doing so will get glassy-eyed looks and perhaps inspire them to give some other department a budget increase or greenlight a different project.

    Develop Your Soft Skills

    Never make the C-suite do your work for you: Make them understand the value of your plans. Doing so may develop your soft skills.

    At SolarWinds, we goad each other with the line, “Explain it to me like I’m 5.” If we can’t do it, then we know we don’t understand the concept well enough to “sell” someone else on it.

    Explain your program to someone using simple language and measurable goals, but explain it so clearly a 5-year-old can understand it.

    And remember, if you’re working remotely, you’ve lost the possibility of a hallway conversation. You can’t meet somebody in an elevator and throw them a pitch. You may only get a moment on a Zoom call. So work on your game. Practice your pitch on someone not involved—even a loved one at home—who can give feedback on the level of comprehension for the end goal.

    It’s not always as simple as you think, and sometimes you’ll need to go above and beyond. This may mean taking a course, reading a book, or watching a YouTube video to improve communication. But do it anyway. You’re learning a new language, so use every tool at your disposal to relay your transformation pitch.

    Develop the Process Documents

    Once you have approval for your initiative, nurture it. Make sure it succeeds.

    If the program has been customized, explain why and give out customized documentation. Your goal is to turn end users and the staff into evangelists.

    In departments I’ve worked in over the years, I’ve often noticed a failure in this area. No one properly explained the goal. They maybe have buttoned down the tech, but the humans didn’t understand why they were using it instead of something else. They couldn’t explain it to someone new because no one produced the process documents.

    And when they can’t explain it, here’s what always happens: One person makes an effort and becomes the department expert. False information develops. No one wants the program to succeed because they hate it. You end up with a boondoggle.

    Clean Out Your Closets

    While working from home, you probably focused on your closets and were amazed at the stuff jammed in there.

    Do the same at work. What’s the business value for those apps you have? Do you have multiple systems in different departments?

    Use monitoring to assess usage. You may save money when you realize there are plenty of apps on hand you’re not using to their full capability.

    You could also discover you already have the functionality you need—you just didn’t know it because only one department used the app.

    I’ve worked with a lot of companies where one person was using an app nobody else knew about. Someone had to approve the budget line, but it was a blip on the radar. When you have ten blips on the radar, it can add up. Do you need all those blips?

    I can’t count the number of times I’ve seen people with oddball applications somebody built at some point. Clean out the closets. Taking inventory will help you find ways to work toward business efforts at little to no additional cost. Saving the business money while achieving progress toward digital transformation during this time is a big deal.

    Monitor Your Whole Stack

    If you can monitor from the database to the network connection and then from the application to the front end, you get the entire story without the guesswork. This is why I like to monitor the whole stack.

    You can correlate this data and see what went wrong. You get the information capable of helping you fix the problem and prevent it from happening again.

    But monitoring is different than alerting. I’ve come across this countless times: People set up too many alerts, which they later ignore because of fatigue. No one wants to discover their website has been down for a half-hour and no one knew about it because the emails were ignored.

    Instead, start by setting up monitoring on anything potentially important. Then get alerts on actionable things: You need to know about them because you can do something about these issues when you receive an alert. If you’re not going to work on issues until the next day, maybe you don’t need an alert at 2 a.m. Better still, automate actions where you can with alerting.

    Conclusion

    It’s a confusing time. No one knows how this story will end, so let’s button up the details. Learn how to speak the language of the business sending you a paycheck.

    Help those paychecks keep coming by thinking in terms of what will help the company transform and succeed. Then communicate those thoughts in the language of business.

    Monitor your stack and clean up: If you can clean out the mess, you’ll save money, and maybe you’ll be ready for what’s to come.