Imagine driving down the highway and seeming to get a traffic jam at a distance. You realize your car is equipped with GPS to have clear visibility into what’s next and can show exact directions for alternative routes and estimated travel time. It is very easy to pick the fastest and most favorable route to reach your destination by looking ahead proactively and having the set of right tools for collecting information.
The combination of Dev and Ops teams that are working together to build a faster and more reliable released pipeline is defined as DevOps. Similar to GPS, Jira Software acts as a singular source of truth for information development across your DevOps workflow.
Complete traceability and visibility of work across different teams can get you surface information and data from an integrated toolchain to the right people anytime. No matter if you’re a team lead, release manager or a tester, the workflow visibility can ensure everyone by letting them know what’s in development and what’s being supported.
In the latest release of Jira Software version 7.9, there is support added for the dev cycle to show development data from Bamboo, Bitbucket and GitHub in Jira Software search from your DevOps practice. It makes it a lot easier to identify development issues by making informed decisions and faster shipping with software development services.
Get Answers to Development Questions via Basic Searches
A new column called Development is added to the default view of Jira’s Issue Navigator in the latest release of Jira Software Server (v7.9). It allows viewing specified information pulled out from Bitbucket Server without clicking into the individual issue. Instead of limiting yourself to the single-issue information, you can see a high-level snapshot of issues coupled together by filtration, to help surface larger trends or problems.
If this gets stopped at their source, does it really need to move the needle for improving your dev process within DevOps? For instance, if you wish to know how many issues under development, are they in the review?
If you ever find that one or two developers are getting loaded down with the bulk of pull requests, you can immediately access if redistribution of work is required or not.
Filter Out Your Development Information Using JQL
What happens if you need to answer too many complex or open-ended questions? This can become monotonous after a time. You can use Jira Query Language (JQL) to create search queries that are based on development information to uncover key information for avoiding all pending problems.
The latest version of Jira Software Server comes updated with the syntax to align the JQL query formatting. The users of Jira Software power use JQL for a long time to look at a subset of issues for driving reports and focus on Scrum and Kanban boards. With the help of cross-reference data from developer tools, Jira Query Language seems to be more powerful now.
Examples of Jira Query Language in Action
The teams who practice DevOps need critical internal and customer feedback, which helps them to inform features by making them higher quality and more valuable to the end user. Hence, focusing on feedback often creates tension when you decide if the first version is ready to deploy.
You may ask: What number of issues are done but have not been deployed?
From this question, you can determine whether the feature is ready to be released and starts collecting feedback or is blocking any issues that need to get resolved prior to release.
Often, the team’s test builds locally before jumping off to deployment. If the same is the case for your team, then it is a good practice to regularly check the status of the builds.
You may ask: What number of issues are failing builds?
If you figure out a lot of failing builds, it may be a signal that the developer environments do not match the deployment. Generally, this is a problem you want to catch and fix right away, so conversely, the set of issues can be the areas where the testers can check acceptance criteria and begin exploratory testing.
Boost Up Your Search
You need to surface the information when and where it is needed as most of the teams get the most out of DevOps by bringing development, QA, high-quality releases, more-informed decisions and happy customers. Keep learning!
xMatters Flow Designer is a drag-and-drop graphical tool that either developers or IT operation teams can employ to create incident management workflows on top of xMatters incident management software. Doug Peete, chief product officer of xMatters, said those workflows feed data into a variety of third-party IT management tools to enable IT operations and DevOps teams to consume the same data in different tools—for example, in an instance of ServiceNow for IT operations and as a message in Jira or Slack for DevOps teams.
Peete said the goal is to enable organizations to develop a more consistent approach to incident management. A recent survey of more than 1,000 IT professionals conducted by xMatters and Atlassian found that while 81 percent of developers and operation teams share information and tools, only 17 percent provide open access to information without time restrictions. The survey also found that 50 percent of respondents said the tools, processes and steps they employ vary from incident to incident.
Most of those organizations have very little in the way tools that enable them to effectively conduct a post-mortem analysis of those incidents, added Peete.
The arrival of the xMatters Flow Designer tool comes at a time when organizations are trying to find ways to meld the highly structured ITIL processes that most IT organizations rely on today and the inherently more agile approaches based on best DevOps practices. The most recent iteration of the ITIL framework incorporates some DevOps principles, but it’s apparent the two approaches to managing IT will be employed side by side in many organizations for many years to come. Developers these days tend to prefer DevOps methodologies, while IT administrators tend to appreciate the consistency of an ITIL framework that was designed to address IT governance concerns. By providing a set of workflow tools that span both those approaches, Peete said IT organizations can more easily meld those two approaches on their own terms.
At the same time, an extensible approach to incident management makes it possible for IT organizations to incorporate new tools into those workflows as their IT environment evolves. That capability also should make it easier to integrate incident management workflows across multiple organizations as well as incorporate a new IT environment as a result of acquiring another company.
Regardless of the path chosen, it’s clear that as organizations increasingly realize how dependent their business processes are on software in the age of digital business transformation, the more likely it is they will embrace DevOps practices. However, that doesn’t mean organizations need to abandon ITIL; there are plenty of IT processes that benefit from a highly structured approach. In fact, arguably the most important thing is to not let a philosophical debate over the merits of DevOps versus ITIL wind up becoming a major distraction that creates two isolated cultures who refuse to collaborate with one another.
Sauce Labs announced it is now moving beyond functional testing, adding a front-end testing tool it has dubbed Sauce Performance to make it easier to accelerate testing within the context of a DevOps process.
Lubos Parobek, vice president of products for Sauce Labs, said the goal is to enable developers or testers to begin testing both how well application functions work and perform much earlier in the DevOps process using the same testing tool.
Parobek said that as organizations embrace modern application development architectures based on microservices, it’s become crucial to test the capabilities of any module within an application because the number of interdependencies between modules continues to increase. That approach accelerates the rate at which applications can be developed. However, any flaw that impacts how the application works or performs can have a debilitating impact on any number of microservices that make up the application, he noted.
Sauce Performance makes use of debugging and performance trace logs to identify the root cause of an issue in addition to capturing metrics such as Time to First Meaningful Paint, Time to First Interactive, Page Weight and Speed Index. Sauce Performance also employs algorithms to automatically establish a baseline that can be used for regression testing.
Parobek said Sauce Performance serves to streamline testing processes as well. Most existing front-end performance testing solutions require integration with a load/stress testing tool or a separate application performance monitoring (APM) tool. However, Sauce Performance allows developers to use their existing Selenium test scripts to capture both functional and performance test data.
In addition, Sauce Performance has been designed to integrate with multiple continuous integration/continuous deployment (CI/CD) platforms to make it possible to feed test results directly back to developers, which can then decide to prioritize issues that need to be addressed.
Sauce Performance is available as part of the Sauce Labs Continuous Testing Cloud.
Parobek said organizations want to be able to make it easier for developers to test their own code as part of their DevOps best practices. That doesn’t eliminate the need for dedicated testers for evaluating functions, but potential performance issues today are being addressed often long before applications are deployed in a production environment.
One of the reasons applications are not as thoroughly tested as they might be is that many organizations require developers to learn how to use tools that have different user interfaces and then switch between testing tools. The result is a complex testing process that makes it more tempting to short-shrift elements of the testing process as application delivery deadlines loom.
More challenging still, many organizations still don’t continuously test applications after they are deployed to ensure new functionality does not adversely impact the user experience.
For as long as applications have been built, tension has existed between the developers who create applications and the people who test them. That debate may never be resolved, but everyone agrees in this age of DevOps that it’s better to test early and often.
Organizations are embracing product experimentation as a tool for continuous improvement
Companies that embrace product experimentation are able to capture highly accurate data about markets and product ideas and gain intelligence about market trends. As a result, these companies are able to continuously deliver innovation and measure business outcomes.
Industry leaders such as Netflix, Instagram and Facebook have used product experimentation to maximize a positive customer experience, increase their user base and elevate their market positions to the highest of levels.
Let’s say you want to be one of those companies—or at least you and, hopefully, your team, want to experiment with product features in hopes that your company will embrace experimentation on a larger scale to achieve continuous improvement.
Great. But now what?
Just thinking about learning the basic concepts of experimentation and figuring out where to start can seem like an overwhelmingly daunting task. Fortunately, there are a few tried and true steps you can take to get on the path to product experimentation for continuous improvement.
Measure First
“You have to walk before you can run.” That old adage certainly applies here. Rather than attempting to jump headfirst into experimentation, organizations first must ensure they are measuring things. Are you tracking things such as users per day, trends, dates and conversions? The idea here is to become data driven, because before an organization can run effective experiments, it first must gather quantifiable data; understand what this data means for overall growth, user retention and long-term projection; and then base business decisions on this data.
Buy or Build
No matter the size and scope of the experimentation throughout the organization, even if it is just one team or department, you need a platform or tool to experiment on. Many of the most progressive organizations that have based their growth and continuous improvement on experimentation have built in-house solutions to facilitate this. However, this can be time-consuming from the start and the platform will continue to require attention as it evolves. This evolution also requires a specific skill set to make it happen—specifically, data science and engineering—to ensure the experimentation platform is statistically sound.
For most, investing in a robust tool or platform built specifically for experimentation is the best option. Most experimentation platforms allow you to plug and play, which provides the right features and capabilities to get an experimentation started quickly.
Hypothesize
The next step is to create a testable hypothesis and then record and analyze the data during testing. It’s important to begin thinking in terms of hypotheses, as framing plans and ideas in this manner makes them easier to reuse. In other words, being able to say, “Based on this, we predict we can move that metric,” makes your processes very repeatable. Getting into this mindset and having a standardized format—in terms of how things are designed and reported on—makes the lives of everyone on your team easier, as they can simply replicate similar experiment designs. And they will have fewer excuses not to.
Keep It Simple
Now that you have quantifiable data and some hypotheses to work with, you are ready to dip a toe into the experimentation pool. It is always a good idea to start with a single simple experiment first, no matter how small. For example, experimenting on a known pain point in your product is a nice place to start. Once you can successfully run an experiment that allows you to fix something in your product that you know is a problem, then you are ready to move on to bigger things such as revenue creation.
Choose the Right Metrics
As your team’s product experimentation efforts become more sophisticated, choosing the right metrics—and more importantly, your overall evaluation criteria (OEC)—should become a top priority in continuous improvement. Your OEC comprises the most important metrics of your experiment and it’s a measure of long-term business value or user satisfaction.
In choosing which metrics to use, there are three essential characteristics of an effective OEC to consider.
The first of these is sensitivity. This means the metrics you have chosen should be adjustable due to small changes in business value or user satisfaction, which helps ensure the result of an experiment is clear within a reasonable time period. For example, let’s say a customer only buys something from your website once or twice year. That’s not a very useful metric for an experiment since it would be difficult to influence.
Next is directionality. Your metrics should be moving in one direction or another based on whether your overall business value increases or decreases. That said, the direction some metrics take can be ambiguous. For instance, say you are attempting to measure customers’ engagement with your support team. An increase in that metric could be a positive thing because it might be an indication that more people are engaging with your core product. On the other hand, a decrease in this metric could be an indication that your core product has become easier to use and therefore now requires less support.
The third characteristic to consider is understandability, meaning the metric should be easily understood, both in terms of its direction and its definition, by your entire organization. Moreover, you should ensure it ties the experiment directly to business value.
Of course, much more will need to be done to transform your organization into a place that truly embraces an experimentation culture and reaps the benefits that it brings in terms of customer experience and beyond. But these steps should set you and your team down the right path.
In an ideal world, implementing DevOps practices and Agile methodologies would be the key building blocks organizations need to realize rapid, high-quality releases.
The ability to iterate on a product with a high volume, velocity and level of quality is the ultimate goal of the modern enterprise; every CEO wants a faster time to market. But keeping business practices agile is much easier said than done. The term “agile” is broad. While The Agile Manifesto does a good job of defining the concept, there are myriad technical and non-technical aspects to the idea. At the end of the day, simply saying you are “agile” isn’t some silver bullet that delivers faster cycle times, a better product and more satisfied users.
Instead, success with Agile methodologies means thinking more critically about how they are deployed and if your current DevOps practices are strong enough to support that strategy.
What is Agility, Really?
In practice, agility is a complex combination of things, perhaps best understood by what it’s not. Being agile with a product is not simply thinking about how fast you can complete a collection of features. Yes, it’s great when the backlog becomes smaller, faster. But Agile, when applied correctly, is really about having a true understanding of the user’s business problem and a real idea of their envisioned, desired outcome—and what it might take to achieve that outcome.
This requires a shift in thinking when it comes to the product backlog. Too often, backlogs are viewed vertically, meaning features are built that may not have independent value. As a result, release efforts grow in development effort and elapsed time, limiting the ability to quickly release in small, incremental stages. As an example, consider search functionality as a feature set. On its own, search isn’t necessarily an independently valuable feature. What are users searching for? Why do they need this information and what are they doing with the results? A vertical view of agility fails to ask these questions and focuses only on the myopic feature set at hand. Consequently, even the most mature Agile practices are limited in what they can accomplish. Who really cares if you can get a feature out of the backlog quickly if it doesn’t matter to users?
Agile thinking should instead be applied horizontally; the user’s journey is the center of everything. What do they need to accomplish? What are they unable to do now and how quickly can we give them that ability? In the search example, this means thinking beyond simply building a search function and instead developing a new product release that eases a specific pain point of users. Quick and iterative changes based on direct user feedback is the goal.
So Where Does DevOps Come In?
Agile is hardly a foreign concept for software engineers—86 percent use an Agile methodology (such as scrum) day to day. But the tools, processes and practices of DevOps need to be honed constantly to support iterative development, testing and release of code.
As with the development of any product, software developers have much to gain from building and testing functionality in small, iterative releases. Smaller tests allow for more intensive studies of accuracy and problem-solving before allowing an entire organization to rely on a solution. While these pilots may not be fully rolled out, the teams involved must be integrated to include voices from a variety of stakeholders, including but not limited to:
Architecture
Experience design
Development
Security
Quality assurance
Operations
Teams must also keep these DevOps best practices front-of-mind when developing a software solution:
Employ microservices. A solution built from these separately deployable services that perform specific business functions is much easier to scale out or expand. Microservices also remove single points of failure (SPOFs) by preventing issues in one area of an application from affecting others.
Blend continuous integration (CI) and continuous delivery (CD). These two DevOps strategies support each other in much the same way as integrated human teams that consider stakeholder needs. While CI automates the build and testing processes, CD automates the deployment cycle from development to production. The automation behind both results in a vastly increased deployment frequency.
Use infrastructure-as-code. Modern cloud platforms allow for infrastructure to be software-defined. This allows DevOps practitioners to bring best practices from the field of software engineering to bear against systems challenges. Think about the new features AWS announced for CloudFormation this year, for example: configuration drift detection, dynamic references, macros (functions with iteration support) and linters. All of these are in support of treating infrastructure orchestration as a software engineering activity, allowing DevOps teams to use one common set of tools and practices.
Refine observability. As architecture becomes ever more complex, the practices of monitoring and logging are evolving. No longer can you independently monitor the uptime of a server and simply log OS and app issues. Application performance management (APM) becomes paramount, measuring aspects of the user experience as they flow through the app, as does identifying and publishing relevant business metrics. The distributed nature of microservices and the various cloud services enabling them, demand new tooling to measure potential bottlenecks in the form of distributed tracing. And the DevOps best practice of “hands-off production” (e.g. no shell or attachment access) means you’ll need to provide real-time visibility into the health and inner workings of your application via log shipping, adding your centralized logging solution into the critical path of application troubleshooting.
Focus on communication. This is perhaps the most beneficial point for your team and should not be overlooked. The cross-functional, collaborative teams supported by both Agile and DevOps culture break down traditional silos and unite members around a common goal. Formal structures around these teams should start early and continue through retrospectives to assess and celebrate everything you’ve accomplished in a short time. You’re not working in a vacuum, and this project isn’t the only one your team will ever produce. Keeping careful records of successes, failures and areas for improvement will only make your work more efficient and Agile in the future.
Agile is the perfect process for the modern tech landscape—releasing quickly in small bites that are then perfected based on customer feedback. In living up to that ideal, teams who turn to Agile in managing their projects shouldn’t take a set-it-and-forget-it approach to their processes. Instead, bolstered by DevOps tools, culture and practices, they should embrace the ongoing refinement and reflection required to support both customer needs and business goals.
A part of that effort, Chef also launched the Chef Enterprise Automation Stack—which combines Chef Infra for managing infrastructure, Chef InSpec for maintaining compliance, Chef Habitat for managing applications, Chef Automate for managing hybrid clouds and Chef Workstation, a starter kit for launching Chef—within a single distribution of Chef software. Chef Infra is the original Chef project around which the company was launched.
Corey Scobie, senior vice president of product and engineering for Chef, said the company previously offered a mix of open source and proprietary software that made engaging with some customers overly complex from a licensing perspective. This approach aligns the entire Chef business model around providing support for open source software, he said.
At the same time, Chef is now open to collaborating more closely with developers who want to contribute code to its various projects. That’s critical because code contributions are now the primary means through which many IT organizations help shape the direction of products as they continue to evolve, Scobie noted.
Of course, many IT organizations today either mandate the use of open source software or have instituted an “open source first” policy that makes it challenging for any proprietary software to be adopted.
Chef expects that by making its software easier to consume via a unified open source transition it will be able to further accelerate adoption of what is described as a “Coded Enterprise” to managing IT. Rather than manually configuring IT assets in isolation, that approach encourages organizations to adopt best DevOps practices that treat all aspects of IT, including infrastructure, as code, said Scobie, adding that capability is more important than ever as IT organizations are increasingly require to manage heterogenous cloud computing environments.
Chef claims that approach has already resulted in more than half of the Fortune 500 having adopted at least one module of its software and, in the fourth quarter of 2018, the highest level of bookings in the company’s history.
While Chef helped pioneer the IT automation category, competition across this sector has intensified. Chef and its primary rivals Puppet and Red Hat are the leading proponents of frameworks for automating IT operations. Although adoption of those frameworks has increased substantially in recent years, use within IT organizations often remains fragmented, often resulting in islands of automation. Chef is clearly hoping that IT organizations will increase adoption of its software stack now that it’s based entirely on open source software. Many organizations face challenges teaching their IT operations teams enough programming skills to automate their processes. In absence of those skills, adoption of IT automation frameworks within the context of a set of well-defined DevOps best practices often remains uneven, at best.
Compuware has updated its Topaz for Total Test suite to enable organizations applying best DevOps practices to the development of mainframe applications to combine unit, functional, integration and regression testing within a single test scenario.
In addition, Compuware is making it easier to test multiple applications simultaneously. The latest update to Topaz for Total Test adds the ability to not only orchestrate a sequence of steps, but also design tests to measure how programs interact with each other and various data sets.
Also added is the ability to automate several testing functions, including the ability to launch functional tests within a browser and execute unit, functional and integration tests without having to manually create their own Job Control Language (JCL). According to Compuware, testers now can design test cases upfront based on program specifications before developing a program. What’s more, Topaz for Total Test has been integrated with the DevOps pipeline management platform developed by XebiaLabs.
Finally, Compuware announced that the Topaz 3270 Emulator now makes it possible complete one-off “green screen” tasks without leaving Topaz. Initiating a CICS transaction or accessing REXX utilities through the Emulator within Topaz, for example, makes it simple for developers to quickly resume Eclipse-based tasks without having to exit its testing environment or toggle between tools.
Compuware CEO Chris O’Malley said the pace at which IT teams in mainframe environments have been adopting DevOps practices has accelerated considerably in the past year. Not only are applications being developed and deployed faster, the quality of those applications has increased because DevOps tools provided by Compuware make it easier to both visualize a complex application development process and then test those applications as they are being developed. Given the often mission-critical nature of mainframe applications, it’s crucial that any increase in development velocity doesn’t have a negative impact on application quality, he noted.
DevOps has become a greater imperative in mainframe environments, O’Malley added, as organizations look to leverage investments in existing mainframe applications rather than try replicating functionality that already exists on a mainframe in a distributed computing environment. That approach helps to reduce sharply the amount of technical debt an organization needs to service when they duplicate functionality across two or more platforms. Mainframe teams that historically have relied on waterfall developments process have been challenged by keeping pace with the rate of change. As applications that are deployed on a distributed system look to invoke a mainframe application function, organizations that have deployed those applications need to keep pace with a much faster rate of development, especially when it comes to application programing interfaces (APIs).
It may take a while longer for DevOps practices on mainframes to become adopted widely. But as the rate of innovation continues to increase, thanks to the rise of various digital business transformation initiatives, it’s apparent that mainframe application development will need to become more agile. The challenge at this point is not so much the availability of DevOps tools for the mainframe, but rather training the teams that build and deploy those applications on when and how to implement DevOps practices.
I attended Adobe Summit 2019 to research the intersection of DevOps and marketing. Below are insights from my interviews with leading marketing technology experts.
Is DevOps making its way into marketing? In a short answer, a soft “Yes.”
I recently attended the Adobe Summit, held March 26-28 in Las Vegas. This year emphasized digital customer experiences, and I was curious to take a peek into this world of marketing tech to see if DevOps was having any impact.
Many of the people I talked to described how marketing technology is adopting a more agile, DevOps-inspired mindset. But is marketing actually driving product change? While Adobe and proponents would like to have us think so, some are not as sure.
At Adobe Summit, I had some eye-opening meetings with professionals invested in digital marketing, retail and analytics services, most of which are using Adobe products in some form. In this article, we’ll highlight what they had to say on the intersection of DevOps and marketing.
What is the Role of DevOps in Marketing?
The need to break down data silos was a common theme among keynotes, sessions and throughout my meetings at Adobe Summit.
When large digital marketing agencies take on clients, for example, a common disability they find is a disparate and dysfunctional customer data storage system. In our meeting, Alex Kelleher, managing director at Deloitte Digital, noted, “Data needs to be available, and integratable. That is the first thing we typically fix for our clients—we’ll fix the data in silos, get it in the same place, and usually simplify it.”
Deloitte Digital’s process involves three D’s: first, they consolidate data silos, then build data-driven decisions, then deliver agile products. In doing so, Kelleher is seeing more and more developer practices making their way into marketing and sales.
“We’re seeing CMOs manage their teams as agile teams, recruiting agile and scrum masters,” he said. “That’s very cool for CMOs to be involved in … those worlds colliding is super exciting.”
Is DevOps Eroding Traditional Boundaries?
DevOps principles encourage shared knowledge and open communication between teams. Now, it appears such ideas are affecting how marketing technologists architect their teams and delivery cycles.
Rachel Lane, solution principal customer experience at Medallia, sees a trifecta of forces working in tandem. “Development, Ops, and Marketing must work together,” she said. “If one of those doesn’t link up, then we see extended lead time to launch, and it can become problematic.”
Medallia’s goal is to meet customers where they are to gather actionable feedback through push notifications, surveys, embeddable surveys, Net Promoter Score (NPS) systems and other means. Engrossed in this world of customer feedback, Lane reminded us: “You should never ask a question that you already know the answer to.”
Unfortunately, this still happens often. User data is often locked in silos and if multiple teams (sales, marketing, support engineers, etc.) are using separate user data repositories, customer interaction can suffer. Thus, user conversation data must be de-siloed and unified.
For Lane, having tight customer experience-driven feedback is critical for reiterating the overall product. However, customers typically hate filling out surveys. To decrease friction, she foresees more passive voice-driven feedback through home AIs.
Rearchitecting the Digital Footprint for Agility
By now it’s evident that unclear data initiatives and messy data storage can hinder digital transformation. So, what are organizations doing to de-silo and open up data?
Anheuser-Busch (AB) is a huge beer corporation, overseeing brands including Budweiser, Busch, Elysian and many others. Each has unique online eCommerce storefronts to sell ancillary swag, such as T-shirts, drinkware and other products.
With public-facing sites for hundreds of brands, maintaining data standardization across its product lists was a nightmare. Disparate data structures can also inhibit directing change from within, slowing corporate-led growth.
John Faviano, director of demand and integrated marketing technology at Anheuser-Busch, described how AB solved the issue by creating a consistent data structure from which all online stores can pull content from.
“We’ve standardized the tech stack in the last three years to enable the business to run more efficient … You have to think from a platform perspective, not a single siloed technology,” he said.
AB’s web APIs now grant incredible scalability, as the content is now delivered agnostic of client or brand. AB brands retain independent facades yet are fueled by a unified content storage and delivery process. “Our API strategy is a build-once-and-scale mechanism,” Faviano said.
Digitization with IoT and AI
Sreedhar Bhagavatheeswaran, SVP and global head of digital business at Mindtree, believes that every part of the enterprise needs to be digitized. He sees a wealth of untapped data that enterprises can leverage to transform user experiences.
Having built digital presences for big-name consumer brands including Marriott, P&G and Kellogg’s, Mindtree understands the advantages of using a DevOps approach for software cycles. Though it may require a cultural change, “The probability of project success in a DevOps environment is much higher than in a non-DevOps environment,” Bhagavatheeswaran said.
Release automation is integral to Mindtree’s process. Coding checks and CI tools such as Jenkins bring quick releases, enabling business teams and clients to see the impact on a daily basis. They also privilege API-fueled microservices designs for increased agility.
“From an agile program management perspective it gets challenging, but that is the nature of the beast,” he noted.
Bhagavatheeswaran is excited for the potential IoT has to evolve industrial, business and consumer-facing touchpoints. For example, industrial engineers could conduct remote servicing using digital twins of real physical equipment. He also described developing mobile IoT apps for his clients: Push notifications triggered by removing caps from makeup bottles, for example, could empower consumers with advice on how to apply makeup correctly.
To sum it up, Bhagavatheeswaran described our current paradigm with a simple, powerful sentiment: “The experience is at the confluence of edge, humanity and intelligence.”
Approaching the Developer Experience
But digital transformation doesn’t stop with open data, APIs and IoT. Developer experience (DX) has become an important factor in maturing countless digital services.
Jason Woosley, VP of commerce product and platform at Adobe, founded the Adobe-acquired Magento, which began as an open source project on GitHub, welcoming pull requests to alter product features (with the proper vetting in place, of course).
By investing in open source and developer communities, Magento over time reached a critical mass, democratizing how developers build online storefronts.
Woosley estimated that 50 percent of Magento code was built by third-party developers. One such feature is multi-source inventory, which, he said, accounts for 70 percent of the Magento code base. Naturally, he has a deep appreciation for the power of developer communities.
“You can’t buy a developer community. You can’t steer or create a culture,” Woosley said. “Code custodians are actually participants, and to deserve that role DX needs to be delightful and empowered.”
To improve the developer experience, Magento has hosted countless events, increased developer support staff, annotated its APIs, adopted GraphQL for extensibility, invested in optimizing developer portals and more. With the inclusion of Magento in Adobe Experience Cloud, more capital is available to further DX enhancements—something Woosley is excited about.
Wednesday March 27, 2019 in Las Vegas. (Jeff Bottari/AP Images for Adobe)
DevOps is Kicking Martech to Innovate
Deloitte Digital’s Kelleher noted that “nowadays, your competitors are any digitally active application,” regardless of whether they’re even in the same industry.
This means that a consumer will judge a mobile digital experience with an airline with the same scrutiny as calling an Uber or making a PayPal transfer. Users hold the same lofty digital expectations from any business, forcing us all to adapt dramatically.
Fueled by the relentless pressure from users, marketing technologies are adopting DevOps principles to improve their offerings in a few ways:
Continuous releases: Martech uses DevOps strategies to release quickly. User-facing mobile app release cycles, for example, routinely adopt CI/CD.
De-siloing: User data and consumer conversation information are being distributed with greater alacrity across enterprises, improving end UX.
Open data initiatives: With web APIs, new platform-agnostic content distribution architectures have emerged. Development procedures are standardized across an enterprise, quickening the release cycle.
Cloud architecture: By adopting cloud-based management tools, martech is improving the asset management condition of supporting many user-facing touchpoints.
Developer experience: By embracing open source and supporting developer community, leading e-commerce groups are improving their offerings.
While marketing is critical to the whole, it may not be the No. 1 business driver. When I asked Bhagavatheeswaran whether marketing was really driving the creation of new tools, he responded: “Is marketing driving the tools? Are they influencing? Not quite yet. However, it has the ability to influence the developer’s quality. Probably not their job.”
Even if marketing is not directly influencing product development, we’re still seeing DevOps seep into traditionally non-technical environments, which is exciting.
It was eye-opening to enter the world of marketing technology to see firsthand how these institutions—such as Ansira, a 100-year-old company—are using agile means to streamline digital transformation initiatives.
With an emphasis on both creating and managing quality digital customer experiences, Adobe Summit 2019 shed light on many unique strategies being undertaken in the realm of martech.
Whether it’s leading the development of user-facing apps, overseeing expansive brand catalogs, using a cloud-based single source of truth for content management or building developer communities to reap huge R&D benefits, the intersection of marketing and technology has never required more strategic action than it does now.
At the Adobe Summit 2019 conference this week, Adobe detailed that its Adobe Experience Cloud customer experience ecosystem is reliant on a set of best DevOps processes that is wrapped around a modern microservices architecture and layered on top of big data platform deployed on the Azure cloud.
Adobe last year acquired Magento, provider of an e-commerce platform, and Marketo, provider of a marketing automation platform. Since then, Adobe has been working to integrate those offerings with its existing marketing application to create the Adobe Experience Cloud.
Anjul Bhambhri, vice president of platform engineering for Adobe, said this set of software-as-a-service (SaaS) applications are being integrated around a shared common data model that is layered on a microservices-based architecture of containers running on Kubernetes clusters. On top of that, Adobe is layering a series of machine learning algorithms, dubbed Sensei, to embed artificial intelligence (AI) across the entire portfolio, he said.
As that work progresses, Adobe plans to allow customers and partners to leverage the data stored in the Adobe Experience Cloud to train their own AI models using data curated by Adobe, Bhambhri noted. That data model, known as the Experience Data Model (XDM), is also being shared with partners including Microsoft and SAP, which last year committed to an ambitious initiative to build a common data model in collaboration with Adobe. XDM makes use of open source Kafka messaging software to integrate the various data pipelines that are required to integrate these applications at scale in near real-time, Bhambhri said.
Those efforts complement an existing initiative under which Adobe is exposing open application programming interfaces (APIs) to encourage developers to build applications that extend Adobe Experience Cloud.
Rather than building their own customer data platforms, organizations can drive their digital business initiatives using a big data platform managed by Adobe on their behalf. Many organizations have been building their own platforms to achieve that goal with mixed success, first deploying a data warehouse on top of a big data platform and then working to integrate various applications to provide a richer digital customer experience. Bhambri noted Adobe is pouring considerable resources to obviate the need for organizations to acquire, deploy and manage their own IT infrastructure to achieve that goal.
IT leaders must decide whether they want to reduce the time, money and effort required to build these custom platforms in favor of using a managed service from Adobe—which, arguably, would enable them to pour more resources into developing applications that, as a result, would come to market faster.
In the meantime, it’s clear the need to embrace digital business transformation will drive more organizations to embrace DevOps processes. The question now is to what degree they need to define their own set of best DevOps processes versus simply lifting the DevOps best practices that organizations such as Adobe have already proven.
Robot overlords are the stuff of science fiction fantasy. Today, with more teams implementing artificial intelligence (AI), DevOps teams need a hard, continuous look at reality. An AI overseer watching apps at work could make the difference between sadness and euphoria in your efforts.
We’re seeing AI misses more and more often. Facebook recently admitted its algorithms failed to stop uploads of a particularly heinous live-streamed video. Autonomous vehicles have struck cars and people. Jaywalkers in China have been misidentified and publicly shamed in error. It’s not for lack of effort in development. The adage “If it were easy, anyone could do it” applies.
A few weeks back, I was in a Twitter chat session on AI led by Kirk Borne, data scientist at Booz Allen Hamilton. The question came up of what organizations should consider when creating guidelines for use of data and bias-free AI. Here’s my response:
A4: DevOps teams should have someone whose role is AI oversight—actually watching what it’s doing and constantly testing/validating its findings #MITSMRChat
Most fails are due to fire-and-forget, wherein AI systems are trained, tested against training and turned loose. Even a well-designed AI system is subject to several problems:
Errors: This is where AI makes a factually incorrect decision. False positives and false negatives are in this category, along with miscategorization problems.
Gaps: There are situations in which AI understands conflicting options and is unable to choose. Then, there are situations in which the AI doesn’t recognize what it sees.
Bias: Maybe the system prefers green M&Ms or German shepherds because there was some subtle trend in the training data for “candy” or “dog.”
Ethics: This can be a higher level of bias, where preference is given based on age, gender or race. Sometimes it’s the classic no-win scenario in which both options are harmful.
An AI overseer guards against these types of problems in near real-time, every day, for as long as it takes to weed them out. Some problems are easier than others. An example of a more difficult problem came when autonomous vehicle researchers realized that not all traffic signs are brand new and well-lit. Shade, branches, wind, scratches, dings, bullet holes, stickers, graffiti and many more types of defects exist in the real world.
Increased Complexity
Inevitably, part of the solution the AI overseer leads is better scenario-planning and more training data. Retraining becomes a way of life and at some point, bigger data sets also lead to more complex implementations and another challenge: speed—after retraining to correct issues, the reloaded real-time classification engine runs like it’s stuck in molasses, producing correct results too late to be useful.
While the A system is running, a B version should be in development with new training and classifier boxes. For very large data sets, teams should consider designing a workload-optimized training server complex instead of relying on elastic cloud resources. This was behind NVIDIA’s recent acquisition of Mellanox—using InfiniBand for more bandwidth between GPU clusters in AI server complexes.
Where training systems often scale, real-time systems usually don’t. They are optimized for size and power consumption and can only accept so many additions. When a bottleneck emerges, it can kill the entire application. New generations of CPUs, GPUs and FPGAs keep pushing the envelope for designers tackling AI challenges.
Human-in-the-Loop
In many use cases, the job of the AI system is not to make every single decision autonomously. Instead, the system should make routine decisions and lead the AI overseer to look at exception cases. Directing humans quickly to areas needing attention is often more valuable than risking bad decisions. Human-in-the-loop is something DevOps teams should architect into systems more often.
This may all sound obvious, but it points out a big difference in developing AI versus developing code-based algorithms. If there’s a bug in code, you can debug it and find the offending lines of code to fix. But debugging AI is a lot more difficult. Digital twin implementations come into play using playback of real-work inputs to look at what happens inside the classifier black box. There are usually hints of problems developing before catastrophe strikes. Running data both good and bad can help spot issues.
Ideally, the AI overseer is a hybrid of a data scientist plus a systems architect. Look for someone who understands both data sets and hardware implementations, at least at a high level. They may have to call in other resources on the team for detailed investigations.
The last thing you want after all the hard work in developing a system is to have it run amok months or years later. It’s just Murphy’s Law. AI systems will do something entirely unexpected at the worst possible time. An AI overseer can help a DevOps team get ahead of AI problems.
Also added is the ability to automate several testing functions, including the ability to launch functional tests within a browser and execute unit, functional and integration tests without having to manually create their own Job Control Language (JCL). According to Compuware, testers now can design test cases upfront based on program specifications before developing a program. What’s more, Topaz for Total Test has been integrated with the DevOps pipeline management platform developed by XebiaLabs.
