devopsy.kinsta.cloud

Tag: processes

  • BMC Adds Generative AI Capabilities to Helix Management Platform

    BMC Adds Generative AI Capabilities to Helix Management Platform

    BMC today revealed it is embedding generative artificial intelligence (AI) capabilities across its BMC Helix service and operations management platforms.

    BMC CTO Ram Chakravarti said the company is incorporating the open source GPT-J large language models (LLMS) to build generative AI models. Those models are optimized for specific domains using data collected by BMC and imported from other data sources, like the Jira project management software from Atlassian. That persistent layer of storage is designed to aggregate multiple types of data within what amounts to a Helix data lake.

    The generative AI capabilities added to BMC’s portfolio include natural language summaries of issues and events captured by BMC Helix Operations Management, along with an ability to create a historical analysis of a user’s specific environment to identify recurring issues more easily.

    BMC Service Management, meanwhile, can now correlate incidents and provide resolution summaries that can be stored. It’s also now possible to run clustering analysis on chat archives to find new or improved utterances that help virtual agents answer queries better and execute workflows.

    BMC initially opted to build its own LLMs because general-purpose LLMs—such as the one created by OpenAI—are subject to “hallucinations.” Hallucinations are created when incorrect data is included in a model. BMC is training its LLMs on a narrow range of trusted data to ensure the recommendations and subsequent automations it creates are valid.

    Over time, BMC will add additional LLMs; the company hasn’t yet decided if there are use cases where it makes sense to rely on an existing general-purpose LLM to add additional capabilities, noted Chakravarti.

    Organizations can also opt to use a containerized version of the BMC LLM if they prefer, but BMC will encourage most organizations to invoke generative AI via its Helix SaaS platform, he added.

    BMC Helix is an IT services management (ITSM) platform that integrates with a range of DevOps platforms. Helix is part of a larger existing BMC Connected Digital Ops initiative that seeks to unify ServiceOps and DevOps with AIOps, DataOps and AutonomousOps. Generative AI will automate a range of tasks from within Helix that can then be extended to DevOps platforms such as Jenkins.

    It’s still early days as far as applying generative AI to processes, so organizations should focus on use cases where it will add some immediate value, said Chakravarti. Once they develop a level of trust in the automation created and executed, they can then pragmatically expand the number of generative AI use cases where they make sense, he added.

    One way or another, generative AI is going to be applied to the management of IT. Many routine tasks that conspire to limit the productivity of IT teams today will be eliminated, but there will always be a need for a human to remain in the loop to ensure the right outcomes are achieved. However, it will also soon become possible for existing teams to manage IT at levels of scale that were previously unattainable.

    Image source: Photo_Credite_Indira-Tjokorda via Unsplash

  • 7 DevOps Lessons in 2018: The Path to DevOps Success in 2019

    7 DevOps Lessons in 2018: The Path to DevOps Success in 2019

    We all learn from mistakes, right? But it would be better if we learned faster and didn’t repeat them in our future exercises. And this is exactly what we will discuss here in this blog.

    For a while now, we’ve been overwhelmed by the idea of the DevOps principle. We love how the collaboration between development and operations provides room for automation, continuous integration/delivery and enhanced time-to-market.

    But what about the tiny shortcomings we overlook in the process of continuous delivery?

    Listed below are some of the don’ts—or, rather, lessons learned from our DevOps implementation in 2018:

    Gauging Employee Capacity Over DevOps Delivery

    When Carmen DeArdo, Tasktop’s senior value stream management strategist, posed two questions to a crowd of 200 people, they had no answer to give. What were the questions, you might ask?

    • How many treat their delivery pipeline tooling as an integrated product with a product owner and an architect?
    • How many have any measure of how long it takes for them to deliver a feature or defect?

    Companies treat their delivery pipeline tooling as different components along the delivery chain. And, when it comes to measuring time taken, all that matters is getting the product to the finish line.

    These components are important if companies need to avoid obvious mistakes on the path to success. Consider the above questions the next time you set out on your DevOps mission. Within this aspect, measuring team happiness is as important as an integrated delivery pipeline tooling, and time is taken to introduce a feature.

    Companies need to strike a balance between managing work and achieving team happiness. This is important if the company has a long-term vision. Unhappy employees burdened with work don’t deliver the expected results. A sustainable pace helps companies ensure that employees don’t succumb to pressure.

    Revise the Management Strategy

    Organizations need to encourage their managers in a way that they are not put off by the DevOps process but rather motivated to build and maintain their team.

    Most organizations emphasize giving managers incentives to deliver expected results, maintain quality, expand team size, set immediate goals and rake larger profits. However, this strategy could backfire when applied to a DevOps implementation.

    Companies instead should encourage their managers to create an environment where the teams grow and become flexible, not only contributing to that process but also adding value to other processes, hence, the organization’s overall success. This thought process will lead to a chain of positive outcomes.

    Upskilled and Cross-Skilled

    Gone are the days when specializing in a particular skill was rewarding! The competitive market is looking for a workforce that is upskilled and cross-skilled. In short, employees need to be a package of multiple skills, with an emphasis on soft skills.

    Being multi-skilled not only supports transformational goals but also supports an organization’s goals. When the lack of new skills becomes a constraint, companies must invest in hiring individuals to propel transformation, which is equivalent to investing in automation.

    Automation ≠ DevOps Success

    Somewhere between adopting the DevOps culture and being DevOps-equipped, professionals have shifted from the purpose of DevOps to automation.

    In the process, people have lost control over the overall management of DevOps. Either professionals are in a situation in which the code is not built in the intended way or that the automated part is managed but the steps required for automation are not.

    Organizations instead should refocus their attention on the scalable nature of DevOps, building a new, fully automated process rather than automating an end-to-end process over time, as it is difficult and also time-consuming. Hence, automation does not equal the DevOps mission accomplished!

    From Idea to Blackboard

    DevOps once was more an idea of a team discussion rather than full-fledged process. But we saw 2018 transform DevOps from a mere idea to a part and parcel of everyday business—so much that it defines the way businesses plan their finances, regulations and organizational strategy as a whole.

    Additionally, DevOps experts in 2018 emphasized the need for value delivery than just focusing on details of technical practices. This can be achieved by constructing a managerial framework that bridges the gaps between business and technology.

    Relieve Your DevOps of Old Tech

    Last year also witnessed DevOps professionals moving toward new technology such as containers, Kubernetes and serverless. Why? It’s obviousthese technologies enable DevOps to deliver its promises. Trying to innovate the DevOps process or even innovate its end product with old technology will only take you backwards in the DevOps process.

    In 2019, we should realize that holding on to old technology will mean limiting your organization’s capabilities and impact.

    Identifying the Right DevOps Adoption Patterns

    While there are several DevOps adoption patterns out there, some organizations choose a central DevOps team enabling standard CI/CD tooling. The approach is in sync with DevOps thought leaders’ approach of reducing global complexity.

    However, this approach fails at catering to the needs of different teams. With the focus only on addressing CI/CD tooling, many centralized teams struggle with adoption.

    In another approach, companies seek to engage ambitious and autonomous tools to use DevOps tools and practices.

    This approach tends to match the common DevOps belief, ‘First prove that new work methods fit the enterprise, then spread.’ However, these teams are only successful in delivering projects with high levels of automation involved but have quickly failed to convert team-level experience to company-level.

    A 2019 DevOps adoption approach should focus on having high levels of team autonomy and reducing global complexity.

    Here are some tips to help you achieve this:

    • The central architecture team collect and share recommendations about languages, libraries and tools.
    • Teams consider these recommendations and experiment to see if there’s an opportunity for greater gain.
    • If things aren’t working, teams can change change and undo dead-end technology decisions/ideas.

    Now that we are ready with our lessons, it’s time to go live! Are you ready for your DevOps 2019 showdown?

    — Veritis

  • DevOps Transition: The Cultural Commitments and Challenges

    DevOps Transition: The Cultural Commitments and Challenges

    Enterprises can achieve certain levels of success by filling a need in the market, hiring skilled teams and utilizing cutting-edge tools and technologies. However, to set themselves apart and chart a course for long-term success, they need to address the values, beliefs and behaviors that make up organizational culture as carefully as they address business decisions. It’s culture that ultimately informs the decisions made about how a company evolves its concepts from idea to value, so when you want to make a change and grow, that’s where you need to start.

    One area where culture is particularly important is the introduction of new practices and processes applied to software engineering and the role that a DevOps strategy plays within organizations. DevOps encourages a mindset of communication, collaboration, integration and automation among software developers and IT operations, so it’s more than just a new set of tools; it’s a cultural shift. This change doesn’t happen immediately or automatically, it requires deliberate steps and actions to be taken, and calculated decisions to be made.

    The shift also requires commitment. A recent Gartner report, “New Insights into Success with Agile in Digital Transformation,” found that organizations must be prepared for a commitment of three or more years to ensure success when moving to a more agile development process. Teams with less than a year of experience with a new development process show a success rate of 34 percent, while that rate jumps to 64 percent with between one and three years of experience. After three years of agile experience, the success rate skyrockets to 81 percent.

    New Technologies Accelerate Momentum, not Create It

    Implicit in the decision to move to DevOps is the desire to develop faster. To do that, organizations often begin the process by saying to themselves, “We need to automate things.” They buy a variety of testing automation tools, production delivery tools and anything they think will make them more agile. However, if they don’t take steps to prepare the people in the organization, things can get worse, not better, because the new elements can create isolated teams centered around “campfires” where separate teams use the various new automation tools individually.

    When teams are undergoing transformation, we often see them go through a roller coaster of up-and-down results. This was illustrated in the DORA report, “Accelerate: State of DevOps 2018: Strategies for a New Economy.” When the transformation begins, teams quickly identify wins and automation helps lower performers improve, creating an uptick in overall performance. However, as the process moves along, automation increases test requirements, which are still dealt with manually, and a pile of technical debt blocks progress. At the same time, the mounting technical debt and increased complexities cause additional manual controls and layers of process around changes that, more often than not, slows work. Teams generally don’t see an upswing in results until putting in relentless efforts toward improvement, leveraging expertise and learning from their environments, which finally results in a jump in productivity.

    This is a moment when organizations need to lead with their brains, not their pocketbooks, and stay committed to the process. To minimize the risk of failure, they must address the people and the process with the same rigor and commitment they address the technology. In fact, evolving the culture and process associated with how people work is the biggest challenge in adopting DevOps. People resist change and no amount of technology makes change easier.

    Any initiative that begins with just buying software or technology to make the organization agile is a mistake. The best way for a business of any size to launch a DevOps initiative is to get people comfortable with the vernacular and the process before changing anything. I’ve seen organizations go so far as to change the name of existing processes just to get teams thinking differently before the real change is made.

    Putting in Tools Before a Plan is Like the Cart Before the Horse

    After seeding the terminology and idea of change, the next step has to be tactically thinking through how the organization will evolve. It’s often thought that tools will make an immediate impact, but not enough planning is done to integrate the tools before being taken out of the box. Basically, they end up like a bunch of kindergartners at recess: Everyone has their own toy to play with but they do it alone and no one works together.

    Before putting in new tools and changing processes, there needs to be understanding around where the gaps and inefficiencies are so KPIs and metrics can be mapped back to tell where progress is being made. You can’t manage what you can’t see, so you have to develop visibility into the process to understand where those inefficiencies currently are. When that is achieved, remaining constantly vigilant to understand the constraints that exist while establishing new processes and using the new DevOps tools will allow you to continuously improve.

    It needs to be known that the reward is worth the risk. Making the move to DevOps can’t be thought of as a decision or a choice, it’s an imperative for organizations that want to remain competitive. Every organization needs to become a software company and to do that they need to move to DevOps and make continuous improvement part of their DNA. Organizations can’t fear the move, they just need to be diligent with the transition, monitoring and follow up when adopting DevOps.

    — Bob Davis

  • Roadblocks to Successful DevOps Often Human, Not Technical

    Roadblocks to Successful DevOps Often Human, Not Technical

    Usually, when people talk about DevOps, they focus on the technical aspects. However, in my experience we need to highlight what lies behind technology: the people. To effectively implement DevOps, we have to understand that many obstacles are not technical, but human.

    In working with various organizations in their DevOps journeys, I have seen six main roadblocks to a successful DevOps implementation:

    1. We mistakenly blame technical obsolescence: Tech teams should avoid justifying slow processes and lengthy deployments just because of the existence of old systems. To do the best with current systems, analyze your workflow and decide whether the problem is less a matter of technical tools, but one of attitude and organization.
    2. We don´t cooperate: DevOps doesn’t work unless teams can work together. There are three steps to building collaborative teams. First, work hard. Your good work speaks for you; it gains you the respect and cooperation of your colleagues. Second, highlight the contributions of others. Offering recognition shows that each member of these diversified teams is important. Finally, learn how other teams are being evaluated so that you better understand their behavior and can work with them in achieving real cooperation.
    3. Our egos get in the way: Ego leads us to believe that our approach and knowledge apply to every problem and that we can simply solve these issues. It prevents empathy and the ability to properly help to those who come from a different context or background. In DevOps teams where people come together from different perspectives and backgrounds, this is particularly important. So please check your ego at the door.
    4. We are unwilling to leave our comfort zone or the status quo: DevOps is about speeding up processes and providing new ways to work. As a result, DevOps teams should question traditional methods and understand that some rules no longer apply in the digital world.
    5. There is a lack of leadership: DevOps teams succeed under real leadership. Real leaders give visibility to everyone and understand that anyone can offer critical contributions, even when least expected.
    6. We suffer from cognitive bias: Cognitive bias comes from our background, our personal experiences and our careers. However, we shouldn’t let this condition us. It is essential to move forward and understand that our experiences and knowledge do not apply to every context. DevOps teams must be aware of cognitive biases to build a proper solution for problems that may arise.

    These six human aspects can often form obstacles to DevOps implementation. To help overcome these challenges, I typically recommend three broad strategies to organizations:

    • Technology is a means but not an end. It is important to understand that technology is what helps us solve problems, but it’s not the solution in and of itself.
    • Understand the problem and find balance. Avoid over-engineering; you do not need to prove how much you know about technology in general, you need to find the proper solution.
    • Be humble and curious. Technology is never static. There is always something new to learn. In the field of DevOps, it’s critical to constantly investigate and renew ideas.

    A successful implementation of DevOps is not only about automation. It is also about people who make decisions and use tools. However, for many enterprises, transitioning to DevOps represents a fundamental shift in how individuals and teams will have typically worked in the past. This is why I encourage DevOps teams to evaluate their workflow and be aware of aspects such as ego or biases, as they do affect performance. Handling these situations might require professional assistance. I suggest working closely with human resource professionals or turning to business psychologists to understand these human aspects. In turn, this will enable your DevOps teams to walk toward success.

    — Ernesto Cardenas

  • Simplifying Through DevOps in Banking

    Simplifying Through DevOps in Banking

    There are a great many assets available on the internet that talk about what DevOps is and how far DevOps adoption has come. So we will not repeat the “what” and the “how far.” Instead, we will focus on the road ahead and future of simplification and transformation at banking organizations and the role DevOps is likely to play in the same—in all three areas of “Run the Bank (RTB),” “Change the Bank (CTB)” and “Transform the Bank (TTB).”

    Figure 1: Change-Run-Transform Bank – POA with DevOps Maturity

    In this article, we take a look at what shape we think DevOps-driven simplification in financial organizations can take in the near future and also some opportunities for such simplification. As depicted in Figure 1, with DevOps maturity, the siloed processes of CTB, RTB and TTB will come closer together, allowing common activities and processes to be carried out in one place. The others will get simplified and automated thereby reducing elapsed time of cycle from ideation to production and application management drastically. This will yield benefits not only in terms of cost and time, but also in terms of feature availability to business.

    Banking Focus

    In banking, the early adopters are leading the march with a lot of good practices such as standardized tooling for specific technology areas, orchestration, feedback loop setup, process and technology rationalization, etc. The focus needs to continue on the same.

    We think that the challenge that DevOps architects need to now focus on is to be able to use DevOps to help financial organizations bring down the non-discretionary spend by simplifying the previously ignored maintenance, operations and infrastructure realms. The core of this DevOps driven simplification is needs to be move cost of maintenance to its lowest possible and hence releasing funds to discretionary areas in “Change the Bank” and “Transform the Bank.”

    While the point of arrival for DevOps-led transformation should be “full automation” and “zero maintenance” but they are a bit far in the future because the return on investment (ROI) on the monies and effort required to make that happen needs to justify the same. We see the focus shifting to value delivered to business by transformation of an application or suite of applications. Figure 2 depicts the core repeatable activities of a DevOps-led simplification exercise while keeping in mind these improvement cycles need the setup of feedback loops at each stage.

    Figure 2: Repeatable activities for DevOps-led simplification

    This brings us to our next idea, that the road map to DevOps-enabled simplification needs to be paved with metrics and measures and these metrics cannot be randomly chosen. These metrics have to be actually measurable and be divided into two areas of business metrics and IT metrics as we explain below and need to be diligently tracked to aid course correction.

    For example, release orchestration processes for applications are mostly complicated, need a lot of manual effort, have strict compliance requirements as well as security mandates, need to be carried out more frequently nowadays because of shorter deployment cycles and have to manage ever-increasing complexity of component interaction (upstream and downstream). Now, release orchestration is also a very important step in the entire CI/CD pipeline. So standardization and simplification of release orchestration process makes immense sense. But how does one measure success and quantify improvement?

    As already stated, intelligent insights (metrics and measures) are important in this process for both business and technical team members so that everyone has single source of truth for current status and distance from end goal. This kind of automation also helps focus on the continuous improvement pillar of DevOps adoption by logging everything that matters, have frame-by-frame data for everything that helps. This collection of metrics aids analysis of success as well as failure thereby furthering the cause of continuous improvement.

    Continuing with the example of release orchestration, there are many important best practices that help ensure that wheel is not reinvented. Some of the important learnings that only practitioners will be able to let you in on are as follows:

    1. Tools that need scripting will not be able to help you scale and create low-maintenance solutions.
    2. You need to invest in tools/orchestration solutions that help you visualize, get intelligent insights in a jiffy and can report in a variety of forms and shapes.
    3. Tools need to be able to capture and track business metrics, too.
    4. You need to spend effort on organization level compliance and security.
    5. Strive to automate your most effort-intensive and/or lengthy processes.

    Each step on DevOps maturity scale will have many such learnings and best practices that must get shared across the length and breadth of the organization.

    DevOps and Banking: Future Trends Prediction

    Based on our understanding & knowledge of financial organizations, we believe that the following areas will see focus in the next few years:

    Figure 3: Trends in short-medium term in DevOps adoption

     

    Continuous Improvement within Federation

    • Technology teams will need to enable and encourage localized innovation within a federated boundary of toolsets that will, in time, bring Dev and Ops toolsets to near mirror images of each other.
    • By federation, we mean a detailed homogeneous blueprint that gives flexibility but within an overarching boundary of tools and procedures while encouraging continuous improvement.
    • This must also inform relevant stakeholders about areas for continuous improvement that make the most evolutionary impact to business and use metrics suitably to track and reward improvement.

    Outcome Management

    • We also think that DevOps adoption needs to be driven by outcome management with evidence of impact taking the driving seat for road map management.
    • Focus will be on point of arrival (POA) and continuous measurement of business and IT metrics for outcome management.
    • We also believe that Culture-Automation-Lean-Measurement-Sharing (CALMS) model of DevOps will find more believers.

    Evidence of Impact

    • Metrics and metrics-based course correction will become the Holy Grail in the simplification exercise. The metrics collection will need to focus on areas of both business and IT. The metrics and measures will need to be redefined as:
      • Business Metrics for business value delivered or improved such as new products / services launched, conversion rate, net promoter score (NPS), customer retention rate, CSAT, ESAT, etc.
      • IT Metrics for value improvement and value management such as cost performance index, reduction in defect debt, reduction in lead time to change, etc.

    Design Thinking

    • We believe that the next big disruptor in this space will be bringing design thinking into the mix to ensure that DevOps-led automation is more customer-centric and iterative.
    • We see focusing on test data management (TDM) across the organization as an important step to ensure continuous delivery.
    • In our opinion, the testing process will undergo complete rethink with support of processes such as risk based priority and risk based test case design, test bed splits, TDM and so on.

    KM, Training and Governance

    • Tools and processes for knowledge management, training and governance need to ably support the DevOps-led simplification.
    • These processes will need systemic focus to create and nurture self-learning technology teams.
    • Transformation of the way of working to rationalize processes such as collaboration for lean and improved handover of work packages.

    DevSecOps

    • Security will be extremely crucial in the process of DevOps-led simplification. All the automation, cloud adoption, pipeline creation, IoT adoption and more is throwing up many new security concerns, thereby leading to a focus on DevSecOps.
    • Security processes will potentially need to move their execution points up in the CI/CD pipeline and be divided into stages based on iterations sizes and deployment cycles.
    • Focus on shifting left application security and role-based security.

    Conclusion

    The next wave of simplification of IT spaces in banking organizations will be aided by DevOps. To look for opportunities, a systematic approach toward DevOps will help—it will be perilous to ignore detailed assessment of existing spaces that will detail the current state, point of arrival simplified state, road map for simplification and the key guiding principles for the transformation.

    Carrying out pilots and proof of concepts in DevOps is not a problem; the challenge is with scaling—in all areas: tooling, training and processes. The key is to manage the horizontal and vertical spread of same/similar toolsets that also help drive efficiency associated with scale and standardization. DevOps-led simplification will need changes to processes, technology and people management (culture). The current role structures might need to be demolished to ensure there are no fiefdoms and cross-functional teams handle all requirements of Dev-Test-Ops. Finally, all the changes need to be able to define the new way of working  so that Change-Run-Transform organizations can be brought together.

    This article was co-authored by Babu Unnikrishnan, Head, Banking & Insurance Technology Group at Tata Consultancy Services.

    — Anshu Premchand

  • Spring Cleaning 101: Polishing Up Your DevOps Processes

    Spring Cleaning 101: Polishing Up Your DevOps Processes

    Dev teams should take time to tune up agile processes and continue advancing their shift toward DevOps

    Release cycles are accelerating, but not as fast as development teams want. Customers’ desired release rates are moving at an unimpressive pace; those looking to push out new updates on a weekly basis often find it looks more like a monthly basis—and that just isn’t going to cut it.

    As the frequency of execution increases, dev teams find themselves between a rock and a hard place. While the growing demand for faster turnarounds isn’t poised to slow down anytime soon, teams struggle to integrate a set of tools into an efficient pipeline to get the job done within the time allotted. With demand on the rise, how can teams work together to fast-track their release cycles?

    It’s time for dev teams to apply a little more elbow grease.

    With spring cleaning season upon us, dev teams across industries should take time this season to tune up agile processes and continue the work of advancing their shift toward DevOps.

    Dust Off Roles and Responsibilities

    A once very siloed practice, software development has since taken on a much more agile approach across teams as the need for faster release cycles rapidly grows. According to a recent VersionOne report, nearly 75 percent of respondents attribute the need to accelerate software delivery to their adoption of agile practices. While DevOps is meant to help dev teams deliver applications at a high velocity, managers encouraging the implementation of these processes often overlook the true meaning of DevOps and the effects these transformations will have on its current employees and their roles.

    At its very core, DevOps is the combination of development and operations, which covers a wide range of tasks once performed by developers, testers and operations at different stages throughout the software development life cycle (SDLC). However, a more agile approach means these different processes (building, testing, etc.) are in a more tightly coordinated execution, requiring each of the different silos to have a better understanding—and knowledge—of each process.

    Before jumping in to update any processes or technologies, it’s important to ensure all teams are aligned on their evolving roles and responsibilities. Sit down with individuals, teams and their managers to get everyone on the same page and provide guidance on best steps for moving forward this year.

    Shrink the Skills Gap

    Despite developers’ growing list of responsibilities, a 2018 report from LinkedIn found that there is a significant skills shortage when it comes to software engineers and other similar career trajectories. That gap shrinks even further when you consider the different roles within software engineering itself. For example, developers have recently taken on more responsibility as “full stack developers,” assuring high-quality outputs and confirming there are no bugs in their code, yet have very little knowledge of how to implement continuous testing.

    This spring, spend time with employees to brush up on their skills, refine their job responsibilities and uplevel their expertise. While this isn’t a task that can be performed and executed on overnight, some recommendations to kick start the process include:

    • Get leadership on board: To fund any of this, teams will need leadership buy-in. Be sure to sit down with those in senior positions to explain the benefits to teamwide training from both an organizational and economic perspective.
    • Try the buddy system: Pair up programmers of different skills and levels to mentor one another. Consider it as a coaching system in which team members can provide feedback and training in real time with real-world projects.
    • Consider augmenting software delivery practices to improve quality: acceptance test driven development (ATDD) is a proven accelerator and behavior-driven development (BDD) helps bridge varying skills and blind spots between the different personas across the SDLC.

    Pick up New and Improved Processes for Increased Productivity

    As release cycles accelerate, team leads need to take a close look at each of the stages throughout the SDLC to determine where the roadblocks occur and what exactly is holding employees back. Analyzing not only the quality of outputs, but also how quality assurance is embedded throughout continuous integration (CI) process is a good start.

    Throughout the DevOps journey, there are a number of developers across different feature teams adding to, editing, updating and continuously testing code at any given time. Establishing best practices and some basic ground rules can be a simple way to ensure visibility into each of the teams’ productivity. Everyone must constantly be aware of which teams are moving along and which are struggling a bit to make sure code is well-maintained (e.g. determining if your testing code blocking your CI integration) and that there are no memory leaks or poor code development practices throwing the process off. Continuous testing across different feature teams will also assure that every code component for different functionalities is working once they all finally merge.

    Getting everyone on the same page will also make it easier to simplify real-time decision making. Be sure to work with teams to define their dashboards, ensuring everyone is seeing the same actionable results at any given time.

    Revamp Your Tech

    While people and processes should be a main focus for spring cleaning, don’t forget about the tech. The different types of technologies utilized throughout the DevOps pipeline must integrate seamlessly with everything mentioned above.

    First, consider your lab environments. The lab is the glue that keeps the entire CI process together, supporting all platforms (whether mobile, desktop, web, etc.). If unstable or unavailable at any given moment, the entire process breaks.

    As more organizations begin to adopt these agile approaches to software development, it’s also important to remember that it’s nearly impossible to build a “one-size-fits-all” solution; every new process, tool or technology should integrate well within the existing toolchain, which will vary from business to business. For the most success, don’t jump to conclusions and totally overhaul your current stack. Today, there are very few vendors that offer solutions that address every step throughout the development process. Instead, develop new APIs or integration points that make it easier to diversify the set of tools you already have.

    Finally, consider your frameworks. When it comes down to it, there are material differences between the developer’s objectives around tests and the test engineers. Make sure the entire team has tools and access to different frameworks based on their needs. A developer, for example, would use a tool such as Espresso or XCUItest to run a small number of unit tests, whereas test engineers require end-to-end functional test frameworks, such as Appium or Selenium.

    Conclusion

    While it won’t always be easy, it’s important to take some time this spring to get your DevOps teams looking squeaky clean. Don’t forget to focus on polishing up your processes, training team members and sprucing up your stack to ensure release cycles are on time—and spotless—by the time the summer rolls around.

    — Eran Kinsbruner

  • 6 Steps to Take DevOps to the Next Level

    6 Steps to Take DevOps to the Next Level

    Enterprises should be winning at DevOps and reaping the rewards of their digital transformation initiatives. After all, DevOps is not new. Its practices, technologies and processes have been widely accepted for years. Agile techniques, which underpin DevOps, are not new, either. Similarly, digital transformation may have started as a “tech solution” but it is now recognized as a C-suite imperative.

    So why are the majority of business underexploiting their potential? Enterprises stand on the brink of a new era of opportunity heralded by 5G, the IoT and AI. So, how will DevOps rise to the new challenge of increased speed, scale and complexity?

    Time to Worry?

    Test automation levels in organizations speak volumes. Automation is an important marker of DevOps maturity and an indicator of how well a business can compete on quality at speed. So, it is a little worrying that software teams continue to rely on manual processes, with just 16 percent deploying automating common test activities.

    It is often observed that DevOps requires cultural change to really take hold. Motivating and retaining top talent is as important to the health of a DevOps implementation as the latest platform or framework. Yet, it is often passed over in favor of a “quick-fix” in the form of a tech solution. Relatively small adjustments in how teams approach DevOps can make a huge difference, as any practitioner of nudge theory will tell you.

    Here are six top tips to get DevOps delivering again.

    Silo or Service Approach?

    Consider switching to a horizontal software organization, sometimes known as a flat hierarchy, in which people are responsible for end-to-end ownership of the service they are tasked with. It is empowering because it gives them a complete view of what the service should be responsible for. In a vertical organization, the developers tend to become siloed and it can be hard to appreciate the bigger picture.

    Adopt Microservices and Container-based Architectures

    These technical advances have influenced how teams are built and how they operate. Their relative isolation forces teams to be organized independently. With that, comes flexible working and responsibility for the complete life cycle. View microservices and container-based architectures as opportunities for DevOps team members to have more ownership of deployments and results in faster release cycles.

    Publish Matrices for Increased Visibility

    There is a lot to be said for increasing transparency between teams and their members. Foster some healthy competition, share best practices or simply provide criteria for teams to match performance. This can be achieved with automated matrices that show software development and release agility, operational efficiency and quality of service. This kind of transparency is a motivator and will act as a catalyst to improve engineering.

    Automation Leads to Motivation

    Automation is vital for achieving scale and speed, as such, it is rightly seen as a DevOps must-have. It is also valuable because it frees up people’s time from routine activities and manual, repetitive, error-prone tasks. These manual tasks do not just burn precious work hours and reduce quality, they also grind down morale. Give developers interesting things to work on that are strategically important to the organization.

    Immediate Feedback

    In DevOps circles, people obsess about the importance of tightening customer feedback loops. But in an age where social networking is ubiquitous, it is not just customers who want immediate recognition more than delayed gratification. Employees are no different! Provide immediate feedback on code/ build/ test/ deployment /deviations from guidelines as they happen, so that corrective actions can be taken immediately.

    Top-Down Commitment

    DevOps requires C-suite commitment. This is especially true in the early stages of a DevOps implementation. Projects stall for various reasons. For instance, businesses can find it challenging to adapt organizational structures to fit the DevOps way of working. Technical hiccups occur too when technologies are new and its practitioners are learning the ropes. Active, unified support from management helps smooth the path to DevOps, deploying help and resources to ensure the project remains on track.

    DevOps is one part technology, one part process and one part people. It is easy to take it for granted. Too often, businesses prioritize the tech and the processes and forget that what makes DevOps transformational. It is the bringing together of two (formerly) distinct groups, the development and operations teams. A nudge, a pat on the back or a common goal go a long way. These softer skills pack a bigger punch and deliver a better bang for the buck.

    — Naveen Kumar

  • Next-Generation DevOps: Self-Learning Systems

    Next-Generation DevOps: Self-Learning Systems

    The massive enterprise movement toward all things “digital” has accelerated the adoption of DevOps in all kinds of projects, but particularly in digital transformation initiatives. Apart from the productivity benefits gained by automating software development and rollout, the increased agility has helped move DevOps adoption to gain critical mass in a relatively short time.

    However, challenges remain, particularly in ensuring the alignment of the three dimensions of business systems enabled by DevOps—people, process and technology—are coordinated enough to achieve desired outcomes. The “churn” in each of these three dimensions with every software release—particularly given constantly changing technology, constantly evolving operating procedures to support business requirements and end users and the impact the churn has on the “people” dimension—cannot be underestimated.

    To mitigate this churn, it is essential to implement a DevOps “composite system” that manages it methodically and systematically to bring some order to the seemingly chaotic mess of managing multiple moving systems at the same time. The composite system should essentially be able to deliver the following capabilities to address people, process and technology:

    A Visibility Dashboard for all Stakeholders in the DevOps Value Chain

    Visibility and relevance of their work is of prime importance for people to feel connected to a mission. In a typical software development life cycle (SDLC) in an Agile methodology executed through DevOps, there are many stakeholders involved, including business stakeholders, developers, testers, and support services personnel. In an integrated life cycle of constant and continuous software development, testing and rollout, the cycle can seem complex and never-ending. For a successful and motivated team committed to do their best, systems should provide a visibility dashboard customized to each individual based on their role in a project. The dashboard could involve gamification and relative performance visibility of trends at an individual and group/project level.

    The purpose of such a dashboard is not just to improve visibility and individual performance but also bring in alignment and connect each member of a DevOps team with a broader mission of the project/company.

    Event-driven Technology Automation Spurred by API Integration

    The sheer complexity and number of technologies and platforms involved in a DevOps life cycle can be unnerving and intimidating at the same time. Ultimately, the aim of deploying technology to a process is to simplify and create efficient systems. To this end, DevOps technology architecture must be governed by two critical design principles:

    1. An event-driven architecture that enables asynchronous integration of data generated by different tools and technologies involved.
    2. An API-enabled interface at each level of DevOps process flow so that a change in underlying tooling does not (or should not) have an impact on the business.

    Data Driven Self-Learning Systems to Constantly Streamline and Improve Processes

    In systems heavily laden with interconnected tools and technology, a typical DevOps process is heavily automated. However, this is just a “first generation” maturity of DevOps evolution. Just as with the people dimension, where team members are constantly measured, benchmarked and improved, systems and processes need to evolve continuously.

    Because of automation, integrated DevOps systems generate lots of data (systemic/process-related data including build cycle times, testing cycle times and operational data such as issue resolution) that can be harnessed and plowed back in. Next-gen maturity in DevOps is achieved through a data-enabled feedback engine that constantly improves the quality of DevOps processes and their performance. Advanced data analytics and machine learning algorithms can be implemented to monitor, track and improve DevOps performance metrics.

    In summary, to implement next-generation DevOps, organizations need to consider a holistic approach to manage changes at people, technology and process levels. Each of these dimensions require unique needs and a keen understanding of what it takes to make a DevOps system work for all stakeholders involved.

    About the Author / Madhavan Krishnan

    Madhavan Krishnan serves as vice president of Cloud & DevOps solutions at Virtusa. In this role, Madhavan is responsible for competency development, client solutions, and practice team development from Asia and P&L. With more than 17 years of global IT industry experience across multiple technology and business roles, Madhavan’s experience cuts across different dimensions of Virtusa’s IT Services business including global delivery, enterprise architecture, incubating and scaling technology practices with P&L responsibility, and presales and business development. Madhavan is an active participant in various industry and client forums including CII, MAIT and RFID World Asia, and was a member of RFID Integration Consortium in 2005.

  • DevOps Assessment: Assess, Analyze, Implement, Achieve!

    DevOps Assessment: Assess, Analyze, Implement, Achieve!

    DevOps has taken hold in IT. A growing number of organizations are adopting DevOps to deliver applications and services at higher speed; evolve and improve products at a faster pace than in a traditional software development and infrastructure management environment; and better serve their customers. After realizing the benefits of development and operations teams working together instead of in siloed environments, organizations are fast embracing the idea of DevOps.

    To move forward in the DevOps journey, companies first should outline, identify and map the areas where they need improvement. Having a clear idea of maturity of your current IT infrastructure will help you greatly in that process.

    What is a DevOps Assessment?

    Adopting DevOps practices is not a one-day process. And, if it’s not done correctly, companies can do more harm than benefit. So, it is necessary for any organization to know whether the practices they are following are in line with the DevOps initiative. A DevOps assessment is nothing but a set of questions that personnel from different organizational areas can answer. Based on the analysis of the answers, the organization can see whether it is moving in the right direction. DevOps assessment helps outline current maturity and identify a road map of improvement areas.

    Why go for a DevOps Assessment?

    An organization with continuously changing IT and performance needs might be thinking of going for—or may have already started—a DevOps initiative. It’s important to ask the following questions:

    • Do I really need DevOps?
    • Is my infrastructure flexible enough for DevOps?
    • What value is DevOps going to add to my business?
    • Are my DevOps strategies right?

    If yes, then the DevOps assessment is totally built for you.

    What Are the Typical Questions in a DevOps Assessment?

    A  DevOps assessment comprises of three stages: Dev and Test, Release and Deploy, and Manage and Monitor—all of which are part of any product development cycle. The assessment includes questions mostly about production test cases and environment, test cases and test data, the level of automation, complexity, visibility, proficiency in the dev-test-release-deploy-manage processes, etc.

    What Can You Achieve with a DevOps Assessment?

    Once a DevOps assessment has been completed, organizations can get a clear idea of functional areas which are underperforming, performing as expected or overperforming.

    A typical DevOps assessment report provides an evaluation of an organization’s current DevOps ability and recommendations for improvements based on the responses. Not only that, the organization also can get an idea of where it is compared to its competition, the expertise it needs to cement its position, the most valuable talent assets in the organization and the talent pool the organization needs to recruit. A DevOps assessment can help the organization align its software development and IT operations processes with business goals, and ship products faster without compromising with quality and with more reliability because of increased agility and ability to adapt to changes.

    In short, it will help:

    • Technical teams to baseline their performance and understand strengths as well as areas of improvement
    • Recruitment team to develop capabilities and recruit related talent
    • Management team to target the investment areas
    • Operations team to understand the most critical operations

    While DevOps has proven its accelerative impacts on development processes and timelines and quality assurance, it also imposes demands that every organization must be ready to address. DevOps Assessment is a real necessity to get an idea of where you are and where you can be on your DevOps journey.

    About the Author / Chaitanya Jawale

    Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, datacenter automation, DevOps and multi-cloud orchestration and management.

  • Seeking the Balance Between Federalism and States’ Rights

    Seeking the Balance Between Federalism and States’ Rights

    When you overhear someone talking about federalism versus states’ rights, you are bound to think they’re talking about national politics. In the meeting rooms of corporate America, however, it’s often a very different discussion going on.

    For product engineering teams in a medium to large corporate context, many topics and discussions boil down to federalism versus states’ rights wherein federalism relates to the interests of the corporate parent and the states in question are the business units or individual product teams. The representatives from each of these bodies often have distinct agendas and priorities which sometimes compete with each other and all too often leave employees and executives alike flummoxed and resigned to pain.

    The Federalist Perspective

    The people who are charged with driving unification and standardization may indeed use their process and policies as sword and shield, but this doesn’t mean they don’t have a well-reasoned position that drives them. Almost every employee is familiar with the drive to create revenue. Not nearly as many are familiar with the charge of “driving the spread.”

    A business could be viewed as healthy when revenue grows at a rate that exceeds the cost of capital (i.e., “investment in the business beats investment in the market”). Better yet, a business can be viewed as sustainably healthy when revenue grows at a rate that exceeds the cost of capital AND operational expense grows at a smaller rate. This is what is known as increasing “the spread.”

    When the spread grows year over year, it means the business is succeeding at increasing both effectiveness and efficiency at the same time (i.e., “doing the right things right”). In most cases that don’t have explosive market growth, driving the separation between revenue growth trend lines and operational expense growth trend lines is one of, if not the best, metrics for the sustainable health of an enterprise, because the increasing spread acts as a lever to fend off disruption and competition by raising barriers to entry or funding acquisition of potential disruptors.

    If your job within the company is to increase the spread for the entire enterprise, the best tools at your disposal are to drive standardization and consolidation in all things by default. In this context, “all things” really does mean “all things.” It includes—but is not limited to—tech stacks, support levels and processes, operating procedures, job descriptions, programming languages and frameworks, employee policies, employee tools, business process systems and core capabilities.

    This drive for rationalization often will come into conflict at the business unit because individuals at all levels within the business unit will many times be asked to drive change that could sacrifice the performance metrics and commitments that are measured at the business unit level.

    In the eyes of the federalist, sacrificing pennies for the sake of dollars is almost—if not—always the right thing to do for the enterprise.

    The States’ Rights Perspective

    The people who are charged with driving business unit performance may indeed voice their displeasure at corporate direction with an attitude that displays a lack of professionalism and respect, but this doesn’t mean they aren’t fighting for a just cause. Supporting the whole at the expense of piece is something that most people can understand. Not everybody, however, can see the cost that comes when unification erodes peoples’ sense of self-determination.

    Individuals and individual business units alike are extrinsically driven and rewarded by achievement of individualistic goals and commitments. Many of these same individuals are intrinsically driven by a sense of autonomy, mastery and purpose. Autonomy at its basic level is well-understood.

    When new directives for unification or standardization are rolled out, this introduces both direct and indirect cost at the business unit level. These costs aren’t always funded to the extent necessary to drive the required rationalization. Even in the case of reasonable funding, relief from existing commitments isn’t usually factored into corporate directives.

    Funding and wholistic concerns aside, what can be the hardest dynamic to work through is directed idleness while fully aligned decisions are being generated. From the practitioner perspective, this dynamic can be perceived as contemptuous because it simultaneously says, “Your concerns are not sufficient to warrant our attention,” and “Don’t take any action to address your concerns because that will warrant our attention.” In the most extreme cases, this is coupled with an unyielding expectation to meet or exceed performance goals.

    This approach breeds a combination of labor attrition, forced helplessness and a jaded attitude within teams that can take years to unwind and change.

    The Balanced Perspective

    Splitting the middle can be difficult in emotionally laden high-stakes areas. Add distrust and a high degree of power separation, and the degree of difficulty gets intense for this effort. Let’s start from the top because the onus is on leaders to go first when an impasse arises:

    Where federalists can give in efforts to support self determination:

    • Even the most ardent federalists agree that autonomy is the only path to achieve scale in a modern corporation. Central bodies of authority can go out of their way to demonstrate their commitment to this by endorsing explicit role-specific areas where experimentation and innovation is needed (i.e., a message of, “Don’t advance here just yet,” goes down easier if it’s coupled with a list of topic areas that have few or no guard rails).
    • Assuming current commitments are not in jeopardy, acknowledge that work done in excess of current commitments is a contribution and not a distraction, even if it has the localized possibility of deviating from to-be-set standards (i.e., a message of, “Don’t spend time on improving area x,” goes down a lot easier if it’s coupled with an acknowledgment that, “If a person is willing to dedicate their own personal time, that does not come at the expense of the company. We value that level of commitment”).
    • Find ways to recognize and reward individuals and teams for avoiding local optimization at the expense of the whole to compensate for locally defined goals and compensation systems.

    Where states’ rights activists can give in an effort to support a broader set of goals:

    • Even the most ardent localists acknowledge the pricicipal within a hierarchy of goals (enterprise goals > unit goals > team goals > personal goals). Local leaders and practitioners can go out of their way to demonstrate their faith in leadership by going the extra mile to find and generate goal alignment that drives benefits to more than one organizational unit (i.e., a stance of, “We’ve prioritized local remediation in this one area because it helps our business unit meet some secondary objectives,” invites less opposition if it’s demonstrably linked to the broader set of enterprise goals.
    • Assuming room for innovation and continuous improvement is met with tolerance, local leaders and practitioners can make themselves beyond reproach by ensuring goal priorities have been kept in mind and also focusing improvements that have limited to no impact outside of their local responsibility (i.e., a local development push to a microservice architecture can have deep impacts to a centralized operations unit without a diligent effort to manufacture a mature operational capability).
    • Find ways to drive local improvement communications up to broader system owners in an effort to facilitate collaboration and longer-term planning (i.e., a message of, “Business unit x has developed a new solution for y,” raises a lot less concern when it’s paired with a statement of, “… and the teams acted responsibly by collaborating with the enterprise team responsible for keeping our long-term efforts here aligned with a consensus road map.”

    When deference and forbearance meet, graceful and elegant solutions emerge and ultimately harmony is preserved. If only more people understood that the adversarial noise in between us is more harmful than either minor deviance, or momentary ambiguity.

    — Stephen Fishman