devopsy.kinsta.cloud

Category: DevOps Culture

  • Rethinking Data Management in a DevOps Environment

    Rethinking Data Management in a DevOps Environment

    You often hear data is the new oil. This valuable, ever-changing commodity has begun to play a starring role in many cloud-native applications. Yet, according to a number of DevOps teams, data issues continue to plague their efforts to continuously integrate, test and deploy frequent software releases. More specifically, issues with persistent data (and its underlying database engine) often appear to be the culprit.

    Your organization might be pursuing emerging IoT applications that incorporate and analyze sensor data from multiple sources. Or, your DevOps team may be trying to develop applications that extract further actionable insight about customers. Whatever the use case, there’s no doubt back-end database architectures have gained growing importance to the success of such projects. Yet, in many cases, such database systems appear to be having difficulty just keeping up with the pace of today’s DevOps pipelines.

    According to one report on the state of database deployments in 2019, 46% of DevOps teams on an accelerated release schedule (with weekly, or even daily, releases) found it “extremely or very difficult” to speed their database release cycles accordingly. In a related Redgate report on the 2019 State of Database DevOps, 20% of respondents cited slow development and release cycles as one of the biggest drawbacks to “traditional siloed database development practices.” Another 23% saw a higher risk of deployment failure and extra downtime when database changes were introduced in a traditional database environment.

    Getting to the Heart of the Data Problem

    Are such database issues the result of the wrong choice of underlying database technology–such as the use of an RDBMS, NoSQL or even a NewSQL system? Possibly.

    Maybe database issues are also caused by poor (or non-existent) cross-communication between database experts and their developer counterparts? Undoubtedly, this is true as well.

    Would you be surprised to learn both situations (wrong technology and poor communication) are often to blame? Also, to blame is the urge to solve new data problems in the same old way organizations approached their earlier, legacy use cases.

    Ultimately, as with many things DevOps-related, the answer to the data problem is likely to require change along three, separate fronts: People, process and technology. It will also require a fundamental shift in how such issues are approached at the start.

    Starting with People and Process

    Instead of worrying about database slowdowns, what if you began again with how DevOps teams first approach the many facets of the underlying data layer? This means:

    1. From the start of a project, include DBAs as part of the cross-functional DevOps team. This will help promote healthy cross-communication. They will also positively influence the development of appropriate underlying data layers and infrastructure that support your emerging use cases. In larger organizations that manage many data sets, these may be specialized database administrators (DBAs). In smaller companies, these may be more full-stack engineers who also have high-quality expertise in database operations.
    2. Identify early the different data types, domains, boundaries and optimal cloud-native patterns associated with your data. Once these are established, the team can gain a better understanding about the different ways to develop applications and data architectures for each new use case.

    In effect, organizations need to make a concerted effort to shift left with their overall data architecture discussions. This shift allows more of the right questions about data to be asked, answered and incorporated early on in the design of the overall application.

    Asking the Right Questions About Data

    Part of this early collaborative work may involve asking key questions about data. These include the best ways for an application and its users to interact with the underlying data, such as:

    • How will data be ingested and from where?
    • How will we access the data?
    • How and where will we store it?
    • How do we update and/or maintain legacy databases as we build for new use cases?
    • What types of data will we have? How will the types change or be increased over time?
    • How will we query from it? And what are the most common queries users will want to run?
    • How will we manage and scale the data in use?
    • How will we protect the data from data loss, disaster or corruption?
    • How will we secure the data?

    If these questions sound a lot like features in a data lifecycle, you’re right. But, such basic questions about data are often overlooked in the rush to deliver, integrate, test and deploy application code. So often, what happens instead is an application team creates a design, then hands it off saying, “Okay, now create a data architecture to support the application.”

    This fundamental miss with data and collaboration at the start often leads to poor database architecture decisions later. It can also cause DevOps teams to resort to workarounds to accommodate such wrong architecture choices made at the start–which may cause some development teams to choose to circumvent DBA involvement altogether. In this case, they might even find themselves opting to use public cloud services instead (or some other types of data management) to support their application.

    Instead, application teams should choose the path of early collaboration between developers and all functions of IT (including DBAs). This approach can offer better DevOps outcomes. It also helps move organizations toward a future where data architects provide an effective bridge between all parties critical to the application’s success: From the needs of developers to the platforms provided by DBAs and the underlying infrastructures needed to enable them.

    Changing Skillsets, Changing Mindsets

    As with most things DevOps-related, success at the data layer has as much to do with changing the education, mindset and culture toward database architectures and database deployment methods as it does with the specific steps in the DevOps pipeline.

    For example, if most DBAs in your organization are narrowly focused in one area (such as an Oracle DBA or SQL Server admins), your organization may benefit from investing in education to close skill gaps. Such investment can help expand the knowledge and exposure of that workforce to DevOps practices or emerging database approaches to cloud-native application patterns.

    It can also help some organizations to first identify those individuals in the organization who want to transform, innovate and learn about new tools, methods and practices.

    Hiring those with that expertise already in place is another option. When you hire new skillsets, however, the answer may not be just to hire several NoSQL administrators. This tactic will not necessarily solve your data problem, either. It may be just as beneficial (or more so) to hire someone with little specific NoSQL skills but who is good at thinking about data in a different way.

    Business First, Technology Second

    In our practice, we are often asked to weigh in on technology choices to support DevOps efforts in emerging areas such as IoT, Big Data and advanced analytics. Organizations ask us about using traditional relational databases (SQL Server, Oracle, etc.) versus NoSQL databases (MongoDB, Cassandra, etc.). They ask about the merits of one NoSQL iteration over another. They ask about how to manage persistent data in container environments. They even ask about workarounds when the data choices they’ve made cause other unexpected problems.

    We do our best to answer these questions. But, whenever possible, we also tell organizations to back up a few steps and start, instead, from their business objectives:

    • What are you trying to accomplish?
    • What are your business drivers?
    • How do you hope data will be used in these contexts?

    Answers to these questions can help you make better choices about the best data architecture to support your growing applications.

    Ultimately, new tools and technologies can enable a lot of impressive data architectures. But, just throwing tools at the data problem is not enough. Early effort and investment in people, process and cross-departmental communication is just as important to a successful data outcome for any project.

    Many of the discussions we have now are trying to take everyone back to the steps they skipped. This harks back to the fundamentals of software engineering: Addressing things early so you don’t have problems later.

    Unfortunately, data is the one component in the technology stack that you can’t easily undo once you’ve chosen a specific path with your application’s data architecture. When it comes to planning for data, it really is a pay now or pay later equation.

    Isn’t it best to take the time and choose your data path wisely rather than paying later for slowdowns or other issues with deployment and performance?

    — Jeff Bozic

  • How Enterprise IT Teams Can Win the Hearts of DevOps

    How Enterprise IT Teams Can Win the Hearts of DevOps

    Take your average IT team in a young enterprise in the midst of skyrocketing growth. There’s a good chance the workflows they’ve used since the outset can’t keep up with the ever-increasing volume of requests from the business. In the minds of some DevOps and app development teams in particular, the IT department of the scrappy startup has gradually become the department of slowing things down.

    As a result, tasks that once took hours, such as provisioning resources (e.g., virtual machines, workloads, XaaS), can now take days. For agile DevOps teams, this is essentially a showstopper: They need access to resources when they need them–not when you deem them worthy. Anything else feels like a drag on development and the business.

    Giving DevOps What They Want

    IT needs to make access to resources as seamless as possible for DevOps teams. The ultimate goal is self-service. DevOps should be able to instantly gain the access they need to the resources they need, without the back and forth of ticketing systems, or the complexity of provisioning resources on totally unfamiliar systems. And with a user interface that only serves up the resources relevant to the requesting team, DevOps can easily manage and provision resources on demand.

    Maintaining the Controls the Enterprise Needs

    Of course, it’s not about just giving DevOps access to whatever they want when they want it. You need real controls in place.

    For example, without the right guardrails, DevOps teams can easily spin up more virtual machines than they need and let them run without limit. To give you an example of how bad it can get, Gartner estimates shadow IT accounts for 30-40% of IT spend, from idle resources consuming costs by the minute.

    Through blueprints, repeatable ways to orchestrate and automate provisioning of resources, this self-service nirvana to eliminate shadow IT can be a reality for admins. Since blueprints contain set rules and builds sanctioned by IT, they’ll always be able to accurately and securely deliver the right resources, without users going rogue and out of compliance with taking provisioning into their own hands.

    For instance, IT can determine who can order servers, workloads and XaaS—along with quotas set for spend and resource usage—to who can approve fulfillment of those orders. This way, resources are never over-provisioned and a real tally is kept as to exactly who is using which resources across the business. By automating routine approval processes and applying the proper conditions to user requests, the errors and time associated with manual provisioning are eliminated and users can get what they need without going at it alone.

    Control Doesn’t Have to Come at the Cost of Delight

    In the absence of the right tools and the right processes, IT can start to seem like a slow-moving gatekeeper to DevOps teams, who need resources fast. Consuming resources needs to be easy and quick for agile developers who need to ship products to market fast. In this sense, the self-service IT model plays greatly to agility: By presenting only the resources needed for DevOps teams, and orchestrating automated processes, resources are provisioned in seconds versus the days involved with an IT ticket. Additionally, with built-in, automated permissions and role-based controls, IT teams can still protect the enterprise, as they should, but at the same time delight users.

    Take for example an organization as big as Home Depot, with over 385,000 employees: By rolling out a self-service approach to provisioning resources, they were able to completely reign in VM sprawl and at the same time make their developers’ lives easier with a provisioning time decreased from two weeks to just under 20 minutes.

    Indeed, IT admins can win the hearts of DevOps and at the same time win back their role as an enabler of enterprise-wide innovation. By empowering users with intuitive self-service to quickly get resources when they need them, IT becomes the heroes that enterprises–and their DevOps teams—need.

    — Brian J. Kelly

  • Quality Engineering Has DevOps and Agile in the Driving Seat

    Quality Engineering Has DevOps and Agile in the Driving Seat

    As opposed to the traditional software development lifecycle (aka waterfall), today’s Agile and DevOps-based software development process is more outcome-oriented. The unrelenting pace of the changing market landscape has made the hybrid, Agile plus DevOps way of software development absolutely critical in addressing customer demands and staying competitive.

    The focus on Agile and DevOps is necessary due to the high failure rates of traditional software development methodologies. These failure rates are mainly attributed to the glitch-infested, low-quality applications churned out by following legacy methodologies.

    The failure rates had left many companies to bite the dust and brought the key role played by quality in ensuring customer satisfaction and ROI for the business into sharp focus. Also, the IT landscape is witnessing developments such as mergers and acquisitions, increased focus on risk and compliance, data and analytics, the fast rollout of apps and mobile commerce, among others. These have necessitated the software development process to become increasingly agile, streamlined, collaborative and flexible. The reshaping of customer expectations is letting organizations to go beyond shift-left testing or DevOps testing by transforming the QA process into one driven by quality engineering.

    What Is Quality Engineering?

    To meet the growing demand for quality software applications in double quick time, a mere tweaking of the software development process is not enough. What is needed is the adoption of software quality engineering process comprising optimal quality assurance, predictive analytics and monitoring of QA elements to reduce glitches to negligible levels. The process would involve a continuous cycle of feedback and quality improvement based on the same. The quality engineering process offers maximum test coverage in the shift-left scheme of things and ensures outcomes like functionality, security, accessibility, usability, performance and reliability of the software application. It complements Agile and DevOps methodologies and ensures their outcomes to remain consistent with the desired business objectives. Quality engineering, instead of identifying the inherent glitches in the SDLC, focuses more on preventing them altogether.

    Shift Left and Strengthen Right

    Quality engineering services cover the entire spectrum of the SDLC thereby yielding the maximum test coverage and delivering the best quality product. With DevOps testing shifting left, the quality determinants are incorporated right into the product build during the development phase. At the same time, DevOps-based QA focuses on the shift-right approach to ensure the last stage of the SDLC i.e., delivery goes on unhindered and customer feedback is taken in right way and worked upon. The ultimate aim of both shift-left and right is to create and deliver a glitch-free product that meets the requirements of the end-users. Here, since end-users are the ones who ultimately assess quality of a software product based on parameters such as usability, functionality and performance, among others, the feedback mechanism should be responsive enough to understand the issues faced by the end-users and remedy them at the earliest.

    Quality Engineering as an Aid

    Quality engineering (QE) helps to bridge the gap between development and deployment processes, which can arise due to the lack of agility. It harps on the successful strategy of “test early, test often,” to pre-empt challenges that businesses face when testing a software product. Quality engineering ensures the quality of a software application throughout the SDLC–right from the designing stage to its final delivery. QE can be incorporated into the development process by using methods such as Behavior-Driven Development (BDD), Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD) respectively.

    Let’s find out what these methods are all about:

    • BDD: In this software development method, the behavior of both the software and business outcomes are taken into consideration. Here, the right sets of tests are automated, leading to an increased collaboration among developers, testers and other business stakeholders.
    • TDD: In this software development process, the QA team writes unit level tests before the development stage. This results in getting an early feedback and helps the development team to refactor its requisites.
    • ATDD: This software development process focuses on writing an acceptance test even before the development phase. This helps the software to meet the acceptance criteria beforehand.

    Quality Engineering and DevOps

    QE, being an end-to-end testing methodology, can offer optimum solutions to businesses struggling with their legacy IT infrastructure. The solutions in terms of continuous testing and integration as mandated by DevOps, can be arrived at by integrating the QA process with the DevOps pipeline. This results in executing processes such as build, test, deploy and deliver in a seamless manner. QE complements DevOps and Agile by detecting glitches right at the beginning of the development process.

    Moreover, QE’s focus on end-to-end testing helps the product to be developed and tested simultaneously. This approach adds teeth to the DevOps’s requirement for continuous integration (CI) and continuous delivery (CD). No wonder, the successful implementation of quality engineering is underpinned on fulfilling the requirements of DevOps and Agile. It further consolidates the benefits achieved from implementing DevOps testing services and Agile testing services.

    QE riding on DevOps and Agile can help businesses to scale up their operations without investing much resources and time. By implementing DevOps test automation and Agile test automation using a test automation software such as Selenium, Robitium etc., businesses can boost their SDLC. QE can help businesses to develop and deploy glitch-free software speedily and deliver enhanced customer experience.

    Conclusion

    The fast-changing competitive business landscape of today requires organizations to streamline their operations, increase productivity and fast forward the delivery of glitch-free software applications. To achieve these objectives, they need to make quality engineering as part of their development and testing cycles. However, QE ends up complementing the Agile and DevOps approach by achieving outcomes such as CI and CD. Furthermore, it leads businesses to get high ROI, better productivity, reduced cost of operations and enhanced customer experience.

    — Akshaya Choudhary

  • DOES19 London: Bridging the Communications Gap

    DOES19 London: Bridging the Communications Gap

    At the cornerstone of any successful DevOps transformation is effective communication between all members in an organization, from the business leaders, IT leaders, middle management and out to each individual member on their teams. Yet, so many times in organizational change, we see a monumental communication breakdowns occur.

    So it’s no surprise that every year at the DevOps Enterprise Summit, so many presenters attempt to tackle this issue. This past June, I had a chance to dive into this a little bit deeper with one of my favorite keynote speakers, AWS executive and a man who needs no introduction to our DevOps audience, Mark Schwartz.

    Over the years, Mark has been at the forefront of an ongoing conversation about the communication gap between business and IT leadership, both as an author, a speaker and during his time as an IT leader himself in organizations small and large, public, private and nonprofit.

    So, needless to say, when he stopped by the Digital Anarchist video booth to share about his newest book, “War & Peace & IT: Business Leadership, Technology, and Success in the Digital Age,” I was very happy to get the chance to continue the conversation.

    While Mark’s previous book, “A Seat a Table,” one of my favorite DevOps books, was primarily written for senior IT leaders, “War & Peace & IT” takes up where it left off, speaking directly to business leaders in an effort to further explain how a difficult relationship with IT can be one of the biggest impediments to the success of their DevOps transformation.

    By diving into the various barriers to effective communication between the business and IT, “War & Peace & IT” illuminates ways of helping all transformations change these negative patterns or avoid in the first place.

    Mark shares these insights from his book and more during our talk, which are all well worth the listen. Below the interview you can find the presentations from Mark at this year’s DOES London event as well, and if you’d like to learn more about Mark and “War & Peace & IT,” check out our DevOps Chat.

    Hope you enjoyed these great videos. For more information on how you can be at the next DOES event, check out DevOps Enterprise Summit Las Vegas 2019 which is happening Oct. 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for a premier event for the technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    Finally, be sure to check out the other 30 or so interviews we have from the conference on the Digital Anarchist site.

    — Alan Shimel

  • Optimism Matters and so Does a Sense of Wonder

    Optimism Matters and so Does a Sense of Wonder

    I’m a terrible video game player. For as much fun as people have with me at the table for Table Top RPGs (TTRPGs), I’m a pain when playing video games.

    As a guy with a masters in computer science, and years of experience ranging from embedded drivers to enterprise architecture, I see bugs or bad design decisions in video games and they tweak my sense of right and just. Ask my wife and youngest about playing Fortnite with me, you’ll get an earful. My wife uses her masters to analyze what could have happened in the code, and why it’s understandable. I fume and say “Yeah, well the code–not me, not the other guy–just eliminated me.”

    In short, I’m jaded where video games are concerned. As a casual gamer, I see the bad even while the good all around is rocking–EPIC devs, you’re doing a great job, particularly with the rate of change the game sees. Gamer rage is about the occasional oddity like getting stuck waist deep in the snow. Or about things beyond your control, like Skill Based Matchmaking that isn’t.

    I’ve noticed a trend in the portions of DevOps that I keep an eye on lately–fatigue. A sense that the change is non-stop, and the volume will just keep increasing. It only makes sense, we’re knee deep in sea change and new terms, products and processes seem to crop up on a daily basis. It can be wearing. Just looking at requirements for jobs–there is the persistent joke about 2000 years’ experience in Jenkins for a reason–it shows a fractured and constantly changing environment that begets unrealistic expectations.

    This has a tendency to make people jaded about new technologies and techniques. After all, Agile and DevOps have brought a huge return on investment, the law of diminishing returns might be kicking in, right? And lots of new shiny have turned out to be smoke and mirrors.

    The thing is, the rate of change in DevOps is still moving so fast because there is still more to gain. Continuous optimization, aka AIOps, is cool and promises a lot. Automated testing is still ramping up, even though automation of build tests is solid in most environments. Other kinds of testing (security, regression, live and even A/B) are still lagging, and test automation is offering help.

    What we need to do is try to keep that sense of hopefulness that we embarked on DevOps with. New tools might give us an appreciable ROI. They might free up time for time-constrained teams, which is the best ROI you can hope for. New processes might address shortcomings in existing ones. Will new tools and techniques always pan out? No, your environment is unique so even popular tools or techniques might not be best fit for your particular organization/apps. That’s okay, keep poking around at what’s new and remember the wins.

    I’ve got like a 4% win rate in Fortnite. Those other 96 games out of a hundred? All learning experiences to (hopefully) increase my win rate. Same with evaluating new tools. The failures feed the successes. It’s far easier to go “Product X didn’t work for us, and this is very much like it. Let’s look closely before even trying a pilot.”

    While there are more people in IT these days by conscious career choice, the bulk of us are still here because of the wonder moments–first time you got code to compile, spun up a cloud instance, figured out network segmentation or divided physical disk into partitions. The same sense of new and exciting should be brought to the current set of changing technologies, while still rock-starring your job. After all, it is some pretty astounding stuff we’re getting to play with every day.

    Maybe I’ll take my own advice, chill a bit when playing video games. After all, that’s another space that has jumped light-years in quality and availability.

    — Don Macvittie

  • From Automated Cloud Deployment to Progressive Delivery

    From Automated Cloud Deployment to Progressive Delivery

    Your team is on its agile journey and you can more or less track a deployment from a story, through git commits, to an automated builder, to an artifact repository, into a container and then onto the cloud. Or, in fact, any other of the many valid variants that lead you to believe your deployments are largely automated. What you can point to is a business request comes in and the result is a service or a new app. Your purview seems to stop before your users can even respond though. Is that good enough?

    Let’s go back to the early idea of a release. It was a collection of all the features and fixes the loudest stakeholders had persuaded the product owner to put at the top of the story list. A date was promised, but QA was late, and the persistent stakeholders squeezed a little more juice out of a story. Then it was stuffed into a ball and delivered to your servers overnight, lest anyone notice. The next day, the developers had to deal with the fallout as the support queues grew with confused users.

    While developers were getting the hang of the agile notion of automated deployment, the release lifecycle did pretty much end with a deployment going live. This gave certainty that what had been built and placed in the artifact repository was the same thing the testers had seen in the staging environment. And it also had the changes Jira said it had.

    This type of release was very much like a birthday present. Your uncle talked to your dad briefly, without your knowledge, and agreed you really would benefit from a new pair of socks. Then these were delivered on the day with the receipt in the bag, just in case you needed to take them back.

    The first evolution came with the concept that a release wasn’t exactly synonymous with a deployment. Finally, the end-user’s perspective nudged its way into corporate release strategy–updates could be deployed without necessarily impinging directly on every user. What if there were two identical release environments with clever network switching, meaning only one was truly live? This type of flip-flop arrangement (sometimes referred to as blue/green deployment) allowed changes to be tested internally in a realistic environment before going live.

    It was the advertising industry that prompted the idea of A/B testing. Instead of guessing one variation of a campaign might be superior to another, the surprisingly scientific method of using a controlled sample and a variation was used on audiences to see which they preferred. In the digital age, it is possible to deploy two variations of the same release to different server sets. This might mean each user session could be using either release. It would then be necessary to associate the resulting click-throughs, or whatever success measurement is chosen, to the specific release flavor. The worth of this kind of experimentation was only as good as the question you asked, but it was at least observing real user interaction.

    Moving on, DevOps environments began to use more feature flags or toggles. These were code paths that could deliver feature changes in live servers, controlled through configuration changes. This reduced the need to re-deploy to make certain changes. Release minded teams were coalescing around configuration, as opposed to just code. Whereas code once compiled and built was locked away in unreadable artifact files–a larger stakeholder community could administer configuration files, usually encoded in English. This helped to keep the feature changes closer to the stakeholders and less likely to slip back into silos.

    As a more defined understanding of delivery arrived, so did the understanding of the user community. It used to be the case that a user was a one-line entry in a database. Even firms whose business is not mining their user’s data understand there are different sets of users for products and services.

    Traditionally, there has always been internal users or beta testers–those within the firm whose job is to check the bits they understand, or are responsible for, are working as expected. Then outside the firewall, there are the tech savvy community who actively want the latest updates. These guys report bugs and often compare your product with the competition, perhaps using both. This audience will not lose their marbles if you deliver a bug to them. More to the point, they will notice rapidly–perhaps telling everyone on social media–about your failings.

    The disengaged users who may only have the free version or tier of your product come next. These people are more likely to work on impressions and are best not disappointed. They are also unlikely to be keen on updates. Finally, the large core of solid users who pay their way, just want things to work and need to understand a path to continuity will already appreciate the software and will understand the roadmap by osmosis. These will probably include your biggest users, too. Of course, if you have no way of distinguishing your users all the above is moot.

    With services sitting on a public cloud and CDN like edge services such as CloudFront, the ability to release by territory is much more straightforward. This is also increasingly necessary for legal reasons–EU regulations, for example. This allows for tactical releases to communities in different time zones and sizes. The practice of deploying changed services to a small group for risk mitigation, or “canarying,” is another method that takes advantage of smart routing. This requires the ability to quickly observe and rollback releases though.

    Today, most software has some degree of dark launch that restricts the visibility of a release to the appropriate community, until all is well. In this sense, a progressive delivery (defined as “continuous delivery with fine-grained control over the blast radius” by James Governor) can be seen as the virus-like spreading of your software or services from your development teams’ laptops to the last user.

    Observing service use is simply part of the core concern of virtually every company in the tech space. From this perspective, progressive delivery changes the way to see your development team as mere builders to user fulfillment specialists, which of course, they always were.

    The future will undoubtedly involve increasingly customer-driven releases, which goes hand in hand with the increasing use of data science to study user communities and their exhaust. The important take away is to make sure your team is reaching further to the right-hand side of the product journey, and keep the user’s reaction to what you make as a larger part of your sensory input. Think more about constant small changes and less about ceremonial releases.

    — David Eastman

  • How the World Measures DevOps Quality

    How the World Measures DevOps Quality

    With continuous everything, knowing whether each new release will ultimately enhance or undermine the overall user experience is essential. Yet, most of today’s go/no-go decision still hinge upon quality metrics designed for a different era.

    Every other aspect of application delivery has been scrutinized and optimized for DevOps. Why not re-examine quality metrics as well?

    Are classic metrics like number of automated tests, test case coverage and pass/fail rate important in the context of DevOps, where the goal is immediate insight into whether a given release candidate has an acceptable level of risk? What other metrics can help us ensure the steady stream of updates are truly fit for production?

    To provide the DevOps community an objective perspective on what quality metrics are most important for DevOps success, Tricentis commissioned Forrester to research the topic. The results are published in the 55-page report, Forrester Research on DevOps Quality Metrics that Matter: 75 Common Metrics—Ranked by Industry Experts. The report takes a deep dive into the global findings, complete with heat maps, quadrant mappings and some fun lists such as “Most Overrated,” “Hidden Gems” and “Top DevOps Differentiators.”

    One of the most common questions we received after publishing the report was: “How do the results vary across regions?” In response, we performed some additional regional analysis—and I’d like to share those results here.

    To start, let’s take a look at the global top 20. The following metrics were ranked as the most valuable by the DevOps experts who measure them (across all regions).

    Europe DevOps Quality Metrics Trends

    Looking specifically at Europe, the top 20 changes as follows:

    Interesting trends in this region:

    • There is a greater commitment to measuring quality metrics. European respondents reported a higher level of DevOps quality metrics measurement across the board. For almost all metrics, the usage rate was at least 6% higher than the global average. For metrics related to time, coverage, risk, effectiveness and efficiency, the usage rate was over 14% higher. This speaks to European organizations’ commitment to scrutinizing and continuously optimizing their quality processes—especially in terms of time and resource utilization.
    • Risk and coverage metrics are valued more than in the global average. European respondents also ranked risk and coverage quality metrics a surprising 21% higher than the global average. This could be related to the fact that the respondents from this region came primarily from the financial services and insurance sector, with healthcare and government close behind. In such highly-regulated industries, measuring and mitigating risk is certainly a core concern. This finding could also indicate European organizations place a greater emphasis on protecting the corporate brand.
    • Test data preparation time seems to be a greater concern. European respondents were more likely to measure (+18%) and highly-value (+23) time spent preparing test data than their global peers. Given the restrictions GDPR placed on test data as of May 2018, it seems likely that European organizations have significantly changed their test data management processes (e.g., to masking and more synthetic test data generation), and are cautiously monitoring how the changes are impacting their overall efficiency.

    Asia Pacific DevOps Quality Metrics Trends

    Now, let’s shift focus to Asia Pacific. The following 20 metrics were ranked as the most valuable by the Asia Pacific DevOps experts who measure them:

    Notable trends in this region:

    • End-to-end testing metrics are valued—and measured—more than in the global average. Although Asia Pacific respondents measured fewer build and functional validation metrics than the global average, they measured (and valued) end-to-end testing metrics much more than their peers around the world. For example, percent of automated end-to-end tests was measured by 47% of the organizations (versus 36% globally) and highly-valued by 84% (versus 70% globally). Risk coverage measurement was significantly higher; it was measured by 49% (versus 34%) and highly-valued by 71% (versus 59%). This speaks to the region’s focus on digital transformation and commitment to delivering exceptional user experiences.
    • API testing metrics were also valued—and measured—more than in the global average. Asia Pacific respondents also measured and valued API testing quality metrics more than the global average. Overall, API quality metrics were measured by 16% more organizations in this region than globally. The highest valued API quality metrics were API test coverage (63% versus 39% globally) and API risk coverage (79% versus 62% globally). This prioritization of API testing is likely a side effect of the regional trend towards API-driven open banking (the majority of respondents indicated they were in the financial services and insurance sector).
    • There is a greater leader/laggard quality metrics measurement gap. Part of the study involved classifying the respondents as either DevOps leaders or DevOps laggards, based on their responses to various questions about the maturity of their processes. Although the percentage of DevOps leaders in the region was lower than the global average (18% versus 26%), the DevOps leaders from Asia Pacific generally measured quality metrics at a comparable rate to their global peers. However, the DevOps laggards in Asia Pacific generally measured quality metrics at a much lower rate than their global peers. This suggests the select set of firms that have truly prioritized DevOps initiatives have made great strides—and the laggards have a lot of catching up to do in order to remain competitive.

    Research Methodology

    Here’s a look at the process behind the research discussed above:

    1. Survey 603 global enterprise leaders responsible for their firms’ DevOps strategies.
    2. From that sample, identify the firms with mature and successful DevOps adoptions (157 met Forrester’s criteria for this distinction).
    3. Learn what quality metrics those experts actually measure, and how valuable they rate each metric that they regularly measure.
    4. Use those findings to rate and rank each metric’s usage (how often experts use the metric) and value (how highly experts value the metric).
    5. Compare the DevOps experts’ quality metric usage versus that of DevOps laggards. If there was a significant discrepancy, the metric is considered a DevOps differentiator.

    — Wayne Ariola

  • DevOps Enterprise Summit Las Vegas 2019 Programming Highlights: What I’m Looking Forward To

    DevOps Enterprise Summit Las Vegas 2019 Programming Highlights: What I’m Looking Forward To

    I am so excited about the upcoming DevOps Enterprise Summit (DOES) Las Vegas. As a programming committee, we seek to make each event better than the last, as measured by how much we learn and how it helps enable the DevOps Enterprise community to achieve their goals.

    As a programming committee, we thought London 2019 was our best conference yet (almost unanimously), which poses a challenge of how could we possibly do better—but I’ve found over the last several years that this is doable, mostly by being very explicit about what challenges across our community we want to help to overcome.

    This year, we focused on the following areas, and I think you’ll find the upcoming conference does an amazing job of addressing them:

    • Experience reports of technology leaders presenting with even more senior business leaders.
    • Overcoming obstacles in security and compliance.
    • Experience reports and subject matter experts in the areas of data science and data initiatives.

    Reviewing this post, I’m finding the number of amazing stories being presented is so good that it’s incredibly difficult to pick which ones to mention here. But, the following speakers really stood out to me, because they’re so different than those from previous years:

    • David Almeda, chief people officer at Kronos: I was blown away when I saw him present. He talked about how one of their top strategic goals was to attract and retain great talent—the result was Kronos being named as one of the top 100 best places to work by both Fortune Magazine and Glassdoor, enabling then to support continued growth, innovation and profitability. He’ll be teaching us the value of employee engagement, and how the top levels of leadership view it.
    • Andre Martin, VP and chief learning officer at Google: Until recently, Dr. Martin was chief learning officer at Target, and before that, at NIKE. He will be sharing what his charter was in those roles, why those organizations created his role in the first place and how it could advance the mission of the DevOps Enterprise community.
    • The Big Four Auditor panel: In this amazing panel, we have four distinguished experts who support the audit practice.  We will be busting the most commonly heard myths and objections about “why DevOps can’t work here,” such as why DevOps can’t be done in regulated industry, why separation of duties prevents DevOps and many more. The four auditors are: Yosef Levine from Deloitte, Michael Wolf from KPMG, Matt Bonser from PwC and Pierre Fourie from Ernst & Young. They will be hosting two Ask An Auditor Anything workshops, facilitated by Dr. Tapabrata Pal and Sam Guckenheimer. This is an opportunity to anonymously ask questions about the audit process with some of the best experts in the space.

    I attended a smaller version of this session in London and I thought it was incredible and truly notable.  This one promises to be a landmark moment for the DevOps Enterprise community.

    Without a doubt, the programming committee has worked hard to create a high learning experience filled with technology leaders pioneering the business practices that will surely be commonplace within a decade. This, combined with experts from the domains that we’re drawing upon to help achieve our goals–along with exciting networking opportunities each day of the event–has helped us establish an industry forum for exchanging insights and information we need as a community.

    I hope you’ll join us in Las Vegas, and that you’re as delighted by the program as we are! In my career, I have grown to love conferences and have benefited so much from them. And yet, this conference is still my favorite. I never learn as much in such a short period than when I’m at DOES.

    Acknowledgements and Changes from Last Year

    I want to thank everyone for submitting a proposal to DOES for Vegas 2019. I personally appreciate and recognize the effort required to prepare your submissions. And I know because I still spend a lot of time preparing and submitting proposed abstracts.

    This year was the most difficult selection process for the programming committee ever, especially when so many are friends and people whose work we all respect so highly.

    To explain how we made decisions, I want to frame everything in terms of the conference programming objectives. Broadly speaking, here are the number of talk slots we reserved for each programming objectives:

    Talk Track Subject Areas Slots
    Experience Reports: New 12
    Experience Reports: Repeat 6
    Spanning Business/Tech Divide 9
    Next Gen Ops 8
    Overcoming old ways of working 7
    Subject Matter Experts 7
    Dynamic Learning Organizations 5
    Leadership Lessons, Transformational Leadership 3
    Other 4
    Total 65

    One thing that you should notice right away is every track only has a few slots. Another thing you are probably unaware of is we had more speaking submissions than ever before–it blows my mind just thinking about it.

    Evolving Programming Objectives

    In addition to the amazing response we received for this year’s call for presentations, we also worked to address some feedback from 2018 that “some talks sounded the same as last year.” So, we reviewed the talks again, and observed that some of the repeat speakers we invited didn’t have a lot of change since the last time they spoke. As a result, we’ve done two things:

    1. We’ve nearly halved the number of speaker slots for repeat speakers (see stats below)
      • 45% of repeat speakers (Vegas 2018)
      • 27% of repeat speakers (Vegas 2019)
    2. We invited repeat speakers who have a large change to report, or a different perspective to share (e.g., a different co-presenter from another business area), etc.

    In general, our top-level goal every year is to help technology leaders succeed in transforming their organizations—both by increasing the likelihood of their success and accelerating the rate of adoption of DevOps principles and practices by focusing on the following talk tracks and subject areas listed above.

    We aim to fulfill this goal through speaker presentations, both from technology leaders and/or subject matter experts from those domains. We also do this through less structured networking sessions where attendees can find other people who are tackling similar challenges or want to learn more about a particular area of interest.

    New Experience Reports

    One of the hallmarks of DOES is our program focuses on spotlighting real world experience reports, straight from the mouths of those who are driving enterprise-scale transformation. As adult learners, and as leaders, there are few (if any) better ways to learn than watching how other people in similar situations solve their problems.

    Besides enabling learning, experience reports serve another important goal—they help us as leaders negate objections that “DevOps can’t be done here.” I’m happy to say over the past six years, we’ve assembled a growing library of 250 experience reports from some of the most recognized brands around the world. As a whole, it shows DevOps principles and patterns are universal across nearly every industry vertical today. Some of the new experience reports I cannot wait to hear in October include:

    • Heather Mickman (VP platform engineering) and David Cherryhomes (VP, IT), UnitedHealth Group: Heather and David will be talking about their amazing work transforming business and technology at UHG, the largest healthcare company in the world, with over 115 million customers. (You will likely remember Heather from her pioneering work at Target, co-presenting with Ross Clanton from 2014-2015 and keynoting by herself in 2016).
    • Fernando Cornago (senior director, platform engineering) and Benjamin Grimm (senior director experience .com), Adidas: They will be presenting about the work they have done to elevate developer productivity at Adidas, including supporting the incredibly important e-commerce initiatives, as well as product design. They will share how they’ve educated top executives and even board members on critical technology concepts, and how they’re making all data easy consumable by everyone across the company.
    • Kira Barclay (director, analytics) and Elizabeth Conzo (analytics leader), John Deere: They will be presenting the amazing work they’ve been doing supporting both enterprise data initiatives, as well as incubating Horizon 3 initiatives and modernizing the software practices in some of the largest product lines at John Deere.
    • Ralf Waltram (VP of IT delivery), BMW: Ralf will be talking about the DevOps and Project to Product journey, which as he says, is how BMW is transitioning from project management to product management. In the BMW team’s words, this the “largest change to how business is done at BMW in twenty years.”
    • Jim Lloyd (chief of the innovation branch, field operations directorate) and Melinda Solomon (Agile training lead), USCIS: Jim and Melinda will be sharing the continuation of the DevOps journey at the US Citizenship and Immigration Services. Jim will be talking about specific mission objectives at USCIS, and the business and technology partnership.
    • Jaclyn Damiano (associate director) and Josh Stone (senior architect/evangelist), Verizon: Verizon has holistically undergone massive organizational and business changes in the past year. A voluntary separation package and outsourcing to third parties has changed the makeup of the team and the culture. A corporate reorganization so significant it is defined as “Verizon 2.0.” They will be talking about how to stay the course on digital transformation, cloud migration and culture change in such a turbulent environment.

    Continued Experience Reports

    This year, we will have six companies back to present their continuing experience reports at the conference. Having this pattern of repeat speakers may be a bit unusual, but I personally love that we’re following these courageous leaders along their journey. I want the experience to have front-row seats to an unfolding documentary of the ongoing transformations they are leading in their large, complex organizations.

    How has the story from the previous year evolved for the organization and the leader? What new obstacles emerged, and how did they overcome them? Is this a path the rest of us want to follow? What are the things worth celebrating as part of this journey and why? For DOES Las Vegas, we have the privilege of welcoming these people back to take the stage:

    • Scott Prugh, chief architect and VP software development at CSG: Scott has spoken at every DOES since the beginning. This year, I’ve asked Scott to speak on something he’s never directly spoken about, which is how they’ve overcome incredible architectural challenges as their transaction growth exploded.  This is one of the most incredible engineering achievements I’ve ever seen.

    Spanning the Business and Technology Divide

    One of the top challenges we see year after year is how to get business leadership on board—and by that, I mean enthusiastic and grateful business partners, who want to tell the world how all their goals and aspirations are finally achieved by working together with their technology counterparts.

    These are often the most difficult talks to find, because they require a technology leader with a great working relationship with their business counterpart, and visible success. In Las Vegas 2018, we had some fantastic talks along these lines (from Nike, Capital One, Target, The Walt Disney Company and Kaiser Permanente).

    This year, we’ll be featuring even more talks like this (33% more to be exact), showing how technology leaders are partnering with not just business leaders, but also other areas of the business, such as product leadership, security/privacy, legal, project management and so forth. Specifically, we are eager to hear from the CFO and Project Portfolio perspective. Here are a few talks I’m super excited to hear:

    • Chris O’Malley (CEO) and Joe Aho (CFO), Compuware: My fireside chat with Chris O’Malley last year was one of the most talked about sessions last year. I’ve invited him back with his CFO, asking them to teach us how to better interact with CFOs, a famously conservative group, and how we can win them over to help DevOps initiatives.
    • Levi Geinert (SVP and head of Agile technology experience) and Werner Loots (EVP consumer and business banking), U.S. Bank: Levi talk about his new role in the Experience Studios, where their goal is to reimagine banking, an effort being driven from the very highest levels of leadership. He and Werner will speak about some of their challenges and noteworthy successes, which has created excitement across the organization.

    Next Generation Operations

    After hearing ops needed more representation at DOES, in 2018 we reserved nearly a quarter of our talks to focus on ops and infrastructure challenges, and created a separate subcommittee to focus on this area. While we aren’t going to have as many next generation ops talks this year, it is our third largest talk track behind new experience reports and spanning the tech and business divide.

    What’s amazing is that we learned the elevation of this topic has fundamentally changed the feel of the conference itself. The programming committee has made an effort to help define and clarify what exactly the role of an ops leader is, and how all the technology and organizational changes there have been in how infrastructure is designed, delivered and operated. I’m thrilled to be able to see this presentation this year:

    • Scott Havens, director of software engineering at Walmart Labs and Jet.com: Until very recently, Scott was responsible for rebuilding the entire inventory management systems that support Walmart, the world’s largest company. He will be sharing how he used functional programming principles to massively simplify the vast architecture that supported the inventory management systems, making it simpler, more reliable, easier to maintain and cheaper to run.

    Subject Matter Expert Talks

    All leaders are, for the most part, self-teaching ourselves what we think we need to learn to be successful. Technology leaders in particular have to adapt to a somewhat constant rates of disruption and change happening around us. In the past, we’ve brought experts such as Dr. Christina Maslach (burnout) and Dr. Richard Cook (safety culture) to deliver talks about the domains we want to learn more about to help us reach our desired outcomes. This year we have the following subject matter experts onsite to deliver presentations:

    • Andre Martin, VP and chief learning officer at Google: Until recently, Dr. Martin was chief learning officer at Target, and before that, at NIKE. He will be sharing what his charter was in those roles, and why those organizations created his role in the first place, and how it could advance the mission of the DevOps Enterprise community.
    • Christopher Bergh, CEO and head chef at DataKitchen: He will be talking about the chronic problems of getting data from where it resides (typically trapped within data warehouses) to where it needs to go (by the teams who need data to make decisions, or manipulate it to make it more useful). Chris had a huge impact on the development of The Unicorn Project, and helped me see the parallel universe of DataOps.
    • Nicole Forsgren, head of DORA and Dr. Dustin Smith, human factors psychologist and senior user experience researcher at Google: They will be presenting all the amazing and continuing findings from the 2019 State of DevOps Report, which continues to uncover fascinating insights on what enables high performance.

    Networking Opportunities, Lean Coffee, Lightning Talks and More

    In addition to all the wonderful talk tracks and exciting presentations above, the conference program creates a forum for different ways to “get together and go faster.”

    I’ve said this before, but it is so important for the organizers of DOES to help attendees achieve their desired outcomes. One of the most special experiences at DOES comes from meaningful one-on-one interactions with your fellow attendees.

    To that end, and together with my friend and IT Revolution advisor, Jeff Gallimore, we have established different ways for people to learn, ask and answer as many questions as possible–based on experiments and what we learned from London earlier this year. Because the quality of the audience is one aspect that we think separates the DOES from all the rest, the more spontaneous conversations and interactions we can nurture onsite, the better for all.

    • DevOps Confessions: At the beginning of each day, programming committee members will read anonymized stories of confessions from leaders in the DevOps community to learn about the struggles, failures and near-misses. These are some of the best anecdotes you may ever hear.
    • Speakers Corner: We created a dedicated time and a location to ask the plenary speakers questions that go deeper on the information presented earlier that day.
    • Lean Coffee: Led by Dominica DeGrandis, author of Making Work Visible and the foremost expert in Kanban Flow within the IT industry today, attendees can connect with and learn from their peers in a semi-structured format all three days of the conference.
    • Birds of a Feather Sessions: This is more like the DevOpsDays unconference sessions, with less structure than a Lean Coffee format, and these sessions are driven by specific topics that attendees want to discuss and learn about. I thoroughly enjoyed the interactions of these sessions in Las Vegas last year.
    • Lightning Talks: These are rapid-fire, must-see presentations that happen from the main stage after the conference day has concluded. Also, as a bonus, the IT Revolution book signing happens immediately afterward.
    • Industry Party: In addition to sponsor giveaways, great food and drinks, this is when I’ll have the book signing of my newest title, The Unicorn Project. The industry party is one of my favorite times during the conference to continue conversations with my fellow attendees and speakers.
    • Slack Workspace: The conference will have a shared Slack workspace for people to interact with speakers, attendees and sponsors. In the past, this is where people have connected to make plans, search/recruit for job opportunities and more.

    As you can see, there’s a lot getting me excited for the conference this year, and I hope to see you there!

    To preview DOES Las Vegas 2019 and learn more about the conference, please watch previous videos of our presentations, download the past speakers’ slide decks and view photos from all past events.

    Special offer: Pre-order 10 copies (or more) of The Unicorn Project by Oct. 30 and receive $350+ off your next conference registration, plus lots of other bonuses. For more details click here.

    — Gene Kim

  • Free DevOps Training at DOI’s Global SKILup Day

    Free DevOps Training at DOI’s Global SKILup Day

    The DevOps Institute (DOI) is hosting a global training day called Global SKILup Day on Dec. 10, 2019. It’s a free virtual event and they have arranged for some of the brightest minds in the DevOps space to speak/train during the course of the day.

    Why global? They truly are planning on a follow-the-sun approach to training, with courses going on in each of the different regions throughout the day. In total, the event will run for 18 hours and span the globe–meaning where ever you are, free training is available to you.

    The SKIL (Skills, Knowledge, Ideas and Learning) part of this free training day is DOI’s training methodology for the next phase of DevOps. They have been conducting SKILup Days around the globe for a while now, and this appears to be a virtualized extension of that effort.

    “What type of training,” you ask? Well, here’s a list of topics broken down by DOI.

    No matter what your interest and/or needs are, there will be something that you can pick up at this training.

    As of this writing, there are 15 speakers to cover 18 hours in three regions, so while I am not party to their internal planning, this author would guess they are still filling out the engagements. Considering we’re nearly two months away, that’s not terribly surprising. What is surprising is the list of speakers contain a high percentage of recognized experts. That’s good for the training, because superstars who can’t present generally don’t have the name recognition these presenters do. And a huge chunk of effective of training is presentation.

    So go sign up! Grab a spot, set the systems to do long builds and learn something new. I like to go to these type of events simply because our little lab is set in its ways, and getting exposed to new methods/ideas keeps things from getting to stale. I won’t be taking up space at DOI though, as I’d rather leave it for all of you when space is limited.

    Since my current responsibility is for a testing lab, this is more important for those of you who are running public facing systems that represent your organization. If I were, the big one for me would be AIOps, because it kind of snuck up on me while working on continuous test and integrating new tools into the DevOps toolchain. In fact, my recent piqued interest in the topic came from looking at an integration and the tool was big on AIOps–though CI/CD Reference Architecture would be cool too. Attempts to standardize are interesting, because even though some parts have stabilized, we still very much live in the land of flux.

    Pick something you don’t think you care too much about along with things you do. You just might find a good reason to care, and it will help you continue to rock it.

    Disclaimer: I have contracted for DevOps Institute in the past (through Ingrained Technology), but I am not currently engaged by them. I shared this because it is free training, and who doesn’t want to know about that?

    — Don Macvittie

  • The Real-Time Innovation Dividend

    The Real-Time Innovation Dividend

    Time is compressing. The attention span of individuals and organizations is becoming ever shorter. There are only brief windows that can be devoted to any given transaction.

    Expectations around situational knowledge, updated in real-time, are compounding. Customers expect the applications they interact with know where they are, what they are looking for and what their preferences are in terms of price, value, design and timeliness of delivery. If the proper options aren’t provided immediately, the customer will move on to another provider.

    While the time available to an algorithm or application is contracting, the complexity of the tasks for successful interactions is increasing. Digital businesses must do more in ever shorter time windows. Differentiation in the digital world has a lot to do with a deep understanding of the customer based on multiple data streams and driving decisions that provide a deeply personalized experience.

    In business, we need to have a current picture of our situation. We build models and analytic dashboards, but these fall short in allowing us a real-time view. The latency of these models may be measured in seconds, minutes, hours, even days and weeks. As latency expands, the picture is not of the moment and that difference defines operating risk. The phrase “time is money” has never been more accurate.

    Brokerages require as close to a real-time view of positions allowing them to manage risk more closely, in terms of their aggregate position, based on a transactionally correct view of precisely what they have on their books to respond in real-time to global market changes.

    For retailers, it means knowing the content a customer has seen and the environment where they encountered it. Did they just come from a brick and mortar store? What digital journeys have they been on? What online content have they been perusing? Continually adaptive models use the answers to these questions to select active customers and recommend options that address what they are searching for.

    The digital shopping experience is composed of multiple linked processes, working in concert to continually understand the customer experience. Different system elements–user profiles, decisioning, recommendation engines and machine learning and AI–require data across different time windows. Some of these systems deal with terabytes of data and some petabytes. Some require absolute consistency and for some eventual consistency is good enough. In many of these systems, there is a demand for hyperscale within tight time windows.

    The ability to take in more data within a given time window feeds the currency of the context. It is not enough to have a lot of data, but you also need the most current view of that data. Operating at hyperscale enables an organization to deliver exponentially more data than traditional databases. This makes models more accurate and, by extension, more valuable.

    Scale Plus Speed Equals More Time

    In some sense the combination of scale with speed creates time, giving you the ability to do more within a given time window. Consider this a dividend, allowing the use of more data or allowing the process to be completed in less time.

    The systems that interact directly with either customers, employees or clients are edge computing systems, pulling in and processing data within relatively tight time windows. Edge systems may have expiry windows where data is deleted after a given time window where it is deemed to be stale.

    The data collected and processed at the edge may be moved to a system of record or core transactional store and kept for longer periods providing historical context. These data sets may grow to petabytes in size while still needing to support response times measured in milliseconds. Meeting these requirements requires hyperscale capability, where the performance of data access does not degrade as the repository of information grows.

    Here’s a real-life example. We must match the information collected regarding devices, identity and patterns that establish context against our database of user profiles. We want to run more sophisticated recommendation engines based on these patterns to ensure we are putting the closest thing to what the customer wants in front of them. We also want to make pricing decisions in real-time, to gain the largest basket at the best margins. We may have established a model that tells us customers with this profile are likely to make additional purchases after this transaction, so our analysis and optimization boundaries go beyond just this transaction. We will want to log this so we can track this behavior to validate the model. We have these processes going on, some in parallel, others in sequence:

    • Establish an identity profile of the customer.
    • Match that profile against a database of profiles that models likely desires and behaviors.
    • Based on that match, determine the products and/or services to recommend.
    • Select the content and media types based on the user profile.
    • Determine pricing based on the user profile and the transaction profile.

    The last element, real-time pricing, is something we want to modify to take into account the margin and profitability of the customer over time. We also know that if this impacts the overall window of the transaction the customer has a higher likelihood of abandoning the transaction and we can lose out on not just this transaction, but a whole set subsequent to this one.

    Doing Better for Both the Customer and the Business

    By building models based on hyperscale capability, 10 milliseconds are saved here, another 20 milliseconds there. This creates the time bandwidth in the overall process to add the notion of optimizing pricing around not just this transaction, but the value of this transaction profile and the relative margins of the various components in this sale and other subsequent sales that are likely to happen. We have created time to do this additional processing and do better–better for our customers and better for our business. And we know that as we add more data points to our profiles and scale up to include more data overall, we won’t experience performance degradation. These time benefits will remain. This is the real-time innovation dividend.

    — Lenley Hensarling