Successfully Deploying AIOps, Part 3: The AIOps Apprenticeship

This is a copy of an original post on the AppDynamics blog here.



The Strategic Brief:

By augmenting operations teams, AIOps enables organizations to preemptively ensure that applications, architectures and infrastructures are ready for rapid digital transformation.



Part one of our series on deploying AIOPs identified how an anomaly breaks into two broad areas: problem time and solution time. Part two described the first deployment phase, which focuses on reducing problem time. With trust in the AIOps systems growing, we’re now ready for part three: taking on solution time by automating actions.

French Clock

© 2019 Marco Coulter

Applying AIOps to Mean Time to Fix (MTTFix)

The power of AIOps comes from continuous enhancement of machine learning powered by improved algorithms and training data, combined with the decreasing cost of processing power. A measured example was Googles project for accurately reading street address numbers from its street image systems—a necessity in countries where address numbers don’t run sequentially but rather are based on the age of the buildings. Humans examining photos of street numbers have an accuracy of 98%. Back in 2011, the available algorithms and training data produced a trained model with 91% accuracy. By 2013, improvements and retraining boosted this number to 97.5%. Not bad, though humans still had the edge. In 2015, the latest ML models passed human capability at 98.1%. This potential for continuous enhancement makes AIOps a significant benefit for operational response times.

You Already Trust AI/ML with Your Life

If you’ve flown commercially in the past decade, you’ve trusted the autopilot for part of that flight. At some major airports, even the landings are automated, though taxiing is still left to pilots. Despite already trusting AI/ML to this extent, enterprises need more time to trust AI/ML in newer fields such as AIOps. Let’s discuss how to build that trust.

Apprenticeships allow new employees to learn from experienced workers and avoid making dangerous mistakes. They’ve been used for ages in multiple professions; even police departments have a new academy graduate ride along with a veteran officer. In machine learning, ML frameworks need to see meaningful quantities of data in order to train themselves and create nested neural networks that form classification models. By treating automation in AIOps like an apprenticeship, you can build trust and gradually weave AIOps into a production environment.

By this stage, you should already be reducing problem time by deploying AIOps, which delivers significant benefits before adding automation to the mix. These advantages include the ability to train the model with live data, as well as observe the outcomes of baselining. This is the first step towards building trust in AIOps.

Stage One: AIOps-Guided Operations Response

With AIOps in place, operators can address anomalies immediately. At this stage, operations teams are still reviewing anomaly alerts to ensure their validity. Operations is also parsing the root cause(s) identified by AIOps to select the correct issue to address. While remediation is manual at this stage, you should already have a method of tracking common remediations.

In stage one, your operations teams oversee the AIOps system and simultaneously collect data to help determine where auto-remediation is acceptable and necessary.

Stage Two: Automate Low Risk

Automated computer operations began around 1964 with IBM’s OS/360 operating system allowing operators to combine multiple individual commands into a single script, thus automating multiple manual steps into a single command. Initially, the goal was to identify specific, recurring manual tasks and figure out how to automate them. While this approach delivered a short-term benefit, building isolated, automated processes incurred technical debt, both for future updates and eventual integration across multiple domains. Ultimately it became clear that a platform approach to automation could reduce potential tech debt.

Automation in the modern enterprise should be tackled like a microservices architecture: Use a single domain’s management tool to automate small actions, and make these services available to complex, cross-domain remediations. This approach allows your investment in automation to align with the lifespan of the single domain. If your infrastructure moves VMs to containers, the automated services you created for networking or storage are still valid.

You will not automate every single task. Selecting what to automate can be tricky, so when deciding whether to fully automate an anomaly resolution, use these five questions to identify the potential value:

  • Frequency: Does the anomaly resolution occur often enough to warrant automation?
  • Impact: Are you automating the solution to a major issue?
  • Coverage: What proportion of the real-world process can be automated?
  • Probability: Does the process always produce the desired result, or can it be impacted by environmentals?
  • Latency: Will automating the task achieve a faster resolution?

Existing standard operating procedures (SOPs) are a great place to start. With SOPs, you’ve already decided how you want a task performed, have documented the process, and likely have some form of automation (scripts, etc.) in place. Another early focus is to address resource constraints by adding front-end web servers when traffic is high, or by increasing network bandwidth. Growing available resources is low risk compared to restarting applications. While bandwidth expansion may impact your budget, it’s unlikely to break your apps. And by automating resource constraint remediations, you’re adding a rapid response capability to operations.

In stage two, you augment your operations teams with automated tasks that can be triggered in response to AIOps-identified anomalies.

Stage Three: Connect Visibility to Action (Trust!)

As you start to use automated root cause analysis (RCA), it’s critical to understand the probability concept of machine learning. Surprisingly, for a classical computer technology, ML does not output a binary, 0 or 1 result, but rather produces statistical likelihoods or probabilities of the outcome. The reason this outcome sometimes looks definitive is that a coder or “builder” (the latter if you’re AWS’s Andy Jassy) has decided an acceptable probability will be chosen as the definitive result. But under the covers of ML, there is always a percentage likelihood. The nature of ML means that RCA sometimes will result in a selection of a few probable causes. Over time, the system will train itself on more data and probabilities and grow more accurate, leading to single outcomes where the root cause is clear.

Once trust in RCA is established (stage one), and remediation actions are automated (stage two), it’s time to remove the manual operator from the middle. The low-risk remediations identified in stage two can now be connected to the specific root cause as a fully automated action.

The benefits of automated operations are often listed as cost reduction, productivity, availability, reliability and performance. While all of these apply, there’s also the significant benefit of expertise time. “The main upshot of automation is more free time to spend on improving other parts of the infrastructure,” according to Google’s SRE project. The less time your experts spend in MTTR steps, the more time they can spend on preemption rather than reaction.

Similar to DevOps, AIOps will require a new mindset. After a successful AIOps deployment, your team will be ready to transition from its existing siloed capabilities. Each team member’s current specialization(s) will need to be accompanied with broader skills in other operational silos.

AIOps augments each operations team, including ITOps, DevOps and SRE. By giving each team ample time to move into preemptive mode, AIOps ensures that applications, architectures and infrastructures are ready for the rapid transformations required by today’s business.

Successfully Deploying AIOps, Part 2: Automating Problem Time

This is a copy of an original post on the AppDynamics blog here.



The Strategic Brief:

Built-in AI/ML—such as in AppDynamics APM—delivers value by activating the cognitive engine of AIOps to address anomalies.



Asian Clock 1

© 2017 Marco Coulter

In part one of our Successfully Deploying AIOps series, we identified how an anomaly breaks into two broad areas: problem time and solution time. The first phase in deploying AIOps focuses on reducing problem time, with some benefit in solution time as well. This simply requires turning on machine learning within an AIOps-powered APM solution. Existing operations processes will still be defining, selecting and implementing anomaly rectifications. When you automate problem time, solution time commences much sooner, significantly reducing an anomaly’s impact.

AIOps: Not Just for Production

Anomalies in test and quality assurance (QA) environments cost the enterprise time and resources. AIOps can deliver significant benefits here. Applying the anomaly resolution processes seen in production will assist developers navigating the deployment cycle.

Test and QA environments are expected to identify problems before production deployment. Agile and DevOps approaches have introduced rapid, automated building and testing of applications. Though mean time to resolution (MTTR) is commonly not measured in test and QA environments (which aren’t as critical as those supporting customers), the benefits to time and resources still pay off.

Beginning your deployment in test and QA environments allows a lower-risk, yet still valuable, introduction to AIOps. These pre-production environments have less business impact, as they are not visited by customers. Understanding performance changes between application updates is critical to successful deployment. Remember, as the test and QA environments will not have the production workload available, it’s best to recreate simulated workloads through synthetics testing.

With trust in AIOps built from first applying AIOps to mean time to detect (MTTD), mean time to know (MTTK) and mean time to verify (MTTV) in your test and QA environments, your next step will be to apply these benefits to production. Let’s analyze where you’ll find these initial benefits.

Apply AI/ML to Detection (MTTD)

An anomaly deviates from what is expected or normal. Detecting an anomaly requires a definition of “normal” and a monitoring of live, streaming metrics to see when they become abnormal. A crashing application is clearly an anomaly, as is one that responds poorly or inconsistently after an update.

With legacy monitoring tools, defining “normal” was no easy task. Manually setting thresholds required operations or SRE professionals to guesstimate thresholds for all metrics measured by applications, frameworks, containers, databases, operating systems, virtual machines, hypervisors and underlying storage.

AIOps removes the stress of threshold-setting by letting machine learning baseline your environment. AI/ML applies mathematical algorithms to different data features seeking correlations. With AppDynamics, for example, you simply run APM for a week. AppDynamics observes your application over time and creates baselines, with ML observing existing behavioral metrics and defining a range of normal behavior with time-based and contextual correlation. Time-based correlation removes alerts related to the normal flow of business—for example, the login spike that occurs each morning as the workday begins; or the Black Friday or Guanggun Jie traffic spikes driven by cultural events. Contextual correlation pairs metrics that track together, enabling anomaly identification and alerts later when the metrics don’t track together.

AIOps will define “normal” by letting built-in ML watch the application and automatically create a baseline. So again, install APM and let it run. If you have specific KPIs, you can add these on top of the automatic baselines as health rules. With baselines defining normal, AIOps will watch metric streams in real time, with the model tuned to identify anomalies in real time, too.

Apply AI/ML to Root Cause Analysis (MTTK)

The first step to legacy root cause analysis (RCA) is to recreate the timeline: When did the anomaly begin, and what significant events occurred afterward? You could search manually through error logs to uncover the time of the first error. This can be misleading, however, as sometimes the first error is an outcome, not a cause (e.g., a crash caused by a memory overrun is the result of a memory leak running for a period of time before the crash).

In the midst of an anomaly, multiple signifiers often will indicate fault. Logs will show screeds of errors caused by stress introduced by the fault, but fail to identify the underlying defect. The operational challenge is unpacking the layers of resultant faults to identify root cause. By pinpointing this cause, we can move onto identifying the required fix or reconfiguration to resolve the issue.

AIOps creates this anomaly timeline automatically. It observes data streams in real time and uses historical and contextual correlation to identify the anomaly’s origin, as well as any important state changes during the anomaly. Even with a complete timeline, it’s still a challenge to reduce the overall noise level. AIOps addresses this by correlating across domains to filter out symptoms from possible causes.

There’s a good reason why AIOps’ RCA output may not always identify a single cause. Trained AI/ML models do not always produce a zero or one outcome, but rather work in a world of probabilities or likelihoods. The output of a self-taught ML algorithm will be a percentage likelihood that the resulting classification is accurate. As more data is fed to the algorithm, these outcome percentages may change if new data makes a specific output classification more likely. Early snapshots may indicate a priority list of probable causes that later refine down to a single cause, as more data runs through the ML models.

RCA is one area where AI/ML delivers the most value, and the time spent on RCA is the mean time to know (MTTK). While operations is working on RCA, the anomaly is still impacting customers. The pressure to conclude RCA quickly is why war rooms get filled with every possible I-shaped professional (a deep expert in a particular silo of skills) in order to eliminate the noise and get to the signal.

Apply AI/ML to Verification

Mean time to verify (MTTV) is the remaining MTTR portion automated in phase one of an AIOps rollout. An anomaly concludes when the environment returns to normal, or even to a new normal. The same ML mechanisms used for detection will minimize MTTV, as baselines already provide the definition of normal you’re seeking to regain. ML models monitoring live ETL streams of metrics from all sources provide rapid identification when the status returns to normal and the anomaly is over.

Later in your rollout when AIOps is powering fully automated responses, this rapid observation and response is critical, as anomalies are resolved without human intervention.  Part three of this series will discuss connecting this visibility and insight to action.

Successfully Deploying AIOps, Part 1: Deconstructing MTTR

This is a copy of an original post on the AppDynamics blog here.



The Strategic Brief:

Quantifying the value of successful AIOps deployment requires tracking subsidiary metrics within the industry default of mean time to resolution (MTTR). This post breaks out the metrics that form MTTR and divides them into two categories: problem and solution.



Somewhere between waking up today and reading this blog post, AI/ML has done something for you. Maybe Netflix suggested a show, or DuckDuckGo recommended a website. Perhaps it was your photos application asking you to confirm the tag of a specific friend in your latest photo. In short, AI/ML is already embedded into our lives.

The quantity of metrics in development, operations and infrastructure makes development and operations a perfect partner for machine learning. With this general acceptance of AI/ML, it is surprising that organizations are lagging in implementing machine learning in operations automation, according to Gartner.

The level of responsibility you will assign to AIOps and automation comes from two factors:

  • The level of business risk in the automated action
  • The observed success of AI/ML matching real world experiences

The good news is this is not new territory; there is a tried-and-true path for automating operations that can easily be adjusted for AIOps.

It Feels Like Operations is the Last to Know

The primary goal of the operations team is to keep business applications functional for enterprise customers or users. They design, “rack and stack,” monitor performance, and support infrastructure, operating systems, cloud providers and more. But their ability to focus on this prime directive is undermined by application anomalies that consume time and resources, reducing team bandwidth for preemptive work.

An anomaly deviates from what is expected or normal. A crashing application is clearly an anomaly, yet so too is one that was updated and now responds poorly or inconsistently. Detecting an anomaly requires a definition of “normal,” accompanied with monitoring of live streaming metrics to spot when the environment exhibits abnormal behaviour.

The majority of enterprises are alerted to an anomaly by users or non-IT teams before IT detects the problem, according to a recent AppDynamics survey of 6,000 global IT leaders. This disappointing outcome can be traced to three trends:

  • Exponential growth of uncorrelated log and metric data triggered by DevOps and Continuous Integration and Continuous Delivery (CI/CD) in the process of automating the build and deployment of applications.
  • Exploding application architecture complexity with service architectures, multi-cloud, serverless, isolation of system logic and system state—all adding dynamic qualities defying static or human visualization.
  • Siloed IT operations and operational data within infrastructure teams.

Complexity and data growth overload development, operations and SRE professionals with data rather than insight, while siloed data prevents each team from seeing the full application anomaly picture.

Enterprises adopted agile development methods in the early 2000s to wash away the time and expense of waterfall approaches. This focus on speed came with technical debt and lower reliability. In the mid-2000s manual builds and testing were identified as the impediment leading to DevOps, and later to CI/CD.

DevOps allowed development to survive agile and extreme approaches by transforming development—and particularly by automating testing and deployment—while leaving production operations basically unchanged. The operator’s role in maintaining highly available and consistent applications still consisted of waiting for someone or something to tell them a problem existed, after which they would manually push through a solution. Standard operating procedures (SOPs) were introduced to prevent the operator from accidentally making a situation worse for recurring repairs. There were pockets of successful automation (e.g., tuning the network) but mostly the entire response was still reactive. AIOps is now stepping up to allow operations to survive in this complex environment, as DevOps did for the agile transformation.

Reacting to Anomalies

DevOps automation removed a portion of production issues. But in the real world there’s always the unpredictable SQL query, API call, or even the forklift driving through the network cable. The good news is that the lean manufacturing approach that inspired DevOps can be applied to incident management.

To understand how to deploy AIOps, we need to break down the “assembly line” used to address an anomaly. The time spent reacting to an anomaly can be broken into two key areas: problem time and solution time.

Problem time: The period when the anomaly has not yet being addressed.

Anomaly management begins with time spent detecting a problem. The AppDynamics survey found that 58% of enterprises still find out about performance issues or full outages from their users. Calls arrive and service tickets get created, triggering professionals to examine whether there really is a problem or just user error. Once an anomaly is accepted as real, the next step generally is to create a war room (physical or Slack channel), enabling all the stakeholders to begin root cause analysis (RCA). This analysis requires visibility into the current and historical system to answer questions like:

  • How do we recreate the timeline?
  • When did things last work normally or when did the anomaly began?
  • How are the application and underlying systems currently structured?
  • What has changed since then?
  • Are all the errors in the logs the result of one or multiple problems?
  • What can we correlate?
  • Who is impacted?
  • Which change is most likely to have caused this event?

Answering these questions leads to the root cause. During this investigative work, the anomaly is still active and users are still impacted. While the war room is working tirelessly, no action to actually rectify the anomaly has begun.

Solution time: The time spent resolving the issues and verifying return-to-normal state.

With the root cause and impact identified, incident management finally crosses over to spending time on the actual solution. The questions in this phase are:

  • What will fix the issue?
  • Where are these changes to be made?
  • Who will make them?
  • How will we record them?
  • What side effects could there be?
  • When will we do this?
  • How will we know it is fixed?
  • Was it fixed?

Solution time is where we solve the incident rather than merely understanding it. Mean time to resolution (MTTR) is the key metric we use to measure the operational response to application anomalies. After deploying the fix and verifying return-to-normal state, we get to go home and sleep.

Deconstructing MTTR

MTTR originated in the hardware world as “mean time to repair”— the full time from error detection to hardware replacement and reinstatement into full service (e.g., swapping out a hard drive and rebuilding the data stored on it). In the software world, MTTR is the time from software running abnormally (an anomaly) to the time when the software has been verified as functioning normally.

Measuring the value of AIOps requires breaking MTTR into subset components. Different phases in deploying AIOps will improve different portions of MTTR. Tracking these subdivisions before and after deployment allows the value of AIOps to be justified throughout.

With this understanding and measurement of existing processes, the strategic adoption of AIOps can begin, which we discuss in part two of this series.

Nine Essential Skillsets for Competitive Digital Transformation

This is a copy of an original post on the AppDynamics blog here.



The Strategic Brief:

If you’re reading this, there’s a good chance you’re an Agent of Transformation ready to change the world. As your enterprise pivots towards AIOps, your team must accumulate the right skills to embrace digital transformation while innovating at scale.



Street Art in Cartagena, Colombia
Large and midsize enterprises successful at competitive transformation have one characteristic in common: careful team-building around both soft and technical skills. Let’s examine how you should think about your digital transformation team (even though it may not be called that). Since there are many books on building agile teams, squads and dojos, this post will focus on the soft skill mix that a majority of IT executives say is the roadblock to successful competitive digital transformation.

Application creation is facing accelerating waves of change. The World Economic Forum asserts we are entering the fourth industrial revolution, even as the third chugs along. Surviving concurrent revolutions requires our digital transformation approach to be as agile as our development methodology. Your transformation must result in a digitally competitive enterprise. The skills needed can be broken into three categories, each with three sub-categories.

 

Skills to Survive

Consider the bare minimum set of skills required for DevOps projects to avoid failure. These fall into three general subcategories: organizational, business and technology.

Organizational

Organizational people line up the dominos for other participants to knock over. They ensure decisions are made and the work gets done as expected. These are skills or titles that DevOps practitioners will be well familiar with, including Scrum Master, Project Manager, Squad leader, and Technical Architect. Without these skills, effort tends to run overtime and wanders away from original goals.

Business

Business people bring the reality check from the real world. They ensure that technical success will have business relevance, and that the business is ready for transformed business models and processes. Look for titles like Product Owner, Business Systems Expert, and Business Line Owner. As more digital natives enter your enterprise, expect a higher level of digital awareness and creativity from those bringing your business skills into the team.

Technology

Technology people build the complex clock and keep it ticking. Here you seek technology-specific skills such as TensorFlow, Kubernetes, or JavaScript that are needed by the specific architecture. On top of these siloed skills, look for general process experience as in DevOps, quality assurance, security, infrastructure, or integration.

These three groups are the essentials—the survival skills—for digital processes to exist and thus are the minimum set needed for digital transformation. Any enterprise going through this transformation has these skillsets—in some shape or form with engineering and organizational skills—in its transformation teams. However, once your business transformation introduces artificial intelligence as part of the architecture, you will need to think differently about the skills needed for success.

Skills for Machine Learning

The machine learning (ML) statistical revolution is changing the world. To embrace this change, enterprises must engage ML in two main ways: as a black box encapsulated within a vendor’s product; or custom-built for competitive advantage.

Application Performance Management (APM) is a good example
of the black box approach where AIOps or Cognitive Services
are delivered by your vendor, and the skills listed under
machine
learning are not required.

When encapsulated, the needed skills are housed within the software vendor rather than in your organization, and the vendor will select the optimal algorithms and training frameworks for each type of data and specific use case. For targeted solutions like DevOps, the encapsulated approach is best.

However, you may be surprised by some of the skills required for your business to build out a data science team and gain competitive advantage from machine learning. Research from Accenture and MIT broke the skills surrounding artificial intelligence into three categories: trainers, explainers and sustainers. (The Jobs That Artificial Intelligence Will Create)

Trainers

Trainers are what we see commonly in AI today. They match models and frameworks to specific tasks, and identify and label training data. Trainers help models look beyond the literal into areas such as how to mimic human behavior, whether in speech or driving reactions. In London, a team is trying to teach chatbots about irony and sarcasm so they can interact with humans more effectively.

Explainers

As AI gets more advanced, the layers of neural networks creating answers will exceed simple explanations. Explainers will provide non-technical explanations of how the AI algorithms interpret inputs and how conclusions are reached. This will be essential to attain compliance, or to address legal concerns about bias in the machine. If you create AI to approve mortgages, for instance, how will you establish the AI is not inflicting bias based on gender or creed? The explainer will play a necessary role.

Sustainers

Someone needs to ensure the AI systems are operating as designed ethically, financially and effectively. The sustainers will monitor for and react to unintended outcomes from the “black box.” If the AI is selecting inventory and setting prices, a sustainer will ensure there is no resulting price-gouging on consumer necessities—thus avoiding customer revolt.

The machine learning marketplace is the opposite of the gig economy. In the gig economy, skills are a commodity, like driving a vehicle. You can swap cars and still be a skilled driver. In contrast, the needed skills for ML may change with every new type of data. When your competitive digital transformation seeks customer facial recognition as shoppers walk in the store, you will likely apply Tensorflow and hire for those skills. Next, the business may want to recommend adjacent products to a customer. The optimal algorithm will be a decision tree, and now you’ll need to hire for that skill. Later you may need email text inference, which requires skills in text tokenizing and stemming before the email data can be fed into Tensorflow. You end up using different languages and frameworks for each new use case. Even within a single use case, the optimal algorithm may change over time as particular frameworks improve for specific tasks.

For the technical hire, you should qualify on aptitude rather than skills. Find the right person, then train them. The apprenticeship approach of giving workers time to learn shows you value your people, which enhances loyalty. You either accept apprenticeship as a cost, or you will need to hire an army of individuals. With AI/ML, you will initially hire the trainers that select and code models. As you do, consider who will grow into the explainers and sustainers.

Regardless of whether your transformation includes machine learning, there are additional skills you’ll need to attain competitive business transformation.

Skills to Compete

Now we are getting into a different mind space altogether. Inclusiveness and variety are now stated goals for leading competitive companies. News headlines have multiple examples where applications failed embarrassingly due to the lack of variety, digital awareness and experience in the transformation team. Even an automatic soap dispenser can have bias if it delivers foam to light-skinned hands but not into the hands of people of color. In this real-world example, the dispenser registered light reflected off caucasian skin, but the Fitzpatrick scale tells us you need a stronger light to trigger the sensor for people of color. A broader team or testing regimen would have identified the problem before release. Similarly, Amazon immediately cancelled a machine learning project once aware of the inherent bias of its trained model. Amazon, hoping to better prioritise future applicants, trained a ML model with resumes from previously successful candidates. Unfortunately, the trained model kept selecting males because most of the successful resumes in the past decade had been predominantly male.

For competitive digital transformation, add these three new groups of skills to your requirements:

Culture

Firstly, look at your overall culture and diversity. Without considering culture, you may easily leave your reputation in tatters as in the examples above. Seek out variety in gender. Combine millennials with baby boomers and mix digital natives with digital immigrants. Even variation in birthplace and societal culture creates the variety of viewpoints needed to ward off potential bias. Hearing different voices will help identify gaps in testing criteria and in training data sets.

Dexterity

The second set of skills leads to “digital dexterity.” Remember, you want the benefits of digital transformation to be experienced by the largest number of people across your organization. This effort involves evangelizing the changes to the entire organization through training and communication. Ensure that all those using technology feel completely comfortable and skilled with the technology. Identify an ambassador to the executive team, someone outside the regular reporting structure. Look for a person on the fast path to leadership—maybe recently out of college—and assigned a mentor from the executive level. This ambassador will communicate important achievements and crucial requirements when needed. Also, look for an internal VC. Sometimes the executive sponsor of the transformation is not the same person as the budgetary sponsor. Ensure someone has the skills to build a VC-like pitch for continued funding.

Experience

Today’s app-driven world makes User Experience (UX) and Customer Experience (CX) critical. These are terms not equivalent, as UX is an app category focusing on human interaction with technology, while CX goes beyond the application to the full interaction a human will have with your organization. Are people walking in a door, or onto a factory floor, or calling via phone to reach your digitally transformed technology? What happens after they exit the website or application? Owning these experiences is as critical to successful competitive digital transformation as understanding the experiences offered by your competitors. It’s essential to correlate user and customer experience to application performance and business impact.

The best way to understand the strengths of your team for competitive digital transformation is to create a simple table of skills mentioned above as rows, and team candidates as columns. As you build out the team, check off the skills. In essence, any skill not provided by the team will need to be provided by you as the Agent of Transformation.

Turning Digital Transformation into Digital Dexterity

This is a copy of an original post on the AppDynamics blog here.



The Strategic Brief:

In a disruptive business world, digitizing the traditional workplace is not enough. Digital dexterity gives you power to make lasting, impactful change.

The goal of digital dexterity is to build a flexible, agile workplace and workforce invested in the success of the organization. This dexterity allows the enterprise to treat employees like consumers—researching their challenges, goals and desired technologies—and then allowing the employees to exploit existing and emerging technologies for better business outcomes. This post advises line-of-business and product owners, already acting as agents of transformation inside their enterprises, on extending the metamorphosis into dexterity.



© 2003 Marco Coulter

© 2003 Marco Coulter

The Road vs. The Mountaintop

The journey begins with digital transformation, a road leading to multiple destinations. It is not a singular goal, but rather a way of life. Even digital-first enterprises continue to transform as they experiment with different business models or expand into new markets.

Enterprises executing digital transformations share three common goals:

  • Making analog tasks digital
  • Seeking new ways to solve old problems
  • Making the business better

While all three goals are important, the technical challenges of digital transformation often end up overshadowing the goal of improving the business. Transformation must leave the business not just different, but better. The transformed enterprise needs to be more agile in both application development and business. Digital transformation needs to result in a new company with digital ’savvy’, an understanding of the power of the data being collected, and the flexible and informed mindset required for digital dexterity.

Dexterity vs. Transformation

The real goal of digital transformation is to shorten the time required to transform business processes. How quickly can you spot a new or altered opportunity? Is the business digitally savvy enough to comprehend the possibilities of new technologies like blockchain, internet of things, and edge computing? Is your business now digitally dextrous?

Digitization without exploiting resultant data is a negative technical investment.

The next step in this journey—data extraction and data-driven decision making—mines the real value of going digital. The significant power of digital over analog is the ease of accumulating and assessing data, including data on each customer click, each cloud system executed upon, each line of code, and even each stage in a business process.

Often the first projects in digital transformation take long, lapsed periods of time. IT will need to rebuild itself first, and take many steps to respond faster to evolving needs. IT will also need to upgrade traditional waterfall models into agile development lifecycles with continuous integration and continuous delivery. Departments can restructure to create DevOps teams to reduce time from coding to deployment.

In the middle of long transformation projects, it is worth stepping back and asking anew: Why are we doing this? Digital transformation has been around so long, it may feel like it’s past the use-by date. Though some enterprises birth as digital-first, many are still struggling with basic analog-digital transformation. In the rush to deal with technology of multi-channel digitization, the goal often is missed.

(For more on digital transformation in specific industry verticals, read the AppDynamics blog posts on insurance, retail bankingand construction.)

Digital Dexterity

Once your digital processes are generating data, the next step is to ensure you can exploit the wisdom of that data.

Achieving digital dexterity requires a new culture on both the business and technical sides. The technology team not only needs the technical skills to transform, but also the diplomatic skills to boost the organization’s digital dexterity. Amongst the “best coders on the planet” that you hire, you will want to seed the best communicators and evangelists as well. The business team will initially need your support in understanding what can be exploited with technology; the technical team will need to communicate using business terms. Similarly, these teams need to be presented with clear correlations from their application deliverables to business outcomes. Developing a multichannel awareness may be a new thing for your salesforce.

The real measure of dexterity is the enterprise’s ability to empower technical staff to make business decisions, and business staff to drive technical choices.

Challenges You Will Meet

Culture

Gartner’s 2018 CIO Survey reveals that CIOs believe corporate culture is one of the biggest barriers to digital transformation, followed by resources and talent. Those three elements make up 82% of digital business impediments, the survey says.

Consider expanding DevOps into BizDevOps. For this, you will need a nervous system connected to all parts of your enterprise to define common goals for both the business and technical teams, both of which need a common, shared view of data to allow differently trained participants to discuss and identify solutions.

Build a common vision and strategy across your business and technology leaders. Collaborative learning across team and knowledge structures is an effective way to help employees become dextrous.

Embracing diversity is a key action that adds a variety of viewpoints for spotting new opportunities. Make sure your strategy considers the employee experience (also a good time to preclude bias for gender, disabilities, etc.). Consider if the approach makes the employee more business-literate and more empowered to exploit new business processes.

Application owners need to continuously search out ways to improve employee effectiveness. The applications we develop should always listen to, interpret, and learn from their users. In the same way smart speakers were extremely stupid initially but self-improved over time, the enterprise application should consider user activity and create more efficient workflows for the user.

Technical Delay

As part of digital transformation, enterprises build out business intelligence frameworks, creating data lakes and gaining a rearview-mirror view of their business. Executives may even bring on data scientists to create models to predict the coming quarter. Each of these actions has value but excludes one key timeframe: today. Right now.

Why Aim for Dexterity?

Every company today is experiencing disruption. In fact, more companies experience disruption than act as disruptors. Right now, there’s a startup somewhere that will eventually flip to a business model that challenges yours. It might be a small change, or a permanent change in the marketplace. Your job is to prepare your enterprise by making sure your employees are empowered with self-serve, consumer-like technologies, and that they’re aware of the possibilities of change.

A dextrous enterprise can easily respond to market movements and disruptions. New businesses can be created with less struggle once it’s easier to connect departments and businesses. Employees with common awareness of the business—and the technology supporting the business—can readily identify, define and exploit new revenue opportunities. The holy grail alignment of IT and business will come through having all parties look at the same data to enable data-driven decisions.

Remember, the dextrous enterprise provides a consumer-like experience for its employees.

Transformation must leave the business not just improved, but better at surviving disruptions. The transformed enterprise is more agile in both development and business. It is able to rapidly integrate and partner with external businesses when the opportunity or need arises, and connect disparate business processes into a new buyer’s journey when a disruptor changes the marketplace. Digital transformation needs to deliver a new company that understands the power of collected data and the flexibility to harness the latest technology.

Digital dexterity is people using digital technologies to think, act and organize themselves in new and productive ways.

For more uses cases supporting digital dexterity, read how customers are using Business iQ for AppDynamics.

An Interface Refresh Can Revitalize Existing Features

Refreshing an interface feels new, even when it does nothing that actually is new.


The Strategic Brief:
Applications are not always brand new. We all use many applications that have been in use for years, perhaps decades. For mobile applications, refreshing the interface is a requirement, rather than a nice to have. If you are lucky, it will be delivered by updates to the underlying OS at little development cost (e.g. notifications in iOS 10). If unlucky, matching your interface to the esthetic of an OS may require you to redesign your app from the ground up. If done well, redesign can be more than refreshing for customers, it can be reengaging.


Refreshing an application interface can reenergize your users
In kicking the tires of iOS 10, there are clear changes in experience for existing features. A noticeable one is notifications. Notifications still do what they always did – an application calls an API to let the owner know a piece of information by displaying it on the lock screen. It is still notifying .. but it looks like a new feature.
I reacted viscerally and immediately to the new notification style. It feels like a new feature. It makes me want to pay attention to the notifications more often and more deeply. I am re-engaged with notifications. It feels new, though it does nothing that actually is new.
See the before and after shots from Politico below.
before

iOS 9 Notifications

after

iOS 10 Notifications

The design, coding, testing and quality assurance around refreshing an interface costs money. It can even cost more than adding a new feature. If the user interface code is not isolated within the application code, a refresh can involve changes to a significant number of modules.

Public Betas are a two-edged sword

In the above example, Apple invested even further by offering a public beta as well. A beta means your feature receives significant testing before general availability. A public beta also introduces risk. If early reactions are negative, the release’s reputation is sullied. This uncertainty is mitigated by the ability to address problems before the product is released. Coordinating and supporting all the people involved in a public beta is an additional expense for a refresh.

Is refreshing an interface a good or bad idea?

Like everything in technology, the answer is .. “it depends”. If you are lucky, you may get a free refresh. In iOS10 – your code calls the same API but the underlying operating system gives the result a refreshed appearance. The display looks different, as in the Notifications example above.(1) Sometimes, the operating system or framework will force a refresh on you.If it changes it’s navigation esthetic, you may have to redesign your app from the ground up to match. Users expect consistency in their experience.

Making happier customers

If your goal is to improve the user experience, you will need usage details from your customers. If you have enough specifics to understand how your customers use the feature today, you stand a good chance of reworking the interface to optimize the common tasks. If you are not tracking usage, then an interface refresh is more likely to be an egotistical exercise of how your developers think it should be used.

Refreshing an interface may elongate an aging product’s lifespan

A young application grows by adding more features. Eventually the application matures and may not need more features. To keep the revenue alive, product managers will still want further releases. The good news is that every year the industry identifies new and more efficient navigation techniques. Adding these into an aging product is a valuable way to revitalize the product, and give yourself an additional version to release.


1. Though a little cheeky, you could try to claim this as an application refresh.

Why aren’t they using my new feature?

 

 

The Strategic Brief:

When users are not using a feature that was popular in early testing, consider whether you explained the value of the feature as well as the function. Even when the use of a feature may be easily self-taught, the benefit or purpose may not be so obvious. This is a necessary lesson for manual writers and even for those writing simple help pages. Consider asking your writers and editors to bring in samples of good and bad writing. Practising on other peoples work can remove the personal feelings of reviewing written work.

A recent question from a product manager asked why users were not using a new feature. In beta testing, users enthused about the feature. Now it was in the field, only the beta testers seemed to be using it. My response was a simple question, “Did you tell them why they should be using it?” Lack of awareness is the most common reason not to use a beneficial feature.

For years, I used Canon’s point and shoot cameras, but one of my pet peeves was their manuals. The point and shoot camera is intended for the amateur photographer. Taking a good photo can be complex and Canon builds features into the camera to allow for those special opportunities. Below is their attempt to describe the fish-eye effect.

canon-screenshot

Canon Manual Example

In the Advanced Guide part of the User Manual in a section titled “Shooting with a Fish-Eye Lens Effect (Fish-Eye Effect)”. The description of the feature is detailed as .. wait for it .. “Shoot with the distorting effect of a fish-eye lens”. Well, thanks for that! They do include a sample photo of a dog’s nose using the effect.Most of us are amateurs who never went to photography school and never used a fish-eye lens. Hmm, is this a special feature for shooting dog’s noses? Canon described the feature, but failed to describe why they had bothered to put the feature in the camera. (See the end of this article for my attempt at a rewrite.)Now let’s take a look at how the Nikon S1 manual describes their Creative Modes.

nikon-s1-screenshot

Nikon Manual Example

Still quite brief – but what a difference! Nikon describes the feature, breaking it out into what you should do and what the camera will do (especially for Night landscape). Then they add a brief overview of why the feature exists. That extra sentence in each description helps you learn why to use a feature. Nikon’s manual helps you be a better photographer.Technology produces a lot of user guides, technical manuals, and quick start guides. Some are excellent, like the actionable guidance found in most IBM ‘Red’ books. Some are terrible, merely listing the available settings with no guidance as to why the developers thought that feature was worth including in the product. Yes, even for software costing hundreds of thousands of dollars.One habit I picked up as a public speaker was re-writing other peoples speeches. Today when listening to speakers, I try to rephrase statements to improve the ‘punch’ and clarify the goal of the statement. This is a good habit to get yourself and your team into. Get your writers to bring in an example of good and bad manuals. Discuss why they see them as good or bad. Then get them to rewrite a portion of the bad one. As a quick example, here is my rewritten description for the Canon example above:

Shooting with a Fish-Eye Lens Effect (Fish-Eye Effect).This mode simulates the style of a wide-angle lens known as a fisheye lens. The center of the photo is distorted to appear closer to the camera and the edges made to appear more distant. Use this mode to create the impression of being as close as possible to the subject in the photo. In the sample photo of a dog, the full head appears, while the snout gains attention by appearing out of proportion.

Feel free to improve on my rewrite in the comment section.